[FEATURE glimmer-next-demo] Demo app for glimmer-next renderer#21340
Draft
lifeart wants to merge 691 commits into
Draft
[FEATURE glimmer-next-demo] Demo app for glimmer-next renderer#21340lifeart wants to merge 691 commits into
lifeart wants to merge 691 commits into
Conversation
lifeart
changed the title
This was referenced Apr 25, 2026
Closed
The smoke runner loaded smoke-modules.json into explicitModules and then took the early branch that skipped shardFilter/globFilter, so every CI shard ran the full 14-module list — 4x compute for identical results across all 4 shards. Apply both filters after smoke validation so --shard N/M actually splits the list and --filter narrows it. Verified: --shard 1/4=7 mods, 2/4=2, 3/4=3, 4/4=2 (total 14). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
3 tasks
Picks up the merged glimmer-next#216 fixes:
- normalize {{#each}} input for Glimmer iterable parity (Set, Map, ArrayProxy, ForEachable, etc.)
- always emit reactive `index` cell when the body reads it (compiler-gated for perf)
- (has-block)/(has-block-params) emit boolean in attribute & helper-param positions
- copy-dist-to-ember.mjs now targets the matching pnpm store version
Expected smoke shard delta: 49 → ~7 failures per shard (the 6 ember.js-side
each-mutation failures + 1 non-block-with-each remain — covered separately).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…each-rows see new args
When a parent component force-rerenders, its inner {{#each}} block builds a
fresh template subtree into a temp container that is later morphed onto the
live DOM. Each iteration claims a child component from the pool. The pool
match (by row identity or position) was correct, but the descriptor's
rcGet closure captured a getter from the FIRST createRenderContext call —
so `this.item` returned stale row data after the parent re-rendered.
Two fixes, both targeting the WeakMap state that survives descriptor
replacements:
1. updateInstanceWithNewArgs now updates state.currentGetter alongside
argGetters[key], so the rcGet closure's `g = state.currentGetter`
read sees the fresh per-row arg getter even when the descriptor lost
its __gxtRenderCtxArgGetter marker (e.g., via an upstream cellFor
reinstall) and createRenderContext's fast path is skipped.
2. createRenderContext's fast and slow paths both refresh state.currentGetter
(slow path was relying on the closure-captured `getter`, which is frozen
to the first install). The rcGet now reads `state.currentGetter || getter`
so the latest per-row getter wins.
Fixes 4 of the 7 remaining smoke failures:
- Components test: curly components / non-block with each rendering child components
- Syntax test: {{#each}} with native arrays / updating and setting within #each
- Syntax test: {{#each}} with emberA-wrapped arrays / updating and setting within #each
- Syntax test: {{#each}} with array proxies, * / updating and setting within #each (4 variants)
The remaining 3 failures (DOM node stability for stable keys when list
is updated) have a different root cause — morph-based fresh template
render doesn't preserve DOM identity for keyed each items — and are
left for a follow-up.
Smoke results: 330/333 (was 326/333). No regressions.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Auto-format the cb0ede4 diff that landed without `prettier --write`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
In classic mode (GXT_MODE != 'true'), `@lifeart/gxt` now resolves to a no-op shim instead of the full glimmer-next dist. The shim exports every named symbol that @ember/-internals/glimmer/lib/* and the gxt-backend modules import, so the static import graph stays valid without pulling the gxt runtime into the classic bundle. Also wraps the previously-unguarded `cellFor(outletState.outlets, 'main')` in `views/outlet.ts` with a `__GXT_MODE__` runtime check so classic Glimmer-VM never sees a cell-backed accessor for `outlets.main`. GXT mode is unchanged: the alias entry only fires when `useGxt` is false, and the find pattern is anchored (`/^@lifeart\/gxt$/`) so subpath imports like `@lifeart/gxt/glimmer-compatibility` and `@lifeart/gxt/runtime-compiler` continue to resolve to the real dist files even when GXT_MODE is set. Validations: - classic build: succeeds (warnings about touchClassicBridge / registerClassicReactor are pre-existing on the branch). - GXT smoke runner: 330/333 (unchanged from baseline). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…as stub" This reverts commit 1002792.
…ntity
Async $_each updates the DOM on a microtask, which lands AFTER the
synchronous __gxtSyncDomNow → __gxtForceEmberRerender morph fallback
runs. The morph then diffs the new full-template fragment against the
pre-mutation live DOM and clobbers Text node content position-by-position,
destroying the keyed-row identity guarded by assertPartialInvariants
in the each-test "it maintains DOM stability for stable keys when list
is updated" cases. SyncListComponent is identity-preserving and runs
inline with __gxtSyncDomNow, so morph then sees identical DOM and is a
no-op for the keyed rows.
Smoke 333/333; previously failing 3 each-stability tests now pass with
no regressions in toggling-each (39/39), curly components (120/120), or
{{get}} (21/21). Vitest 3785/3785.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This branch sets `globalThis.__GXT_MODE__ = true` in `index.html:112`
unconditionally — there is no "classic mode" on this test harness. The
gxt-backend Vite alias in `vite.config.mjs:152-267` is gated on
`process.env.GXT_MODE === 'true'`. Without that env var set, the build
produces a half-broken dist:
- `__GXT_MODE__` is true at runtime (from index.html), so every
`if (!__GXT_MODE__)` guard skips the classic Glimmer-VM path.
- The gxt-backend Vite alias does NOT apply, so the bundle uses
classic `@glimmer/manager` from node_modules with no GXT
integration.
- Every gxt-aware code path that depends on the alias-resolved
manager runs against an unrelated classic implementation,
producing 4000+ test failures dominated by missing component
wrapper elements ("attr() called on a NodeQuery with 0 elements").
The smoke runner workflows already set GXT_MODE=true correctly. The
Basic Test and variant-tests workflows did not. With GXT_MODE=true
the smoke runner reports 333/333 across all 14 modules; the wider
suite filters report curly components 120/120 and broader Components
filter 1569/1587 (the remaining failures are unrelated to this fix).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
`preserveModules: true` produced ~1000 per-source chunks in the GXT-mode build output. testem-based Basic Test loads the static dist/ via Chrome and waits for `testem.js` to be reachable from the page; with that many script tags the cold-cache page load blew past the 120s `browser_start_timeout`, producing "Browser failed to connect within 120s. testem.js not loaded?" with zero tests run. The setting was added to support the GXT smoke harness. That harness runs against Vite's dev server (`pnpm vite --port 5180`), not a built dist, so the rollup build config is irrelevant to it. Dropping the special case yields a single bundled chunk (~7.5MB / ~1.4MB gzipped) that testem can load fast. Smoke harness path is unchanged. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…Template
Strict-mode `precompileTemplate(src, { scope: () => ({ Foo }) })` was
silently dropping the `scope` thunk: only `scopeValues` reached the
compile pipeline, so `<Foo />` fell through to the kebab-case
registry lookup and emitted a raw `<foo>` element. Closes the
Strict-Mode renderComponent test cluster (~24 testem failures).
Three coordinated changes, all in compile.ts:
1. At precompileTemplate entry, invoke `options.scope()` and merge
the returned names into `scopeValues`. Filter to: names that
actually appear as referenceable identifiers in the template,
excluding `on` (GXT's visitor short-circuits `{{on ...}}`
syntactically — adding it as a binding regresses the textarea
modifier path). A `_templateMayNeedScopeThreading` pre-check
keeps internal Input/Textarea templates byte-identical.
2. In `customizeComponentName`, skip the kebab-case lowering when
the name is a scope binding so the GXT compiler emits
`$_c(Foo, ...)` against the local variable instead of routing
through `$_c('foo', ...)`.
3. Extend the dotted-mustache "not in scope" check to consult
`scopeValues` keys alongside block params, so `{{data.count}}`
no longer throws when `data` is threaded via scope().
Validation:
* GXT smoke runner: 333/333.
* Strict-Mode runner: 250/255 (was ~232/255 pre-fix).
* Textarea / Input / LinkTo runners: green.
* testem CI: 789/808 pass, 15 fail, 4 skip (was 765/808 pass, 39
fail). No textarea regression observed.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…ading
The strict-mode scope() callback merge in precompileTemplate was gated by
_templateMayNeedScopeThreading, which only fired when the template had a
PascalCase tag or a free-identifier mustache head. Templates whose only
mustache was `{{on "evt" (fn handler arg)}}` slipped through:
- The mustache head `on` is skipped (the visitor short-circuits {{on}})
- There is no PascalCase tag
- The SubExpression `(fn handler arg)` was never inspected
Result: `handler` and `fn` were never merged into scopeValues, the GXT
compiler emitted `$__fn(this.handler, ...)` (resolving against `this`,
not the strict-mode scope), and the click handler was a no-op.
Extend the gate to also scan for SubExpression heads `(ident ...)`. The
existing `_scopeNameAppearsAsReference` filter still prunes scope entries
the template never references, so loose / Input / Textarea templates stay
unaffected. Fixes the two `Strict Mode - built ins: Can use on and fn` and
`Strict Mode - renderComponent - built ins: Can use on and fn` tests.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…curried-helper
The GXT-mode `template()` runtime compiler in
@ember/template-compiler/runtime had two latent gaps that the
Strict-Mode - Runtime Template Compiler suite exercises but the
strict-mode `precompileTemplate` scope-merge work did not cover:
1. `Can use \`this\` from explicit scope` — when the user provides
`scope: () => ({ this: state })`, the binding was passed verbatim
as a `scopeValues.this` entry. The GXT compiler still emitted
literal `this.X` references against the rendering context, so the
user's `state` object was never reached. Pre-rewrite `{{this.X}}` /
`(this.X` / `<this.X` path heads to a non-keyword alias
(`__gxtExplicitThis`) and rebind that alias in `scopeValues`, so
GXT compiles the access as a normal binding-path lookup.
2. `Can use a curried dynamic helper` (implicit form) — direct `eval()`
in the test method's lexical scope was resolving `helper` to a
leaked module-level `let helper;` declared by the in-element
null-check helper in the same bundle. The implicit form's free-name
extractor then bound `helper` as a scope value, suppressing the
strict-mode `helper` keyword path. Filter `helper` and `modifier`
from `_extractScopeFromEval` so the keyword path always wins for
the implicit form. Users who genuinely want to shadow them can do
so via the explicit `scope` form.
Also defensively strip a stray `this` entry from the implicit form's
extracted scope, so a class-form template using `eval()` plus
`component: this` cannot accidentally have its rendering context
rewritten.
Validation:
- testem Basic Test: 15 fail -> 12 fail; both target tests now pass.
- Smoke 333/333 unchanged.
- No regression in any previously-passing test.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…ven syncs The destroy unclaimed-pool sweep can mistakenly identify newborn instances as "removed by morph" during initial render (when no property change drove the sync). When the user's destroy() throws in those spurious cases, the renderer's wrappedDestroy patch still routes the error into _renderErrors, which a later flushRenderErrors() re-throws out of runAppend — surfacing as "Died on test #1" before the test can run its assertions. Mirror __gxtHadPendingSync into __gxtSyncIsPropertyDriven at __gxtSyncDomNow start (the original is cleared by __gxtForceEmberRerender's finally before the destroy phase runs). When this flag is false, gate the capture path via __gxtSuppressDestroyCapture so destroy/lifecycle throws stay swallowed by the existing Phase 1-3 local try/catches. Restores 4/4 in "Errors thrown during render" and keeps smoke 333/333. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…ts don't bleed into application
The shared `<ember-outlet>` element calls `tpl.render(nestedContext, this)`
without first swapping `globalThis.owner`. When the nested outlet's owner is
an engine instance (different from the application owner), curly bare
identifiers like `{{ambiguous-curlies}}` resolve via `$_maybeHelper`, which
reads `globalThis.owner` to call `factoryFor('component:...')` — picking up
the application's registry instead of the engine's. A template registered in
BOTH the application and the engine therefore resolved engine-scoped
component refinements against the application owner, leaking application
state into the engine's render output.
Save the previous `globalThis.owner`, swap to the nested outlet's render
owner for the duration of `tpl.render`, and restore it in the finally block.
This matches the analogous swap already present in `gxt-backend/outlet.gts`'s
EmberOutletElement implementation.
Fixes the two failing 'has separate refinements' tests in
`Application test: engine rendering` (20/20 pass; smoke 333/333).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
GXT's runtime template factory returns a fresh wrapper object on every `templateFactory(owner)` invocation, and `buildRenderState` calls the factory on each route render. The root-outlet re-render fast-path used strict object identity (`lastRouteTemplate !== newTemplate`) to detect a template swap, so even renders of the SAME route template were treated as a swap and forced a full re-render (innerHTML = ''). That destroyed DOM node identity across `/colors/red -> /colors/green` style transitions and broke the "stable DOM when the model changes" invariant. Compare the underlying `_templateFn` (the compiled function shared across fresh wrappers) so two wrappers around the same template stay on the in-place fast-path. Falls back to object identity for non-runtime templates so the test-helpers fresh-compile case (different `_templateFn`) still triggers a full re-render. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
_renderComponentGxt registers a reactor in _classicReactors (validator.ts)
and tries to unhook it via registerDestructor(owner, doDestroy). When the
caller passes a synthetic owner ({} — the documented default for the
renderComponent API), registerDestructor silently fails (plain objects
are not destroyable), so the reactor outlives its test.
On the next test's classic-tag dirty (e.g. typing in a textarea, swap of
a dynamic component, or any @Tracked write), the leaked reactor fires
_doRender against the prior test's detached target and triggers
__gxtSyncDomNow, which clobbers the active test's DOM through the
shared force-rerender path.
Symptom cluster on testem (single-page run, modules load sequentially):
- <Textarea> / {{textarea}} cut/input/change tests
- curly didReceiveAttrs deprecation
- dynamic component swap-out destroy
- error recovery during initial render
- renderComponent siblings (1 of 2)
- browser timeout 1200s after the textarea cluster wedges sync state
All affected modules pass in isolation; the failures are pure
cumulative-state leak symptoms. __gxtCleanupActiveComponents already
clears every other module-level Set/Map between tests; _classicReactors
is the one that was missing.
Fix: expose __gxtClearClassicReactors from validator.ts and call it
from __gxtCleanupActiveComponents. Smoke (14 modules / 333 tests)
passes; affected modules pass individually.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This reverts commit 401df7b.
_renderComponentGxt registers a classic reactor (validator.ts:_classicReactors)
to re-render on classic-tag dirty, and tries to unhook it via
registerDestructor(owner, doDestroy). When the caller passes a synthetic
owner ({} — the documented default for the renderComponent API),
registerDestructor silently fails on the plain object, leaving the
reactor live across tests. On the next test's classic-tag dirty (e.g.
typing in a textarea, swap of a dynamic component, or any @Tracked
write), the leaked reactor fires _doRender on the prior test's detached
target and clobbers shared GXT sync state via __gxtSyncDomNow.
Symptom cluster on testem (single-page run, modules load sequentially):
- <Textarea> / {{textarea}} cut/input/change tests
- curly didReceiveAttrs deprecation
- dynamic component swap-out destroy
- error recovery during initial render
- browser timeout 1200s after the textarea cluster wedges sync state
A first attempt to drain the global Set between tests (commit 401df7b,
reverted) was wrong: LinkTo also registers reactors there which need to
persist across testStart boundaries within a module — wiping them broke
~700 unrelated tests.
The right fix is per-reactor self-unsub via element-attachment grace,
mirroring renderLinkToElement in gxt-backend/manager.ts:9469-9520:
- Track _hasBeenConnected: once the target has been seen connected,
flip the flag.
- On detached firings after _hasBeenConnected, count grace ticks; at
>4 ticks self-unsub and mark destroyed.
- Pre-connection (never seen connected) still fires normally so the
"can render in to a detached element" test continues to pass.
Smoke (14 modules / 333 tests) green; renderComponent module 25/27
matches the pre-existing siblings-cluster baseline.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds opt-in diagnostic logging behind globalThis.__GXT_LEAK_DEBUG__
(force-enabled in index.html for this CI run; revert once diagnosed).
Instrumentation:
- validator.ts: tags every classic reactor with {id, source, registered-
AtTest} via WeakMap. _fireClassicReactors logs cross-test fires as
"LEAK reactor #N src=… regAt=… firedIn=…". __gxtLeakSnapshot dumps
the live reactor population grouped by source/origin-test.
- renderer.ts: tags _renderComponentGxt's reactor with source=
"_renderComponentGxt".
- manager.ts: tags renderLinkToElement's reactor with source=
"renderLinkToElement"; logs every cache-HIT __syncFromUpstream call
with the live/upstream textarea values — the actual clobber site
identified for the Textarea cluster.
- index.html: snapshots the reactor Set at testStart / testDone so
growth between adjacent tests is visible.
Also adds scripts/gxt-test-runner/leak-debug.mjs — a Playwright helper
that opens the dev server, captures browser console.log output, and
prints "[leak-debug]" lines so the multi-module cumulative-state run
can be reproduced locally without testem.
This is a debugging commit, not a fix. Prior 14+ attempts treated the
classic-reactor leak as the root cause but neither global drains nor
self-unsub via isConnected/marker tracking improved the failing 8
testem tests; the actual leak source still needs to be identified
from CI evidence.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Diagnostic instrumentation (commit 34f9515) confirmed that the cumulative-state failures in testem CI are driven by leaked classic reactors crossing test boundaries. Two specific patterns: - renderLinkToElement (manager.ts:9519) leaks routing-test reactors whose existing _disconnectedTicks > 4 self-unsub never trips, because routing tests reattach the same anchor across transitions and the counter resets each time. - _renderComponentGxt (renderer.ts:2126) leaks renderComponent reactors whose self-unsub fix (commit 6ee5180) never trips, because targetElement is typically #qunit-fixture which stays connected across tests; testem only clears its children. Local reproducer (scripts/gxt-test-runner/leak-debug.mjs) showed a single leaked reactor firing 9,391+ times across unrelated tests. Fix: tag each reactor at registration with the QUnit test it was created in. In _fireClassicReactors, reactors whose registeredAtTest differs from the current test's name are unconditionally invalid (no real-app reactor legitimately survives a QUnit test boundary) and we self-unsubscribe before invoking them. Module-init and pre- QUnit reactors (registeredAtTest === <no-test>) are exempt and fire normally. Result on the local cumulative reproducer: 550 leaks intercepted and drained at the first cross-test fire; reactor population returns to 0 between tests; the runaway 9,391-fire reactor no longer exists. Smoke (14 modules / 333 tests) green. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…ire time" This reverts commit 276a1a4.
…ire time Diagnostic instrumentation (commit 34f9515) confirmed two leak paths: - renderLinkToElement (manager.ts:9519) reactors leak across tests because the existing _disconnectedTicks > 4 self-unsub never trips: routing tests reattach the same anchor across transitions, resetting the counter. - _renderComponentGxt (renderer.ts:2126) reactors leak because the self-unsub fix (commit 6ee5180) never trips — targetElement is usually #qunit-fixture which stays connected across tests; testem only clears its children. Local cumulative reproducer showed a single leaked reactor firing 9,391+ times across unrelated tests. Previous attempt (commit 276a1a4, reverted): drop reactors at fire time when registeredAtTest != currentTest. That regressed ~700 CI tests because Ember's classic reactivity can fire reactors during transient states (afterEach destruction, router setup) where QUnit.config.current is briefly inconsistent with the test that owns the work. This fix: tag each reactor at registration with the QUnit test name, then drain that test's reactors in BULK at testDone — when the test is fully torn down, no reactor of that test is needed in any later test, regardless of QUnit.config.current's instantaneous value. Module-init reactors (registeredAtTest === <no-test>) are exempt. Local validation: 150 DRAIN events at testDone boundaries, each returning the reactor population to 0; 0 cross-test LEAK fires observed in the diagnostic snapshot. Smoke (14 modules / 333 tests) green. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…not at fire time" This reverts commit 6deded4.
Two-line whitespace fixes flagged by CI Linting (lint:format). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Three idiomatic hooks for the classic-tag reactor leak path that diagnostic instrumentation (commit 34f9515) confirmed: 1. renderLinkToElement (manager.ts:9519): the LinkTo instance owns the reactor's lifetime. Eager unsub via Phase 0 of __gxtDestroyTrackedInstances + willDestroy override on the instance. The Phase 0 path matters because Ember's classic destroy chain is async via the runloop, and willDestroy can fire too late to prevent the reactor from leaking across the testStart/testDone boundary. 2. _renderComponentGxt (renderer.ts:2287): split doDestroy into cleanupReactor (reactor unsub only, no DOM) and full doDestroy (also wipes innerHTML). Caller-invoked result.destroy() runs the full path; owner-destruction cascades fire only the reactor cleanup so a synthetic owner's destroy doesn't wipe a target the caller still needs. 3. _gxtPendingRenderCleanups (renderer.ts): a global Set drained by __gxtCleanupActiveComponents (the existing cleanup hook fired by QUnit testStart and test-case afterEach). This is the layer that actually catches the synthetic-owner case: the renderComponent API documents `owner = {}` as the default, that synthetic plain object is never in any destroy chain, so registerDestructor on it records the destructor but it never runs. The pending-cleanup set fires eagerly at known cleanup boundaries regardless. For renderer.ts the wiring also includes the standard associateDestroyableChild(parentOwner, syntheticOwner) so that callers who DO destroy their owner properly cascade through the synthetic. That's the same pattern as the classic GlimmerVM render path (line 2330) — kept for callers with real destroyable owners. Diagnostic instrumentation remains in the branch (commit 34f9515) behind __GXT_LEAK_DEBUG__. Force-enable still set in index.html for this CI run; will be flipped off once CI confirms the fix. Smoke (14 modules / 333 tests) green. Local cumulative reproducer shows leak count reduced significantly (LinkTo source from runaway to bounded; renderComponent source partially drained — testem CI tests will show whether the remaining tail still causes test failures vs the prior 8-failure + browser-hang baseline). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…chains" This reverts commit ef6ce28.
…s on test teardown Last Custom Modifier Manager failure: `can give consistent access to underlying DOM element` expected 4 assertions but got 3 — the assertion inside the modifier's destroy hook never fired. Root cause: The custom-modifier-path destructor (manager.ts ~L9950) pushes its entry onto `_pendingModifierDestroys`, which is drained in compile.ts Phase 2d only when `entry.element.isConnected === false`. At test-teardown the rendering harness destroys the wrapper *before* detaching its DOM, so the isConnected gate keeps the entries pinned and the user's `destroyModifier(instance)` (which fires `willDestroyElement`) is never invoked. Fix: Add a Phase 1b sweep to `_gxtDestroyTrackedInstances` (the test- teardown hook) that iterates `$_MANAGERS.modifier._updatedInstances` and calls `mgr.destroyModifier(instance)` on every still-live custom modifier. Guards with the existing `__gxtModDestroyed` flag so the subsequent disconnected-element drain in compile.ts Phase 2d is a no-op. Errors propagate through `captureRenderError` (no silent swallowing per CLAUDE.md rule). Verified: - Custom Modifier Manager: 22/23 -> 23/23 (+1) - smoke 333/333, "Errors thrown" 4/4, "Tracked Properties" 36/36, "computed" 148/148, "Lifecycle" 42/42 — all 5 non-render gates at baseline. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…) + per-test timeout The Component Tracked Properties canary (`tracked properties rerender when updated outside of a runloop`) has a setTimeout(100ms) -> assert at +200ms race. After ~800 cumulative tests, GXT revalidation pipeline slowdown causes the assertion to race indefinitely; chromium renderer spins at 100% CPU until force-killed. Mitigations in runner.mjs: - Chromium --js-flags=--expose-gc + periodic window.gc() between tests (every --gc-interval tests, default 50, via QUnit.testStart hook). Falls back gracefully (debug-warn once) when gc() is unavailable. - Per-test progress watchdog in the poll loop: if no QUnit assertion or testDone fires for --per-test-timeout ms (default 30000), abort the gate and treat the stuck test as a timeout. Records the stuck-test name for the failure report. - page.evaluate races against a 5s timeout; an unresponsive renderer (spinning at 100% CPU, never yielding a JS slot) is treated as a stuck-renderer signal that also aborts the gate after per-test-timeout. - ctx.close() races against a 5s timeout with a fallback that closes pages individually -- prevents the cleanup itself from hanging on a renderer that's still spinning. - Stuck-timeout reports surface the last successfully-polled QUnit stats (e.g. "partial 1116/1117") instead of "0/0" when the post-loop evaluate also times out. Verified: render gate (40 modules, per-module-isolated) completes in ~53s -- 981/981. Cumulative single-page modes that previously hung indefinitely now abort gracefully within ~90-100s with the stuck-test identified. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The "Clear GXT VM internal maps" block at compile.ts:8195-8215 references
getVM and getRenderTree which are tree-shaken from production builds via
the IS_DEV_MODE guard at glimmer-next/src/core/reactive.ts:75. Since tests
use the production GXT bundle (@lifeart/gxt/dist/), these globals are
never defined — the block was guaranteed-dead code (typeof === 'function'
always false).
Discovered during the canary timing-race root-cause investigation: probe
confirmed 0 effect on cumulative state. The block existed as a defensive
attempt to prevent memory growth, but the actual accumulator (QUnit's
reporter UI + per-test assertion records) is architecturally non-removable.
Also cleans up a silent catch{} that violated CLAUDE.md no-silent-swallow
rule (now moot via removal).
Verified: smoke gate 120/120 unchanged; runner completes cleanly.
…XT_MODE
All ~25 keyword helper modules (or/and/eq/gt/gte/lt/lte/neq/not/array/
hash/fn/element, including each `(runtime)` variant) failed in the JIT
integration test path with `TypeError: Cannot read properties of
undefined (reading '0')` at `unwrapHandle`. 132 tests blocked at 0/N.
Root cause: under `__GXT_MODE__`, `@ember/template-compiler#template`
attaches a GXT-compiled template (created by the GXT runtime compile
pipeline, see `@ember/-internals/gxt-backend/compile.ts`) to the
returned component via `setComponentTemplate`. That template's
`asLayout().compile()` returns `{ handle, symbolTable }` — an object,
NOT the numeric handle that Glimmer's `unwrapHandle` expects. The
opcode runtime falls into the error branch (`handle.errors[0]`) and
crashes because `errors` is undefined.
Fix: in `JitRenderDelegate.renderComponent`, when the attached
template is a GXT factory (marked `__gxtCompiled`), dispatch through
the GXT renderer (`factory(owner).render(ctx, element)`) instead of
the Glimmer opcode runtime. This mirrors what `GxtRehydrationDelegate`
already does in `compileAndRender` for rehydration suites, reduced to
the minimum needed for `jitSuite` (no inline-expansion, no rehydration
markers — the keyword tests are single-template `templateOnly()`
components with their scope captured at compile time).
Verified:
- keyword helper modules: 0/132 → 58/132 (44%). All 26 modules now
RUN; remaining failures are real test-content issues (lazy-eval
semantics, error-message regex, and unrecognized keywords
gt/gte/lt/lte/neq) — not the structural undefined-handle bug.
- All 5 non-render gates remain at baseline:
smoke 1/1
Errors thrown 4/4
Tracked Properties 36/36
computed 148/148
Lifecycle 42/42
- `TemplateOnly` (13/13) and `Syntax test:` (698/698) unaffected,
confirming the non-GXT-mode Glimmer code path is untouched (the
new branch is gated on `__GXT_MODE__` and on the factory carrying
the `__gxtCompiled` marker).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…helper Root cause: commit 176b87e removed the `RenderingTestCase#registerComponent` helper as part of unifying test infrastructure on `precompileTemplate`, but the GXT-specific `packages/demo/src/tests/ember-tests.ts` integration suite still calls `this.registerComponent(name, { template, ComponentClass? })`. All 18 tests across the three "GXT Integration -" modules died with `this.registerComponent is not a function`. Fix: introduce a local `RegisterableRenderingTestCase` subclass in the demo test file that restores the helper with the legacy semantics. Default `ComponentClass` to the curly `Component` so the rendered output carries the expected `<div class="ember-view">` wrapper that `assertComponentElement` defaults to; subclass when the caller's class is the base `Component` to avoid re-setting a template on it. All three integration moduleFor classes now extend the local helper. No other test files or shared infrastructure touched. Verified: - GXT Integration - AngleBracket Invocation 0/13 -> 13/13 (+13) - GXT Integration - Component Args 0/3 -> 3/3 (+3) - GXT Integration - Nested Components 0/2 -> 2/2 (+2) - 5 non-render gates at baseline: smoke 1/1, Errors thrown 4/4, Tracked Properties 36/36, computed 148/148, Lifecycle 42/42 Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…eturn value Same pattern as commit 4501f69 (trackedMap delete): the three sibling class-based impls (TrackedSetImpl, TrackedWeakMapImpl, TrackedWeakSetImpl) all returned `true` when delete() was called with a non-existent key/value. Per spec and the upstream Proxy-based reference impls (packages/@glimmer/validator/lib/collections/{set,weak-map,weak-set}.ts), Set/WeakMap/WeakSet `.delete()` must return false when the value/key did not exist. Corrected all three to return false in that branch. Verified with safe runner: - trackedSet: 16/17 -> 17/17 (+1) - trackedWeakMap: 4/5 -> 5/5 (+1) - trackedWeakSet: 3/4 -> 4/4 (+1) 5 non-render gates at baseline: - smoke: 333/333 - Errors thrown: 4/4 - Tracked Properties: 36/36 - computed: 148/148 - Lifecycle: 42/42 Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Two `getHtml()` paths used `String(raw)` directly, which throws "Cannot convert object to primitive value" for objects with no `toString` method (e.g. `Object.create(null)`). Mirror the behavior of `_normalizeStringValue` by checking for a callable `toString` before stringification and falling back to ''. Recovers: "Dynamic content tests (trusted)" 148/149 -> 149/149. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…Z-traps
When a strict-mode template's `scope: () => ({ globalThis })` (RFC#1070)
threads `globalThis` itself into scope, the emitted
`const globalThis = globalThis["..."]["globalThis"]` declaration would
hit a temporal-dead-zone error because the RHS reference resolved to
the about-to-be-declared local.
Capture `globalThis` into `__gxtGT` at the top of the outer factory
(outside the `return function () { ... }` closure where scope injections
land) and use `__gxtGT` on the RHS of scope-injection declarations.
Recovers:
Strict Mode - Runtime Template Compiler (explicit) - allowed globals from RFC#1070 27/28 -> 28/28
Strict Mode - Runtime Template Compiler (implicit) - allowed globals from RFC#1070 27/28 -> 28/28
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…der GXT
`equalsElement` (used by `assertEmberishElement` /
`assertElementShape`) only stripped GXT's `<!---->` placeholder
comments from the actual HTML, leaving the expected string
untouched. Tests whose expected literal contains `<!---->`
(classic Glimmer-VM cursor for an empty conditional branch
like `{{#if X}}{{yield}}{{/if}}` with X=false) failed because
GXT does not emit the marker — the asymmetric strip erased
the actual side while preserving the expected side.
Strip `<!---->` from BOTH the expected and actual strings
under GXT mode so the comparison is structurally consistent:
tests that include the marker in expected pass when GXT omits
it, and tests that omit the marker continue to pass when GXT
happens to emit one. No behavior change outside GXT mode.
Recovers (12 tests):
[integration] jit :: Components :: yield 39/42 -> 42/42
[integration] jit :: Components :: yield > Curly 14/15 -> 15/15
[integration] jit :: Components :: yield > Dynamic 14/15 -> 15/15
[integration] jit :: Components :: yield > Glimmer 11/12 -> 12/12
[integration] jit :: Components :: Emberish 33/36 -> 36/36
[integration] jit :: Components :: Emberish > Curly 14/15 -> 15/15
[integration] jit :: Components :: Emberish > Dynamic 14/15 -> 15/15
[integration] jit :: Components :: Emberish > Glimmer 5/6 -> 6/6
[integration] jit :: [curly components] scope 12/13 -> 13/13
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The Glimmer keyword helpers `gt`, `gte`, `lt`, `lte`, `neq` live in
`@glimmer/runtime` and are re-exported via `@ember/helper`, but GXT's
template compiler does not recognize them natively (unlike `eq`, `and`,
`or`, `not`, which map to GXT's `$__eq`, `$__and`, `$__or`, `$__not`
opcodes). For unrecognized bare identifiers like `{{gt a b}}`, GXT
emits `$_maybeHelper("gt", [a, b], this)`. The Ember-mode strict-shadow
in compile.ts:15527 then checks `__EMBER_BUILTIN_HELPERS__` — and
because the names were missing, every invocation threw "not in scope".
Fix: Add minimal binary comparison entries to `__EMBER_BUILTIN_HELPERS__`
that mirror the Glimmer-runtime helper bodies (incl. arg-count throw so
the `'throws if not called with exactly two arguments'` tests pass).
Args arrive pre-unwrapped via `unwrapArgs` (ember-gxt-wrappers.ts:835),
so the helpers receive plain values.
Verified:
- keyword helper: gt 1/7 + 1/4 = 2/11 → 5/7 + 2/4 = 7/11 (+5)
- keyword helper: gte same shape → +5
- keyword helper: lt 1/7 + 1/4 = 2/11 → 5/7 + 2/4 = 7/11 (+5)
- keyword helper: lte same shape → +5
- keyword helper: neq 1/6 + 1/4 = 2/10 → 5/6 + 3/4 = 8/10 (+6)
- smoke gate: 333/333 modules green (unchanged)
Remaining failures in these modules are the same family-wide patterns
already present in `eq`/`and`/`not` (implicit-scope-eval picks up
shadow bindings; `assert.throws` regex still expects the throw to be
captured via a different mechanism). Those are separate from the
scope-resolution bug fixed here.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…cade
Two distinct bugs in the GXT-side `@glimmer/destroyable` shim:
1. **"parent can be an array"** — The `iterate(collection, fn)` helper
treated *any* `Array` as the internal "collection of multiple
destroyables" container, walking its elements. When the user
registered an actual array (e.g. `['a']`) as a destroyable parent,
the subsequent `removeChildFromParent` called
`getDestroyableMeta('a')` and crashed with
`TypeError: Invalid value used as weak map key` (strings cannot
be `WeakMap` keys). Upstream `@glimmer/destroyable` brands its
internal arrays with a Symbol to avoid exactly this — restore that
brand here (`_BRANDED_ARRAY` + `_isBrandedArray` + `_brandArray`).
2. **"parent no longer references child after cascaded destruction"** —
`removeChildFromParent` guarded child-cleanup on
`parentMeta.state === LIVE_STATE`. When `destroy(parent)` cascades,
the child's `scheduleDestroyed` callback fires while the parent is
`DESTROYING_STATE`, so the cleanup was skipped and the parent
retained a stale strong reference to the destroyed child, blocking
GC. Mirror upstream commit 35438ae: gate on
`state !== DESTROYED_STATE` so the cleanup fires during cascade.
Verified:
- Destroyables 22/24 → 24/24 (+2)
- smoke gate 333/333 modules green (unchanged)
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
GXT's shipped $__and/$__or/$__not/$__eq return booleans instead of
first-truthy/first-falsy values and do not throw on wrong arg counts,
breaking the upstream Glimmer keyword tests under
packages/@glimmer-workspace/integration-tests/test/keywords/.
Override the four operators on globalThis after setupGlobalScope() to
restore Ember semantics:
- and: short-circuit; return first falsy value, else last; throw if <2
- or: short-circuit; return first truthy value, else last; throw if <2
- not: throw if !=1 arg; return boolean negation
- eq: throw if !=2 args; return strict-equality boolean
Empty arrays are treated as falsy to match Ember conditional semantics.
Asserts route through getDebugFunction('assert') so expectAssertion can
intercept; falls through to a thrown Error if no debug assert is wired.
Recovers +10 tests in the keyword helper cluster (and, or, not, array, +
partial gt/gte/lt/lte/neq paths). Smoke gate 333/333 green.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The Glimmer keyword helpers gt/gte/lt/lte/neq receive args as zero-arity
getter functions when invoked in SubExpression position (e.g.,
{{if (gt this.a this.b) ...}}). Comparing `function > function` always
returns false, causing the `if` branch to take the wrong path.
Unwrap getters defensively at the helper boundary and route the wrong-
arity throw through getDebugFunction('assert') so expectAssertion can
intercept (mirrors the unbound/mut helpers' assert path).
Recovers +5 tests (the `throws if not called with exactly two arguments`
case for gt/gte/lt/lte/neq). Smoke gate 333/333 green.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The implicit eval-mode scope extractor in @ember/template-compiler
(_extractScopeFromEval) was unconditionally filtering identifiers that
collide with HTML tag names (a, p, li, div, ...). That meant templates
like `{{if (and a b) "yes" "no"}}` with `eval(name)` resolution never
saw `a` as a candidate to extract — `a` would be filtered as an HTML tag
name even though it appears in subexpression position, not as an HTML
element-name.
Apply the HBS-syntax-word filter only when the identifier is in actual
HTML element-name position (preceded by `<` or `</`, modulo whitespace).
In mustache or subexpression context, the same name is a real variable
reference and must be resolved via eval().
Recovers +13 tests across the `implicit scope (eval)` cases for the
and/or/eq/gt/gte/lt/lte/neq/not keyword families. Smoke gate 333/333.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The modifier manager's handle() short-circuited when (globalThis as any)
.owner was absent. For built-in modifiers like {{on}}, which are
registered through setInternalModifierManager and don't need an Ember
container, this prevented strict-mode keyword-modifier tests (run
through the GXT-mode delegate path with no Ember application
bootstrapping) from ever attaching event listeners.
Detect built-in modifier names via the modifier manager's own
`_builtinModifiers` registry; for those, proceed with the install/update
path without an owner. Resolve the modifier class directly from
`_builtinModifiers` instead of `owner.factoryFor(...)`. Custom modifiers
remain owner-gated.
Recovers +4 tests across the `keyword modifier: on` jit and runtime
suites. Smoke gate 333/333.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…fect
Drops the `_effectCallCount` / `_effectId` `console.log('[DBG-MSG]', ...)`
block from the text-position mustache effect — leftover from an earlier
diagnostic pass. The effect body remains otherwise identical (no
behavior change).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The JIT delegate's renderGxtComponent bypass created a bare
`Object.create(null)` as the render context, but tests using
`template(..., { component: Foo })` with a `GlimmerishComponent`
subclass need an actual instance — their templates reference
`this.a`, `this.b`, etc. as instance fields.
When the component arg is a class (typeof 'function'), instantiate
it via `new Ctor(undefined, args)` matching GlimmerishComponent's
ctor signature and use the instance as ctx. Non-class components
(templateOnly() returns an instance, typeof 'object') keep the
previous bare-object ctx path.
Recovers 8 keyword-helper runtime tests: gt/gte/lt/lte/neq/fn/eq
"no eval and no scope" + array (runtime) "no eval and no scope".
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The text-position effect at L16525 was calling `item()` twice on the
first render: once at L16087 (type-detection path) and once inside
gxtEffect's synchronous first run. For user helpers with observable
side effects — e.g. `{{capture (hash …)}}` where capture is a test
spy that records steps — this dispatched the helper a second time
before any state change, breaking assertion.verifySteps counts.
Reuse the cached `finalResult` from the outer type-detection call on
the effect's first run; only re-invoke item() on subsequent invalidations
when state has actually changed. Dependency tracking is preserved
because cell reads inside item() already registered with the active
formula frame during the outer call.
Recovers 8 keyword-helper tests: 6 hash double-step failures
("it works", "it works with implicit scope form", "it works as a
MustacheStatement", and the 3 matching runtime variants) plus the
and/or "references are lazy" pair which shared the same root cause.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…r dispatch
Custom managers built with `componentCapabilities('3.13', {})` (or any
options bag that omits the `updateHook` key) end up with
`capabilities.updateHook === false` under classic Glimmer semantics —
but GXT's shim used to return the raw options object verbatim, leaving
`updateHook` undefined and silently coercing to "always dispatch
updateComponent" at the rerender path.
Two pieces:
1. `componentCapabilities('3.13', opts)` now canonicalizes its return
value to `{ asyncLifecycleCallbacks, destructor, updateHook }` as
explicit booleans whenever opts is provided. When opts is omitted
entirely, return `{}` so the lifecycle gate can distinguish "user
explicitly opted out" from "user accepted the default".
2. The rerender-path updateComponent dispatch at L10549 now skips the
call when `caps.updateHook === false` — i.e. only the explicit opt-out
path. Undefined still passes through (preserves BasicComponentManager
tests that rely on default-dispatch).
Recovers "updating arguments does not trigger updateComponent or
didUpdateComponent if `updateHook` is false" in Component Manager -
Angle Invocation without regressing the basic-manager "arguments are
updated if they change" cases in Curly / Angle Invocation.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The `(fn func ...args)` helper returns a closure that callers (modifiers, event handlers) are expected to invoke later with extra args. When this closure is passed as a named component arg — e.g. `<Child @callback={{fn greet "hello"}} />` — the `$_c_ember` wrapper's value-descriptor unwrap loop eagerly invokes the closure at args-read time because it lacks any of the recognized "do not unwrap" tags (__isCurriedComponent / __isFnHelper / __isMutCell / __isEmberCurriedHelper). That eager call returns `greet("hello")` (i.e. `undefined`), which is then forwarded as `@callback` to Child — causing `{{on "click" @callback}}` to throw "You must pass a function as the second argument to the on modifier". Tag the curried fn result with `__isFnHelper` (the existing skip-marker that `hash`/`(fn ...)` SubExpression callers already honor) so the unwrap loop stops at the closure boundary and forwards the callable through. Unblocks `keyword helper: fn :: it works as a MustacheStatement` (+1 test); 333/333 smoke gate unchanged.
Two compile-time replacements blindly swapped the scope-bound `on` value
with the GXT-bundled built-in:
1. The `transformOnModifierHashArgs` pre-pass rewrote every `{{on ...}}`
element-modifier mustache to `{{on-ext ...}}` (the alias that resolves
through `_builtinModifiers['on']`) — regardless of whether the
template's strict-mode scope shadowed `on` with a user-defined
modifier definition.
2. The scope-injection normalizer replaced any non-function `scopeVals['on']`
with `__EMBER_BUILTIN_HELPERS__['on']` — but `setModifierManager(() => mgr, {})`
returns a non-function object, so user shadows were indistinguishable
from the canonical Glimmer-VM `on` and got clobbered.
Both replacements now compare by identity against the canonical `on`
recorded in `$_MANAGERS.modifier._builtinModifiers['on']`. User shadows
fall through unchanged so the in-template `on` resolves to the user's
modifier definition.
No test count change today (the only direct user of this path —
`keyword modifier: on :: can be shadowed` — still trips a downstream
"null is not a function" on the user manager's undefined-returning
createModifier; tracked separately). 333/333 smoke gate unchanged;
30/30 `{{on}} Modifier` regression suites unchanged.
…scope
The implicit-form scope extractor (`_extractScopeFromEval`) only matched
lowercase identifier heads via the existing patterns
(`componentPattern`, `mustachePattern`, `subexprPattern`,
`bareIdentPattern`). For templates whose mustaches reference an
uppercase dotted path — e.g. `{{JSON.stringify (array ...)}}` — neither
`JSON` (uppercase head) nor `JSON.stringify` (dotted name) made it into
the scope. The compiled template then emitted a string-name resolution
`$_maybeHelper("JSON.stringify", ...)` which the strict-mode shadow
rejected with "Attempted to resolve `JSON.stringify`, which was expected
to be a component or helper".
Add a `dottedExprPattern` that captures the head of any `[A-Za-z]` dotted
path appearing in mustache or subexpression position. The existing
`_GXT_KEYWORD_NAMES` filter still gates final inclusion in scope, and
the existing dotted-head pattern for tag positions
(`<state.component />`) is left untouched.
Unblocks 2 tests: `keyword helper: array (runtime) :: implicit scope`
and `implicit scope (shadowed)`. 333/333 smoke gate unchanged;
26-module `keyword helper` regression set up from 129/132 → 131/132.
…ll through to full re-render Application test: rendering 13/18 → 14/18 (+1 test, +4 assertions). Root cause: the rerenderForThisRoot fast-path in `templates/root.ts` updates the args/ctx model cells in-place and calls `syncDomNow()`, but the cell value change does not reliably propagate to text-binding formulas (observed: `[@model: red]` persists in DOM even after `cellFor(argsObj, 'model').value` reads as the new `'yellow'` reference). Three failure modes were observed: 1. Phantom rerender: between the controller's `set(controller, 'model', x)` propagation (which updates the renderContext cell via `__gxtComponentContexts` to the fresher value) and the next `setOutletState`, the renderer tag-revalidate loop fires another `rerenderForThisRoot` with the STALE outletRef. The fast-path overwrote the ctx cell back to the stale model. Detected via reference equality against `lastPropagatedModel`; phantom rerenders now skip cell updates. 2. Model object swap (e.g. revisit `/red` → `/yellow`, exterior `set(ctrl, 'model', ...)`): cell-only updates were observed to leave the DOM stale. Detected via `newModel !== lastPropagatedModel`; falls through to the full re-render path. 3. Interior model mutation (`set(model, 'color', 'blue')`): same object reference, but the shallow shape changed. Detected via a `JSON.stringify` snapshot diff; also falls through to the full re-render path. Tradeoff: the "stable DOM when model changes" test now exercises a full re-render (instead of the cell-only happy-path) so DOM-node identity is not preserved for that one assertion. Net: 1 test gained, 0 lost. Verified: smoke 333/333, "Errors thrown" 4/4, "Tracked Properties" 36/36, "computed" 148/148, "Lifecycle" 42/42 — all gates green at baseline. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Closes the cell→DOM propagation gap for controller-bound writes: SyncCore + _walkRenderContexts updates cells on the renderContext correctly when set(controller, 'model', x) (or model.color = 'blue' for a tracked interior mutation) fires, but the outlet template's text-binding effects don't always auto-flush — the outletState model identity is unchanged so the natural setOutletState rerender path never fires. Two bridge sites in `_gxtTriggerReRender`: 1) Direct controller-model: when `obj.isController === true` and `keyName === 'model'`, invoke the outlet rerender hook with `forceFull=true`. Narrowed to `model` so @Tracked controller properties (e.g. View tree test's `isExpanded`) keep using the non-destructive cell-based path. 2) Interior model mutation: when `obj` is registered as the value of `(*, 'model')` via `_objectValueCellMap` and the owner resolves to a controller (via prototype, owner.controller, or owner.isController), fire the same hook. Gated on `!_gxtIsCurrentlyRendering()` so component-init `this.set(...)` writes still hit the classic backtracking-re-render assertion. `root.ts` adds: - `_gxtControllerToOutletRefMap` (WeakMap<controller, outletRef>) populated in `renderOutletState` alongside the existing component-contexts registration. - `__gxtControllerOutletRerender(controller)` global hook with a `_gxtInControllerRerender` re-entrancy guard. - `rerenderForThisRoot` accepts an optional `forceFull` flag that bypasses the cell-only fast-path. Verified: Application test: rendering 14/18 → 17/18 (+3 — both exterior mutation tests + interior tracked model mutation; stable-DOM remains the documented trade-off carried from 49878cc). Smoke 333/333, View tree 3/3, Errors 4/4, Tracked 36/36, computed 148/148, Lifecycle 42/42, Query Params 160/161 (unchanged from baseline). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Two-part fix for the `{{element}}` keyword/helper pattern with GXT:
1. element.ts: brand ElementComponentDefinition.prototype with
`__isElementHelperDefinition = true` so the GXT $_c_ember wrapper
can detect the helper's return value without an explicit import.
2. compile.ts ($_c_ember branch): when `comp` (or a getter that resolves
to it) is an ElementComponentDefinition, render the tag directly via
$_tag(tagName, fw, ctx, children) instead of falling through to GXT's
raw $_c — which would call handleManagedComponent for a Glimmer-VM-
wrapped class component that GXT cannot construct, crashing with
"Cannot read properties of null (reading 'prototype')" inside the
minified GXT bundle.
3. ember-gxt-wrappers.ts ($_maybeHelper): when nameOrFn is an
object-shaped HelperDefinitionState (e.g. user scope binds
`element: elementHelper` from @ember/helper), look up the internal
helper manager from INTERNAL_HELPER_MANAGERS, call the helper with a
proper CapturedArguments shape (compute-refs via createComputeRef),
and read the resulting Reference via valueForRef. Previously the
object branch fell through to name-as-string container lookup and
returned undefined, leaving `@tag = undefined` for downstream `<Tag>`.
4. manager.ts (template-only render path, both manager-found and
COMPONENT_TEMPLATES-fallback): forward the incoming `fw` (splat
tagProps) into `renderCtx.$fw` so the child template's free `$fw`
references resolve to the invoker's forwarded attrs. Without this
`<Inner class="x"><Tag id="y" ...attributes>` lost the parent's
class because Inner's template-only render dropped fw on the floor.
Mirrors the createRenderContext path's existing $fw setup.
Together these fix the two failing element-helper tests:
- Helpers test: {{element}} :: passed as argument with ...attributes
- jit :: keyword helper: element :: MustacheStatement
All 5 regression gates remain green (smoke 1/1, errors 4/4, tracked
36/36, computed 148/148, lifecycle 42/42). Helpers test: family 1175/
1175, keyword helper: family 132/132.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
… QP properties Continuation of 9c2aae4 (controller-property → outlet rerender bridge). QP-tracked properties (`controller.incrementProperty('foo')` followed by `route.refresh()`) update cells but template formulas don't re-render without an outlet rerender trigger — same root cause as the `model` branch (outletState reference unchanged so the natural setOutletState rerender path doesn't fire). The bridge's controller branch is widened from `keyName === 'model'` to `keyName === 'model' || _isQpKey`, where `_isQpKey` checks whether the key is declared in `controller.queryParams` (string entry or object-key entry — three legal shapes per normalizeControllerQueryParams in @ember/routing/lib/utils.ts). QP keys are an explicit, user-authored set, so this widening does NOT include generic `@tracked` properties that broke the View tree test under unconditional widening. Verified: Query Params - main 61/62 → 62/62 (+1, Issue emberjs#13263). View tree unchanged (3/3). All 5 non-render gates at baseline: smoke 1/1, Errors thrown 4/4, Tracked Properties 36/36, computed 148/148, Lifecycle 42/42. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
… fallthrough on outer commit
Detect when {{#in-element this.rootElement insertBefore=null}} targets the
same element the outer template is committing into. Previously the second
$_inElement call (e.g. after `runTask(() => set(ctx, 'text', 'Huzzah!'))`)
took the direct-insert path and lost its content to the parent's
fragment-replace, leaving the test DOM as "BeforeAfter" instead of
"BeforeHuzzah!After".
Heuristic: a prior placeholder marker living as a direct child of
`appendRef` proves `appendRef` is the render-pass parent. When that
marker is present mid-render, take the self-insert path and return
[content, placeholder] as a wrapper fragment so the outer commit re-seats
content alongside surrounding literal siblings.
External targets (`document.createElement('div')` outside the render
flow) never carry the marker, so direct-insert is preserved — the
"allows appending to the external element with insertBefore=null" test
keeps passing.
Fixes 1 of 2 failing {{in-element}} tests (7/8). The remaining failure
("components are cleaned up properly") is a separate issue: modal-display
inside #if + #in-element fires willDestroyElement repeatedly but never
didInsertElement.
Gates: smoke 333/333, errors 4/4, tracked 36/36, computed 148/148,
lifecycle 42/42, view-tree 3/3.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
`keyword modifier: on :: can be shadowed` and `:: can be curried` silently
failed (empty step assertions, no error) because two runtime gates rejected
modifier installation outside an Ember application context:
1. `$_MANAGERS.modifier.handle` short-circuited to `undefined` whenever
`!owner && !isBuiltinModifierName`. Strict-mode keyword tests run
without an Ember owner, so user-shadowed `on` modifiers (registered via
`setModifierManager(factory, {})`) and curried-modifier closures (from
the `(modifier)` keyword) were dropped before reaching their factory.
The carve-out is extended to non-string modifier defs whose prototype
chain is registered in `globalThis.INTERNAL_MODIFIER_MANAGERS`, plus
functions tagged with `__isCurriedModifier`.
2. `createEmberModifierHelper`'s string-name curried modifier looked up
only `owner.factoryFor('modifier:NAME')` and returned undefined when no
owner existed — silently dropping built-in keyword modifiers like `on`
used in curried form `(modifier on "click" cb)`. It now probes
`$_MANAGERS.modifier._builtinModifiers[NAME]` first and dispatches
through `$_MANAGERS.modifier.handle` (which knows how to install the
Glimmer-VM OnModifierManager and attach the listener).
Paired with the matching glimmer-next compiler-side codegen fixes (shadow
fast-path gate, SubExpression-in-modifier-position dynamic dispatch,
free-identifier-to-string hoisting for `(modifier NAME ...)`), the full
`keyword modifier: on` suite passes 7/7 (was 5/7). 333/333 smoke,
456/456 keyword, 30/30 `{{on}} Modifier`, 24/24 Custom Modifier
regressions green.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Components inside {{#if}}+{{#in-element}} were pooled under an unstable parent: the initial render used the ambient parent (often ROOT) while the SELF_TAG morph re-render pushed a fresh context, so the pool lookup missed, a new instance was created on every reactive change, and the prior was swept as unclaimed — firing willDestroyElement repeatedly and never firing didInsertElement. A detached in-element destination (createElement('div') never appended) also makes el.isConnected false, so the after-insert flush skipped didInsertElement and the unclaimed sweep fired spurious teardown.
- compile.ts $_inElement: render block content with the stable destination (appendRef) pushed as pool-parent via viewUtils.pushParentView/popParentView; tag the destination __gxtIsInElementHost.
- manager.ts: isElementLiveOrInElementHosted() recognizes in-element-hosted (detached) elements as live for the didInsertElement gate; pass-gated claimed-in-pool liveness check in the unclaimed sweep (gated on pool.__lastPassId === currentPassId so {{#if}} collapse still tears down).
Fixes '{{in-element}} :: components are cleaned up properly' (7/8 -> 8/8). No forceFull bridge touched; Helpers compute-count bouncer intact.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The outlet full-rerender path did parentElement.innerHTML = '', orphaning every node — breaking the 'stable DOM when the model changes' invariant, which captures the original text nodes and expects them to survive a model swap (e.g. /colors/red -> /colors/green where the template is 'color: {{@model}}').
When both the existing and newly-rendered content are text/comment-only (_isTextOnly), render into a temp container and _morphInto() in place, reusing same-type nodes and updating textContent — preserving node identity. Any element node (component wrappers, <ember-outlet>, LinkTo anchors) disqualifies the morph and falls through to the existing clear+re-render path, so the load-bearing full-rerender / pool lifecycle is untouched.
Fixes 'Application test: rendering :: it should produce a stable DOM when the model changes' (17/18 -> 18/18).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
GXT dual-backend rendering (opt-in preview)
Summary
This PR adds Glimmer-Next / GXT (
@lifeart/gxt) as an opt-in, build-timealternate rendering backend for
ember-source, sitting behindEMBER_RENDER_BACKEND=gxt(production bundles) andGXT_MODE=true(the Vitedev loop). The split happens strictly at the
@glimmer/*+ember-template-compilerboundary — everything above that line is shared
@ember/*code, everythingbelow it is backend-specific. Classic Glimmer remains the default with no
behavior change and no public API change; GXT is tree-shaken out of the
classic bundle. A draft RFC (
rfcs/text/0000-gxt-dual-backend.md) accompaniesthe implementation and is intended to be promoted to an
emberjs/rfcsPR.Motivation
no VM opcodes, no wire format, and no template JIT — just reactive cells and
direct DOM adapters. For apps that do not need SSR or Glimmer-VM-only
addons, this is a meaningful architectural simplification.
@lifeart/gxtcompat work into mainstream Ember so thatconsumers can evaluate a second backend without a fork. The compat layer is
Ember-owned code; GXT itself stays an external dependency.
asking the Glimmer team to maintain a second runtime or rewriting GXT's
reactive core onto VM opcodes (which are architecturally incompatible — see
RFC §Motivation).
identical to pre-PR output on targeted modules; nothing is conditionally
compiled in the hot path.
What's in this PR
~432 commits, ~106k insertions across ~219 files. Organized by area:
New package —
packages/@ember/-internals/gxt-backend/First-class home for the compat layer (moved out of the previous
packages/demo/compat/scratch location). Declared as a private package witha full
exportsmap in itspackage.json. Key files:manager.ts— the heart of the adapter. Ember component / helper /modifier managers translated onto GXT's reactive + lifecycle primitives.
Large, but organized by internal headers (best reviewed section by section).
compile.ts— template compiler bridge: accepts the Ember.hbs/.gtsinput shape and produces a GXT template factory. Paired with
gxt-template-compiler-plugin.mjsandgxt-template-factory.ts.reference.ts,validator.ts,destroyable.ts— seam shims for@glimmer/reference,@glimmer/validator,@glimmer/destroyable.glimmer-tracking.ts,glimmer-application.ts,glimmer-util.ts,glimmer-env.ts,glimmer-syntax.ts— drop-in substitutes for thecorresponding
@glimmer/*packages.ember-template-compiler.ts,runtime-hbs.ts,gxt-with-runtime-hbs.ts,test-compile.ts— template-compiler entry points across production andtest harnesses.
outlet.gts,link-to.gts,ember-routing.ts— router integration.helper-manager.ts,ember-gxt-wrappers.ts— helper manager adapter andEmber-side wrappers for GXT primitives.
debug.ts,debug-render-tree.ts,ember-inspector-adapter.ts,ember-inspector-hook.ts— partial Ember Inspector parity surface(follow-up work — see RFC §8).
__tests__/— direct unit tests for the adapter, including arehydration-delegate suite.
Vendored
packages/@glimmer/manager/index.tsGained no-op stubs for the GXT hook symbols (
onTag,onComponent,onModifier) plus namespace-import-friendly re-exports so thattracked.tsand
internal.tsresolve identically on both backends without conditionalcompilation. On classic, the stubs are unreachable and stripped by
tree-shaking.
Classic-side integration hooks
Edits under
packages/@ember/-internals/glimmer/,packages/@ember/-internals/metal/,packages/@ember/object/,packages/@ember/routing/, andpackages/@ember/runloop/add the narrow setof hooks GXT needs to observe and participate (CP re-render cascades,
notifyPropertyChange gating, outlet re-render instrumentation, runloop
scheduling boundaries). Every change is a no-op on the classic build path;
they exist only so GXT has something to bind to.
Demo app —
packages/demo/Vite-based demo that exercises the GXT backend end-to-end (
vite.config.mts,src/,tests.html). This is the fastest way to poke at the backend in abrowser and is also what the test runner drives under the hood.
Build-time aliasing
rollup.config.mjsgained anEMBER_RENDER_BACKEND=gxtbranch that swaps@glimmer/*andember-template-compileraliases for thegxt-backendentry points. Default remains
classic.vite.config.mjsgained the same aliasing underGXT_MODE=true, drivingthe dev loop and the Playwright test runner.
RFC draft
rfcs/text/0000-gxt-dual-backend.md— SemVer posture, feature supportmatrix, FastBoot/engines disposition,
@glimmer/componentdisposition,Ember Inspector parity plan, numeric exit criteria for leaving preview.
rfcs/text/0000-gxt-dual-backend-addon-matrix.md— best-efforttop-20-addon compat snapshot (7 pass / 4 classic-only / 9 untested;
every "pass" is inference, not yet verification).
CI
.github/workflows/gxt-dual-build.yml— builds both backends on every PR,runs bundle-size check per backend, uploads artifacts.
.github/workflows/gxt-smoke.yml— 4-shard Playwright smoke suite on everyPR, required check, finishes in under 5 minutes.
.github/workflows/gxt-full.yml— nightly full suite, compares againsttest-results/gxt-baseline.json, opens a regression issue on green→red.Tooling
scripts/gxt-test-runner/— Playwright + QUnit runner replacing theearlier stuck-detection prototype.
QUnit.on('runEnd', …)is the onlycompletion signal; hangs are recorded as timeouts, never baseline passes.
Includes
runner.mjs,diff.mjs,categorize.mjs,contract-tests.mjs,and
smoke-modules.json.scripts/bundle-size-check.mjs+scripts/bundle-budgets.json— CI gateon both backends' bundle sizes.
scripts/ember-cli-gxt.mjs— consumer-facing CLI plugin:ember-cli-gxt enable|disable|status.test-results/gxt-baseline.json— committed baseline that the nightlyrunner diffs against to catch regressions.
Backwards compatibility
the targeted modules. No
@glimmer/*import was moved, renamed, or routedthrough a seam layer — classic is still classic.
@ember/*API surface is unchanged on both backends; 12 contracttests in
scripts/gxt-test-runner/contract-tests.mjsverify that bothbackends export the same symbols with matching signatures.
EMBER_RENDER_BACKEND=gxt/GXT_MODE=true.Nothing in this PR is reachable on a default build.
Opt-in usage
Local dev loop:
Production bundle:
Or via the CLI plugin:
node scripts/ember-cli-gxt.mjs enable.Test parity
modules (components, angle-bracket invocation, curly, template-only,
contextual, built-in helpers, custom helpers, modifiers, tracked state,
{{each}},{{if}}/{{unless}},{{let}}, computed, observers).test-results/gxt-baseline.json): 5,327 / 5,938 (~89.7%) passing on GXT.Glimmer JIT-specific internals (77), Ember Inspector / debug-render-tree
(58), engine/route-transition edge cases (41), miscellaneous (42).
The ~300 most recent commits on
glimmer-next-freshare targetedfix(gxt):commits against rehydration, query-params, contextualcomponents, computed-property cell setup, custom modifiers, and more.
git log upstream/main..HEADshows the full record; the baseline fileshould be refreshed before merge.
nightly run.
Known limitations / follow-ups
rehydration subsystem (see
packages/@ember/-internals/gxt-backend/rehydration-delegate.tsandrecent
fix(gxt): rehydration — …commits), but the classic FastBootmarker-translation path has two open architectural blockers: root-context
isolation inside
compile.ts(RFC Phase 4.1) and lossy cursor-IDtranslation for nested engine outlets (Phase 4.2). The delegate ships as
an opt-in escape hatch, not as the default SSR path.
@glimmer/componentimport-identity question. The published packagedirectly imports
@glimmer/manager+@glimmer/reference; if an appinstalls
@glimmer/component@2.xalongsideember-source-gxt, symbolidentity for
Tag/createTag/CURRENT_TAG/getCustomTagForforks.RFC §6 documents two resolution options (sibling
@glimmer/component-gxtvs. protocol-package extraction); neither is implemented here.
exercised against a fully strict-mode Embroider build.
rollup.config.mjsoutput): GXT prod is ~3.48 MB raw vs. classic's~2.05 MB — approximately 70% larger raw, 68% larger gzip. Dominated
by
@lifeart/gxt's reactive core + bundled template compiler with notree-shaking applied yet. A
rollup-plugin-visualizersweep (RFC Phase2.5) is the recommended next step; until it lands, the 70% premium should
be read as a worst-case upper bound, not a final number.
RFC status
Draft at
rfcs/text/0000-gxt-dual-backend.md(plus the addon matrixcompanion), marked
Stage: Acceptedfor the purposes of tracking branchwork. The intent is to promote it to a real RFC PR against
emberjs/rfcsbefore a preview tag ships — an Ember core team scheduling question, noted
in the RFC's own follow-ups table.
How to review
Suggested order, shortest path to "is this sane?":
rfcs/text/0000-gxt-dual-backend.md(motivation, SemVer posture,exit criteria). Then the addon matrix companion for the ecosystem picture.
packages/@ember/-internals/gxt-backend/package.jsonand the
exportsmap. Confirms the public entry points the rest of Emberis expected to reach through.
manager.ts— the heart of it. Large, but organized by internalsection headers; follow those rather than reading top-to-bottom.
compile.ts— template-compiler bridge. Same guidance: follow theinternal headers.
-internals/metal/,-internals/glimmer/,@ember/object/,@ember/routing/,@ember/runloop/. These are small,narrowly scoped, and each should read as a no-op on classic.
.github/workflows/gxt-*.ymlplusscripts/gxt-test-runner/README.mdandscripts/bundle-budgets.json.test-results/gxt-baseline.json— don't read it, but confirm theregression gate is in place.
Not in scope
is a future RFC consideration, gated on the numeric exit criteria in RFC §10.
(
ember-inspector-adapter.ts,ember-inspector-hook.ts,debug-render-tree.ts) but full parity is follow-up work pending GXT'sinternal component-tree API stabilization.
Glimmer-VM JIT internals that are architecturally incompatible with GXT
(no opcodes, no JIT). These are explicitly not targeted for parity.
ember-source-gxton npm. The RFC discusses theside-channel package story; this PR only lands the dual-build capability
inside the monorepo.