Support Babel 8 alongside Babel 7

[wagenet]

Note: This PR was written by an AI agent (Claude, via Claude Code), run by @wagenet. The code and this description are the agent's work, not his. It's opened as a draft because it can't merge usefully until broccoli-babel-transpiler moves first (see below) — and because it deserves a careful human review rather than a rubber stamp.

Towards #535.

What this does

Makes ember-cli-babel work on Babel 7 and Babel 8 from one codebase, and widens the @babel/* ranges to ^7.x || ^8.0.0 (peer @babel/core to ^7.12.0 || ^8.0.0).

pnpm test:node is green on both: 106/106 on Babel 7, 106/106 on Babel 8.0.1.

The four things Babel 8 actually broke

@babel/plugin-proposal-decorators requires version. Babel 8 removed .legacy and errors without an explicit version. { legacy: true } → { version: "legacy" }; Babel 7 accepts that spelling too, so there's no branch.

moduleIds / getModuleId are no longer root options. This is the one that would be easy to miss. Babel 8 reads them only from the module transform's own options, so with the current code every module compiles to an anonymous define([...]) and the AMD loader can't find any of them. Babel 7's getModuleName already prefers plugin-level values over root ones, so these move into @babel/plugin-transform-modules-amd rather than forking.

@babel/plugin-transform-runtime dropped regenerator, useESModules, and helpers. All three now throw. useESModules: true still changes behavior on Babel 7 (without it you get CJS helpers), so this is the only place that checks the installed major. On Babel 8 it's unnecessary — @babel/runtime resolves ESM helpers via package.json#exports.

loadPartialConfig became callback-based. The useBabelConfig: true path called it synchronously. loadPartialConfigSync has existed since Babel 7.8.

Behavior change worth a release note

Projects using useBabelConfig: true that configure the AMD transform by hand have to pass moduleIds/getModuleId themselves on Babel 8, because we can no longer inject them at the root:

[
  require.resolve("@babel/plugin-transform-modules-amd"),
  {
    noInterop: true,
    moduleIds: true,
    getModuleId: require("ember-cli-babel/lib/relative-module-paths")
      .getRelativeModulePath,
  },
],

buildEmberPlugins now does this itself, so only hand-rolled config is affected. It's documented in the README. The failure mode is silent at build time, which is why it's called out.

This can't merge yet

broccoli-babel-transpiler@8.0.2 declares "@babel/core": "^7.17.9" as a peer, which npm treats as a hard failure:

npm error code ERESOLVE
npm error peer @babel/core@"^7.17.9" from broccoli-babel-transpiler@8.0.2

The constraint looks stale rather than real — its whole Babel surface is transformAsync plus reading @babel/core/package.json for a cache key, and the suite passes against Babel 8 with the peer check relaxed. It needs ^7.17.9 || ^8.0.0 and a release before any of this is reachable by users. There's no open Babel 8 issue or PR on that repo.

Notes for reviewers

• CI: adds a Node: Babel 8 job. scripts/use-babel-8.js rewrites package.json with pnpm overrides before install; its comments explain each one. Two are workarounds, not requirements: code-equality-assertions (a test-only assertion helper that calls transform synchronously — it keeps its own Babel 7 copy in a normal install) and relaxing the broccoli-babel-transpiler peer check described above.
• @babel/runtime is left pinned at 7.12.18. It looked deliberately exact-pinned, and it feeds the helpers tree in treeForAddon, so I didn't touch it. Worth deciding separately whether Babel 8 apps should get @babel/runtime@8 helpers.
• The static-block test asserts an exact snapshot of Babel's inline helpers. Babel 8 emits the same helpers in a different order, so the snapshot is now Babel 7 only, with both majors asserting what the test is actually about (the static block is compiled away). Regenerating a second snapshot instead would also be reasonable — your call.
• loose deprecation warnings appear on Babel 8 for -private-methods and -private-property-in-object, which want the privateFieldsAsProperties / setPublicClassFields assumptions instead. Left alone: assumptions are global rather than per-plugin, so it's a semantic change that seemed like a maintainer decision.
• babel-plugin-ember-modules-api-polyfill@3.5.0 uses uppercase @babel/types builders, deprecated in @babel/types@8. Warning only, and only reached on ember-source < 3.27.

🤖 Generated with Claude Code