Skip to content

[SPIKE] Remove -with-dynamic-vars / -get-dynamic-var support#21485

Closed
NullVoxPopuli-ai-agent wants to merge 1 commit into
emberjs:mainfrom
NullVoxPopuli-ai-agent:remove-dynamic-vars
Closed

[SPIKE] Remove -with-dynamic-vars / -get-dynamic-var support#21485
NullVoxPopuli-ai-agent wants to merge 1 commit into
emberjs:mainfrom
NullVoxPopuli-ai-agent:remove-dynamic-vars

Conversation

@NullVoxPopuli-ai-agent

Copy link
Copy Markdown
Contributor

Summary

Spike: remove support for the -with-dynamic-vars / -get-dynamic-var template keywords and the VM plumbing that exists only to serve them.

This removes the template-facing dynamic vars feature end to end:

  • Compiler keywords: -get-dynamic-var (call + append positions), -with-dynamic-vars (block position), and the utils/dynamic-vars.ts keyword delegate
  • MIR: the GetDynamicVar and WithDynamicVars nodes, their encoding passes, and their strict-mode visitor arms
  • Wire format: opcodes WithDynamicVars (45) and GetDynamicVar (53), their WireFormat.Statements / WireFormat.Expressions types, and the wire-format-debug formatting (opcode numbers are left as gaps, not renumbered)
  • Opcode compiler: the statement/expression compilers for both opcodes, plus the now-orphaned DynamicScope() opcode-builder helper
  • VM: VM_GET_DYNAMIC_VAR_OP (111) and VM_BIND_DYNAMIC_SCOPE_OP (58) — constants, VmOp types, append-opcode handlers, VM#bindDynamicScope, and debug metadata
  • Tests: the -with-dynamic-vars and -get-dynamic-var integration suite, the entry-point "initial dynamic context" test, the curly dynamicScope smoke test, Ember's with-dynamic-var-test.js, and the -with-dynamic-vars leg of the syntax refinements test

What is deliberately kept

Dynamic scope itself is not removed — Ember's outlet machinery stores outletState in it from JS:

  • DynamicScope interface (get/set/child) and DynamicScopeImploutlet.ts's component manager and syntax call dynamicScope.get('outletState') / .set(...) directly
  • VM_PUSH_DYNAMIC_SCOPE_OP / VM_POP_DYNAMIC_SCOPE_OP — component invocation still saves/restores dynamic scope around component boundaries
  • renderMain / renderComponent's dynamicScope parameter
  • Ember's DynamicScope class in renderer.ts, including its outletState-only assertions (now guarding only internal JS callers)

Breaking-change note

This deletes the intimate API that liquid-fire uses to intercept outletState
({{#-with-dynamic-vars outletState=...}} / (-get-dynamic-var "outletState")) — the
outlet-test.js case labeled "outletState can pass through user code (liquid-fire
intimate API)" is removed accordingly. Everywhere else in Ember these keywords were
already restricted to outletState by assertions. If this lands for real it presumably
needs an RFC/deprecation story for liquid-fire (or confirmation that current liquid-fire
no longer relies on it).

Testing

  • pnpm type-check:internals — clean (the two @glimmer/component module-resolution errors in owner/type-tests are pre-existing on main)
  • pnpm lint:eslint — clean
  • pnpm test (vite build + full testem browser suite) — 9382 tests, 9365 pass, 17 skip, 0 fail

🤖 Generated with Claude Code

Removes the template-facing dynamic vars feature:

- the -get-dynamic-var (call/append) and -with-dynamic-vars (block)
  keywords, the GetDynamicVar/WithDynamicVars MIR nodes, their encoding
  and strict-mode passes
- wire format opcodes WithDynamicVars (45) and GetDynamicVar (53) and
  their types (numbers left as gaps, not renumbered)
- VM opcodes GetDynamicVar (111) and BindDynamicScope (58), their
  append-opcode handlers, VM#bindDynamicScope, and debug metadata
- the associated integration test suites

Dynamic scope itself stays: Ember's outlet machinery reads and writes
outletState on the dynamic scope directly from JS, and component
invocation still pushes/pops dynamic scope. Only the template syntax
for reading/writing arbitrary dynamic vars is removed.

Note: this deletes the intimate API liquid-fire uses to intercept
outletState in templates.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants