Wireformat to importable opcodes: hello-world goes from 37.6 to 14.5 kB (brotli) - #21585

Each statement and expression compiler in `opcode-compiler/lib/syntax/`
is now an exported op object, `{ id, compile }`, created with a
`/*#__PURE__*/` call. `@glimmer/opcode-compiler/ops` re-exports every op
under its `SexpOpcodes` name. A compiled template can put the op object
in the head position of a tuple, and `compileSexp` calls `head.compile`.
Because each op imports the runtime handlers it pushes, importing an op
pulls in only the handlers that op needs.

Templates that still ship a JSON block have numeric heads. The template
factory in `lib/template.ts` handles them: it fills a number-to-op table
from every op through `syntax/legacy.ts` and parses the block. A build
that emits op-headed blocks uses `lib/template-core.ts` through the new
`@ember/template-factory/modular` entry, so the legacy table and the
unused ops stay out of the bundle. `@glimmer/program` builds its default
template from `YieldOp` directly for the same reason.

Head comparisons in `helpers/resolution.ts` and the `Append` compiler go
through `headId`, which accepts either a number or an op object.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PQyBrSj4CZaqMcKc7aW81

`precompileModule` in `@glimmer/compiler` compiles a template the same
way `precompile` does, but prints the block as JavaScript whose tuple
heads are identifiers such as `__wf_Append`. It returns the expression
plus the list of identifiers to bind, each with the module and export
name to import (`@glimmer/opcode-compiler/ops`). A build tool adds the
imports and renames the identifiers. The template `id` is still hashed
from the JSON form, so ids do not change between the two formats.

`ember-template-compiler/minimal.ts` exports it, which is the entry the
babel plugin loads, and the build wiring in `broccoli/` passes it
through. `rollup.config.mjs` adds `@glimmer/opcode-compiler/ops` as an
exposed entry so an app can import it from ember-source.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PQyBrSj4CZaqMcKc7aW81

This is a temporary `pnpm patch` until the change lands upstream. When
the template compiler exposes `precompileModule`, the plugin calls it,
binds each opcode identifier to an import from
`@glimmer/opcode-compiler/ops`, and emits `createTemplateFactory` from
`@ember/template-factory/modular`. Compilers without `precompileModule`
take the JSON path as before.

`babel-import-util` matches its placeholder nodes by identity, so the
plugin replaces every occurrence of an opcode identifier with a fresh
node from `i.import()` instead of renaming in place.

With this patch, ember-source's own templates and the smoke test apps
compile to op-headed blocks. Hello world smoke app, Vite production
build: 135.07 kB / 43.27 kB gzip before, 123.90 kB / 39.77 kB gzip after.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PQyBrSj4CZaqMcKc7aW81

The standard library used to compile all five routines eagerly when an
evaluation context was created. `StdAppend` references the component
invocation helpers and the content handlers, so every app shipped them
even when no template had a dynamic `{{value}}`.

A routine is now a `StdlibBuilder` object. `stdlibOperand` takes the
builder instead of a name, and `StdlibImpl.handle(builder)` compiles it
the first time a template asks for it. Because a routine compiles into
its own heap region, the encoder records a fixup for the operand and
patches in the handle after `commit`, once the asking program's region
is closed. Nested routines (`cautious-append` calls
`cautious-non-dynamic-append`) use the same fixup path.

`context.stdlib.main` still works. It compiles the root routine on first
access, which happens on the first render.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PQyBrSj4CZaqMcKc7aW81

The Glimmer global context and the renderer used to import `get` and
`set` from metal, the Ember array iterator, proxy checks, and backburner
directly. A strict app that renders one component with `renderComponent`
shipped the whole object model and the run loop through those imports.

`-internals/glimmer/lib/hooks.ts` now holds slim defaults: tracked reads
and writes on plain objects, native arrays and iterables, and a run loop
with `actions`, `render`, and `destroy` queues flushed on a microtask.
The modules that own the richer behavior register their versions when
they load:

