Make ember-lts-4.12 compat scenario runnable

[NullVoxPopuli-ai-agent]

Summary

Gets ember-lts-4.12 green locally by unblocking two stacked runtime issues that surfaced once the require resolver fix in #321 landed. Both only affect the compat path (ENABLE_COMPAT_BUILD=true + the ember4 deps overrides); ember-source >= 6 scenarios don't hit them because the upstream code was rewritten.

1. Cannot read properties of undefined (reading 'has') — COMPUTED_GETTERS.has(...)

ember-source <= 5.x (@ember/-internals/metal):

import { DEBUG } from '@glimmer/env';

let COMPUTED_GETTERS;
if (DEBUG) { COMPUTED_GETTERS = new _WeakSet(); }
// ...
assert(`...`, isClassicDecorator || !propertyDesc || !propertyDesc.get || !COMPUTED_GETTERS.has(propertyDesc.get));

@glimmer/env publishes DEBUG = false. Without something resolving DEBUG at compile time, rollup tree-shakes the if (DEBUG) init while the assert predicate still runs eagerly → COMPUTED_GETTERS is undefined at runtime. ember-source >= 6 switched to isDevelopingApp() from @embroider/macros (which buildMacros() already handles), which is why non-compat scenarios don't hit this.

Fix: add babel-plugin-debug-macros conditionally (only when ENABLE_COMPAT_BUILD is set) in babel.config.mjs:

const isCompatBuild = !!process.env.ENABLE_COMPAT_BUILD;

// ...
...(isCompatBuild
  ? [
      [
        'babel-plugin-debug-macros',
        {
          flags: [{ source: '@glimmer/env', flags: { DEBUG: true } }],
        },
      ],
    ]
  : []),

The plugin inlines DEBUG = true at every @glimmer/env import site in ember-source so the init and the use stay consistent. Gating on ENABLE_COMPAT_BUILD keeps the default build untouched.

2. Bump ember-qunit and @ember/test-helpers in the ember4 stanza

Two additional runtime errors were classic-Ember assumptions that don't hold in a vite bundle:

• ReferenceError: requirejs is not defined — ember-qunit@8's start() auto-calls loadTests(), which enumerates requirejs.entries from classic Ember's loader.js. ember-qunit@9 dropped that call entirely.
• Cannot read properties of undefined (reading '_APPLICATION_TEMPLATE_WRAPPER') — @ember/test-helpers@4's setup-rendering-context / visit reads global.EmberENV._APPLICATION_TEMPLATE_WRAPPER; classic ember-cli seeded that global from index.html. @ember/test-helpers@5 removed every reference to EmberENV and _APPLICATION_TEMPLATE_WRAPPER.

Both can be worked around in the test app (passing { loadTests: false } to qunitStart, manually assigning globalThis.EmberENV), but the cleaner fix is to bump the pins so the compat scenario exercises the same API surface modern scenarios already do:

 const ember4 = {
-  '@ember/test-helpers': '^4.0.0',
+  '@ember/test-helpers': '^5.0.0',
   '@ember/test-waiters': '^3.1.0',
   '@embroider/compat': '^4.0.3',
-  'ember-qunit': '^8.0.0',
+  'ember-qunit': '^9.0.0',
   'ember-cli': '~4.12.0',
 };

Both bumps peer ember-source >= 4.0.0, so Ember 4.12 is still within the supported range. ember-qunit@9 peers @ember/test-helpers >=3.0.3, so the test-helpers bump stays within bounds.

Test plan

• pnpm dlx @embroider/try apply ember-lts-4.12 && pnpm install --no-lockfile --ignore-scripts && pnpm --filter ember-page-title build && cd test-app && ENABLE_COMPAT_BUILD=true CI_BROWSER=chrome pnpm test:ember locally → 31 pass, 0 fail
• Default (non-compat) pnpm test:ember locally → 31 pass, 0 fail (the babel plugin is not added without ENABLE_COMPAT_BUILD)
• ember-lts-4.12 job on CI goes green
• ember-lts-5.12, ember-lts-6.4, ember-latest, ember-beta, ember-alpha remain green
• Non-compat Tests/Floating Dependencies jobs remain green

Still red after this PR

min-supported (ember-source ~4.2.0) hits a separate, unrelated failure: @glimmer/[email protected] imports @ember/owner, which didn't ship until Ember 4.10. The scenario's ember4 deps stanza will need a @glimmer/component@^1.1.2 pin. Out of scope here since the user asked specifically about ember-lts-4.12.

🤖 Generated with Claude Code