Add support for Babel v8

[francescoparra]

Support for Babel 8

Description

ember-cli-babel currently does not support Babel 8.

When upgrading a project to Babel 8, ember-cli-babel is unable to work correctly with the new Babel version, preventing applications from upgrading their Babel dependencies.

Expected behavior

ember-cli-babel should support Babel 8 and allow Ember applications to use the latest Babel release without requiring compatibility workarounds or pinning Babel to an older major version.

Actual behavior

Using Babel 8 with ember-cli-babel results in compatibility issues because ember-cli-babel currently relies on Babel APIs and/or behavior that changed in Babel 8.

Motivation

Babel 8 is a new major release with breaking changes, and projects upgrading their Babel dependencies will eventually need ember-cli-babel to support it.

It would be useful to add Babel 8 support and update any affected Babel APIs, dependencies, or compatibility checks.

Additional context

This may also require reviewing ember-cli-babel's Babel-related dependencies and peer dependency constraints to ensure Babel 8 is correctly supported.

[wagenet]

Note: This comment was written by an AI agent (Claude, via Claude Code) investigating what Babel 8 support would take. It was run by @wagenet, but the analysis and wording are the agent's, not his. Everything below was verified by running it against Babel 8.0.1 — but please review it critically rather than taking it at face value.

Summary

Babel 8 support in ember-cli-babel itself is small and tractable — four option changes, all but one of which work identically on Babel 7 and 8. It cannot ship until broccoli-babel-transpiler widens its @babel/core peer range, which is a one-line change in a different repo.

I have a draft PR with the ember-cli-babel half: #537

With it applied, pnpm test:node is green on both majors: 106/106 on Babel 7, 106/106 on Babel 8.0.1.

One thing that's already fine

The commonly-cited blocker — @babel/plugin-proposal-class-properties / -private-methods having no Babel 8 release — no longer applies. ember-cli-babel@8.x already moved to @babel/plugin-transform-class-properties, -private-methods, and -private-property-in-object. Every @babel/* package it depends on has a Babel 8 release, including @babel/plugin-proposal-decorators@8.0.2 (that package keeps its name in Babel 8).

What actually breaks

1. Decorators require a version option. Babel 8 removed .legacy outright and errors without version:

The decorators plugin requires a 'version' option, whose value must be one of: '2023-11' or 'legacy'.

{ legacy: true } → { version: "legacy" }. Babel 7 also accepts version: "legacy", so this needs no version branch.

2. moduleIds / getModuleId are no longer root options. This is the subtle one and the easiest to miss. Babel 8 rejects them at the root (Unknown option: .moduleIds); they are now read only from the module transform's own options. ember-cli-babel sets them at the root today, so on Babel 8 every module is emitted as an anonymous define([...]) and the Ember AMD loader can't find any of them.

Babel 7's getModuleName already prefers plugin-level values over root ones (get-module-name.js), so moving them into @babel/plugin-transform-modules-amd works on both majors.

3. @babel/plugin-transform-runtime lost regenerator, useESModules, and helpers. All three now throw. useESModules: true still matters on Babel 7 (without it you get CJS helpers), so this is the one place that genuinely needs a version check. On Babel 8 the option is unnecessary — @babel/runtime resolves ESM helpers through package.json#exports.

4. loadPartialConfig is async in Babel 8. index.js calls it synchronously on the useBabelConfig: true path:

Starting from Babel 8.0.0, the 'loadPartialConfig' function expects a callback.
If you need to call it synchronously, please use 'loadPartialConfigSync'.

loadPartialConfigSync has existed since Babel 7.8, so switching is safe on both.

One unavoidable behavior change for useBabelConfig users

Because ember-cli-babel can no longer inject moduleIds/getModuleId at the root, projects that bring their own babel.config.js and configure the AMD transform by hand have to pass them to the transform themselves on Babel 8:

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

buildEmberPlugins does this for you in the PR, so only hand-rolled AMD config is affected. Worth a release note — the failure mode is silent at build time and only shows up as modules the loader can't resolve.

Non-fatal deprecation warnings under Babel 8

• loose on @babel/plugin-transform-private-methods and -private-property-in-object is deprecated in favor of the privateFieldsAsProperties / setPublicClassFields assumptions. Still works; noisy. I left it alone since moving to assumptions changes their scope from per-plugin to global, which felt like a maintainer call.
• babel-plugin-ember-modules-api-polyfill@3.5.0 uses uppercase @babel/types builders (MemberExpression), deprecated in @babel/types@8. Only reached on ember-source < 3.27.

The actual blocker: broccoli-babel-transpiler

broccoli-babel-transpiler@8.0.2 declares:

"peerDependencies": { "@babel/core": "^7.17.9" }

On npm this is a hard install failure, not a warning:

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

The good news is that the constraint looks stale rather than real. Its entire Babel surface is transformAsync plus reading @babel/core/package.json for a cache key — both fine on Babel 8. I ran ember-cli-babel's full node suite against @babel/core@8.0.1 with that peer check relaxed and everything passed, so I think it just needs the range widened to ^7.17.9 || ^8.0.0 and a release. There's no open Babel 8 issue or PR on that repo (last release Apr 2025), so someone would need to pick it up.

Suggested ordering

1. broccoli-babel-transpiler — widen the peer range, release a patch. Nothing else can move first.
2. ember-cli-babel — the four fixes above, plus widening @babel/* ranges to ^7.x || ^8.0.0 and the @babel/core peer to ^7.12.0 || ^8.0.0. Draft PR: Support Babel 8 alongside Babel 7 #537
3. code-equality-assertions (dev-only, optional) — depends on @babel/core: ^7.19.6 and calls transform synchronously. It keeps its own nested copy in a normal install, so it doesn't block anything; it only matters if you try to force a single Babel 8 across the whole tree.

Happy to be told any of this is wrong — I'd rather be corrected than have a bad analysis sit on the issue.