- `metal/lib/property_get.ts` and `property_set.ts`: `get` and `set`
- `metal/lib/tags.ts`: `tagForProperty`
- `@ember/array/index.ts`: `isEmberArray` and `objectAt`
- the proxy mixin: `isProxy`
- `@ember/runloop/index.ts`: backburner

Every entry in the global context delegates at call time, and listeners
attached to the default loop move to backburner on registration, so
import order does not matter. An app that imports any of those modules
behaves as before. The hello world smoke app drops from 114.1 kB to
94.7 kB raw (36.9 kB to 30.7 kB gzip).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PQyBrSj4CZaqMcKc7aW81

In a strict template, `mut`, `readonly`, `unbound`, and the keywords the
AST transforms emit (`-each-in`, `-track-array`, `-in-el-null`, and so
on) compiled to `GetStrictKeyword` and resolved through the resolver's
built-in helper table. That table imported every keyword helper, and
through them the object model, so the strict render path shipped all of
it.

Three changes:

1. The module printer takes a `lexicalKeywords` map. A keyword in the map
   is printed as `GetLexicalSymbol` with a slot after the template's own
   locals, its import is added to `imports`, and `precompileModule` adds
   the slot to the `scope` function. Ember's wrapper supplies the map for
   strict templates, pointing at `@ember/-internals/template-keywords`.
2. The resolver's built-in tables start empty and `ensureBuiltins()`
   fills them. The legacy JSON factory, the new
   `@ember/template-factory/loose` factory, and the classic `Renderer`
   call it, because those are the paths that resolve by name.
   `precompileModule` now reports which factory the build tool must
   import, and the babel plugin patch uses it.
3. `EachInWrapper` moves to its own module, so the default iterator no
   longer pulls in the `-each-in` helper and its dependencies.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PQyBrSj4CZaqMcKc7aW81

`NewTreeBuilder.setDynamicAttribute` was a class method, so every bundle
carried the dynamic attribute classes, property normalization, and URL
sanitization behind it. The logic is now `setDynamicAttribute()` in
`vm/attributes/dynamic.ts`, and the two handlers that set dynamic
attributes import it. A template with only static attributes drops it.

The default iterator checked for `EachInWrapper` and carried the object
and map iterators with it. `toIterator` now tries registered extensions
first, and the `-each-in` helper registers the each-in iterator when it
loads.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PQyBrSj4CZaqMcKc7aW81

`encodeOp` switched on five numeric resolution opcodes and imported all
of `helpers/resolution.ts` to do so, which put the loose mode name
resolution code in every bundle. The ops that resolve by name now push a
`ResolutionHandler` object, and the encoder calls `head.resolve`. A
build with only strict templates drops the resolution code with the ops
that need it. `Local` and `TemplateLocal` stay numeric, since the
encoder handles them inline.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PQyBrSj4CZaqMcKc7aW81

`enterList`, `registerItem`, and `exitList` were VM methods, so the VM
referenced `ListBlockOpcode` and every bundle carried the keyed list
diffing behind `{{#each}}`. They are functions in `vm/lists.ts` now, and
the list handlers import them. `enterItem` stays on the VM because
`ListBlockOpcode.sync` calls it, and moving it would create an import
cycle between `update.ts` and `lists.ts`.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PQyBrSj4CZaqMcKc7aW81

`ComponentElementOperations.flush` called `setDynamicAttribute` for
reference values, which kept the dynamic attribute classes, property
normalization, and URL sanitization in every component render. Callers
of `setAttribute` now pass an applier along with the reference, and
`flush` uses it. The `ComponentAttr` handler, the curly component
manager, and the classic attribute bindings all pass
`applyDynamicAttribute`, so a template-only component whose attributes
are all static drops that code.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PQyBrSj4CZaqMcKc7aW81

The Glimmer environment constructed `DebugRenderTreeImpl` itself when
the delegate enabled debug tooling, so the implementation was in every
bundle even though Ember turns it on from a runtime flag. The delegate
now supplies the tree, and `EmberEnvironmentDelegate` constructs it
behind an `@embroider/macros` condition:

    setConfig: { 'ember-source': { debugRenderTree: false } }

in an app's `buildMacros` config drops the implementation. Without the
config, behavior is unchanged: the tree exists when
`ENV._DEBUG_RENDER_TREE` is set, which the inspector does at runtime.

`@embroider/macros` moves to `dependencies` because published code now
imports it, and the test babel config evaluates the macros so the suite
runs. A type stub covers `@glint/template`, which the macros types
import and this repo does not depend on. The hello world smoke app opts
out to show the effect.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PQyBrSj4CZaqMcKc7aW81

The component and modifier handlers carried the code that feeds the
debug render tree inside `if (vm.env.debugRenderTree !== undefined)`
blocks: args capture, custom lifecycle nodes, destructor registration,
and two updating opcodes. That is about 5 kB of source in every bundle
even when the tree is left out.

Those blocks are now methods on `DebugRenderTreeImpl`
(`componentDidGetSelf`, `componentDidRenderLayout`, `modifierDidAdd`,
`remoteElementDidPush`), and the handlers call them through
`debugTree(vm.env)?.`. A build that opts out of the tree drops the
bookkeeping with it. The runtime only ever receives `DebugRenderTreeImpl`,
which is why `debugTree()` can narrow the host-facing type.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PQyBrSj4CZaqMcKc7aW81

`BaseRenderer.strict` constructed `ResolverImpl` up front, which kept
the resolver and `@ember/instrumentation` in every bundle. The strict
path now starts with `LazyResolver`, whose lookups return `null` until
`ensureBuiltins()` registers the real resolver. The paths that resolve by
name already call `ensureBuiltins()`, so behavior is unchanged for them.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PQyBrSj4CZaqMcKc7aW81

…uilder

`NewTreeBuilder` carried `{{#in-element}}` support (`RemoteBlock` and the
remote push and pop), the block list behind `{{#each}}`, and the appends
for `{{{html}}}`, fragments, and nodes as class methods, so every bundle
kept them. They are functions now:

- `vm/remote-element.ts`: `pushRemoteElement`, `popRemoteElement`,
  `RemoteBlock`. Builders that customize the push (rehydration,
  serialization) implement the optional `__pushRemoteElement` hook, and
  the serializer reuses `defaultPushRemoteElement` after adding its
  marker.
- `vm/dynamic-content.ts`: `appendDynamicHTML`, `appendDynamicFragment`,
  `appendDynamicNode`.
- `vm/lists.ts`: `AppendingBlockList`, pushed directly by `enterList`.

`pushBlock` and `pushElement` become public for those functions. Every
tree builder in the repo extends `NewTreeBuilder`, which the functions
rely on.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PQyBrSj4CZaqMcKc7aW81

…sImpl

`ConstantsImpl.helper()`, `.modifier()`, and `.resolvedComponent()` exist
for name resolution: loose mode templates and `{{component "name"}}`.
As class methods they stayed in every bundle, and through
`getInternalHelperManager` they kept the custom helper manager too.

They are functions in `@glimmer/program/lib/definitions.ts` now, with
their caches keyed by the constants pool. `ResolutionTimeConstants` keeps
`component()` and `defaultTemplate`, which every render uses.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PQyBrSj4CZaqMcKc7aW81

`api.ts` built `new CustomHelperManager(() => new FunctionHelperManager())`
at module load, so the custom helper manager and the args proxy reached
every bundle that looked up a component manager. The default is created
the first time a plain function is used as a helper.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PQyBrSj4CZaqMcKc7aW81

`@ember/-internals/browser-environment` computes `isChrome`, `isFirefox`,
and the user agent on load. The renderer only needs `hasDOM`, so it
imports that module directly. The hello world smoke app turns off Vite's
module preload polyfill, which has nothing to do for a single script.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PQyBrSj4CZaqMcKc7aW81

The transaction held the modifier install and update queues and the
tracking code that flushes them, so every bundle carried modifier support
whether or not a template used a modifier. The transaction now offers
`schedule(hook, item)`: work queued under a hook runs once at commit with
everything queued under it. `vm/modifiers.ts` owns the install and update
hooks, and the modifier opcodes queue through it.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PQyBrSj4CZaqMcKc7aW81

…loads

The default template iterator knew about Ember arrays and objects with a
`forEach` method. Both are Ember conventions, so `@ember/array` now
registers them as an iterator extension when it loads. The default
handles native arrays and native iterables.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PQyBrSj4CZaqMcKc7aW81

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PQyBrSj4CZaqMcKc7aW81

The five standard library routines and the default component template
were compiled in the browser on first use, which kept the encoder, the
label patcher, and the component invocation helpers in every bundle.

`bin/build-aot-stdlib.mjs` now compiles them in node and writes the
words to `opcode-builder/stdlib-data.ts`, with the handlers each routine
dispatches and the positions that hold another routine's handle.
`StdlibImpl.handle(routine)` registers the handlers and copies the words
into the heap, resolving fixups first so each routine keeps its own heap
region. A test compares the committed data with a fresh build, so a
change to a routine or an opcode number shows up as a failure that names
the generator.

The same machinery serves templates:

- `lib/aot/record.ts` is an encoder that records words instead of
  writing them to a heap. It notes which words hold constants, stdlib
  handles, and nested block programs, and resolves labels.
- `lib/aot/template.ts` loads a recorded template into a context: it
  interns the constants, patches the words, and returns the handle.
- `template-core.ts` takes its layouts as a parameter. `template-jit.ts`
  supplies the browser compiler; the AOT loader supplies its own.

The default template is the first AOT template, so a context no longer
needs the browser compiler to exist.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PQyBrSj4CZaqMcKc7aW81

`precompileAot` in `@glimmer/opcode-compiler/lib/aot/precompile.ts`
compiles a strict template to VM words at build time. The output has the
shape `precompileModule` already produces (an expression plus the imports
to bind), so the babel plugin needs no change. Lexical scope values and
strict keywords become constants by identifier, evaluated on first use so
a template can reference a class declared later in its module.

Ember's `precompileModule` wrapper now emits AOT output for strict
templates and points the build tool at `@ember/template-factory/aot`.
Loose templates keep the modular JIT path, since they resolve names at
runtime. The build exposes the handler modules and the stdlib data as
entry points, because compiled templates import them directly.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PQyBrSj4CZaqMcKc7aW81

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PQyBrSj4CZaqMcKc7aW81

A strict template resolved `mut`, `{{outlet}}`, and the helpers behind
`{{#each}}` through a keyword list and a built-in table. The AST
transforms now bind each keyword to its import, the way `array` and `fn`
already work, and a JavaScript binding with the same name shadows the
keyword. The runtime compiler supplies the same values through its
keywords object.

The keyword list, the keyword slots in both printers, and the built-in
keyword tables are gone. Loose templates still resolve the names through
the resolver.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PQyBrSj4CZaqMcKc7aW81

The `-each-in` wrapper now iterates itself through a symbol method, and
`@ember/array` extends iteration through the one environment hooks
object, so the iterator extension list and the wrapper module go away.

Loose templates bind their built-ins at build time, the names that
already win over app helpers, so a compiled loose template resolves only
user helpers and components by name. The renderer no longer fills the
built-in tables, the loose factory no longer needs them, and the base
renderer starts with no resolver instead of a lazy delegate. The tables
stay for JSON blocks from published addons and for templates compiled in
the browser.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PQyBrSj4CZaqMcKc7aW81