chore(deps): upgrade Babel toolchain to 8.x (coordinated migration)#1044
Conversation
Bumps @babel/core, @babel/preset-env, @babel/preset-react, @babel/preset-typescript, @babel/plugin-transform-runtime, and @babel/runtime to their 8.x releases together, since preset-env, preset-react, preset-typescript, and plugin-transform-runtime 8.x all peer-require @babel/core ^8.0.0 — they cannot land independently (this is why the individual Dependabot PRs for these packages showed as CONFLICTING/DIRTY; see #1002, #1004, #1007, #1026). Also: - Removes @babel/plugin-proposal-class-properties, @babel/plugin-proposal-object-rest-spread, and @babel/plugin-syntax-import-meta from babel.config.cjs and package.json. None of these have an 8.x release (their proposals were long ago folded into standard JS/babel-preset-env), and their peer dependency on @babel/core is pinned to `^7.0.0-0`, making them incompatible with core 8. Verified via a direct transformSync smoke test that preset-env alone still handles class fields, object rest/spread, and import.meta without them. - Bumps babel-jest from 29.7.0 (peer-requires @babel/core ^7.8.0, so it doesn't support babel 8 devDependency) to 30.4.1. - Sets Jest's coverageProvider to "v8" instead of the default "babel". Babel 8 exposed a circular-require bug in Jest's Istanbul coverage instrumentation path (@jest/transform's nested @babel/core@7.29.7 copy resolves to an empty exports object when lazily instrumenting a dynamically-required file), which only reproduced under `--coverage` and only for scripts/agents/includes/sync-version.js (the one file explicitly exempted from transformIgnorePatterns because it's require()'d at runtime rather than statically imported). Switching to V8's native coverage sidesteps the Babel/Istanbul instrumentation path entirely; full suite (72 suites / 668 tests) passes both with and without coverage. Verified: npm ci, npm run test:js (668/668 passing), npm run lint:pkg-json, and a targeted eslint pass all green.
|
✅ Template check passed after update. Thanks for fixing the PR description. |
github-actions
Bot
added this to the
chore(deps-dev): bump @babel/preset-env from 7.28.5 to 8.0.2 milestone
|
Warning Review limit reached
Next review available in: 13 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Repository YAML (base), Organization UI (inherited) Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (4)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
github-actions
Bot
added
status:needs-review
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates Babel dependencies to version 8, simplifies the Babel configuration by removing several plugins, and configures Jest to use the V8 coverage provider. Feedback recommends reverting the coverage provider to 'babel' to prevent inaccurate coverage reports for transpiled files, and instead excluding problematic files. Additionally, @babel/runtime should be pinned to version 8.0.1 for consistency and moved to dependencies if the project is distributed as a library.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| }, | ||
| moduleFileExtensions: ['js', 'ts', 'jsx', 'tsx', 'json'], | ||
| coverageDirectory: process.env.JEST_COVERAGE_DIR || './coverage', | ||
| coverageProvider: 'v8', |
There was a problem hiding this comment.
Using coverageProvider: 'v8' can result in inaccurate coverage reports for transpiled files (such as TypeScript, JSX, and TSX files) because V8 coverage relies on precise source maps, which Jest often struggles to map back correctly compared to Babel/Istanbul. Since the circular-require issue was only reproduced for scripts/agents/includes/sync-version.js, a more robust approach is to keep the default 'babel' provider and exclude the problematic file using coveragePathIgnorePatterns.
coverageProvider: 'babel',
| "@babel/preset-env": "8.0.2", | ||
| "@babel/preset-react": "8.0.1", | ||
| "@babel/preset-typescript": "8.0.1", | ||
| "@babel/runtime": "^8.0.0", |
There was a problem hiding this comment.
There are two issues with @babel/runtime here: 1. Dependency Type: If this project is published as a library, @babel/runtime must be in dependencies rather than devDependencies. The @babel/plugin-transform-runtime helper injects imports to @babel/runtime into the transpiled output, which consumers will need at runtime. 2. Version Consistency: To prevent potential compatibility issues and keep the lockfile predictable, @babel/runtime should be pinned to the exact same version as @babel/plugin-transform-runtime (8.0.1) instead of using a caret range (^8.0.0).
| "@babel/runtime": "^8.0.0", | |
| "@babel/runtime": "8.0.1", |
github-actions
Bot
added
area:documentation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 41ef1c1f91
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| "@babel/core": "8.0.1", | ||
| "@babel/plugin-transform-runtime": "8.0.1", | ||
| "@babel/preset-env": "8.0.2", | ||
| "@babel/preset-react": "8.0.1", | ||
| "@babel/preset-typescript": "8.0.1", |
There was a problem hiding this comment.
This upgrade pulls in Babel 8 packages whose lockfile engines require ^22.18.0 || >=24.11.0, but the repo still has .npmrc engine-strict=true; npm's engine-strict docs say npm refuses to install packages incompatible with the current Node version. I checked workflows including .github/workflows/project-meta-sync.yml, .github/workflows/metrics.yml, .github/workflows/issues.yml, and .github/workflows/readme-audit.yml: they set Node 20 or 18 and run npm ci/npm ci --ignore-scripts, and reproducing under Node 20.20.2 with npm ci --ignore-scripts --dry-run --offline fails with EBADENGINE before tests run. Either keep Babel on a Node-20-compatible line or raise every install environment and the package engine together.
Useful? React with 👍 / 👎.
🔍 Reviewer Summary for PR #1044CI Status: ❌ Recommendations
|
Metadata governance
|
1 participant
Chore Pull Request
Linked issues
Relates to #1002, #1004, #1007, #1026 (superseded — closed in favour of this coordinated migration).
Summary
Completes the Babel 8 migration that individual Dependabot PRs couldn't land on their own, since
@babel/preset-env,@babel/preset-react,@babel/preset-typescript, and@babel/plugin-transform-runtime8.x all peer-require@babel/core@^8.0.0— bumping any one of them alone against a 7.x core breaksnpm ci. This is why #1002, #1004, #1007, and #1026 each showed asCONFLICTING/DIRTY.Changes
@babel/core,@babel/preset-env,@babel/preset-react,@babel/preset-typescript,@babel/plugin-transform-runtime, and@babel/runtimeto 8.x together.@babel/plugin-proposal-class-properties,@babel/plugin-proposal-object-rest-spread, and@babel/plugin-syntax-import-meta— none have an 8.x release (their proposals were folded into standard JS /preset-envlong ago), and their@babel/corepeer range (^7.0.0-0) is incompatible with core 8. Verified with a directtransformSyncsmoke test that class fields, object rest/spread, andimport.metastill transform correctly without them.babel-jest29.7.0 → 30.4.1 (29.7.0 peer-requires@babel/core@^7.8.0, so it can't run against babel 8).coverageProvidertov8. Babel 8 exposed a circular-require bug in Jest's Istanbul-based coverage instrumentation (@jest/transform's nested@babel/core@7.29.7copy resolves to an empty exports object when lazily instrumenting a dynamically-require()'d file under--coverage) — reproduced only forscripts/agents/includes/sync-version.js, the one file explicitly exempted fromtransformIgnorePatterns. Switching to V8's native coverage sidesteps Babel/Istanbul instrumentation entirely.Impact / Compatibility
babel.config.cjsverified equivalent for class fields, object rest/spread, andimport.metasyntax after removing the deprecated plugins.Verification
Risk & Rollback
Changelog
Changed
@babel/core,@babel/preset-env,@babel/preset-react,@babel/preset-typescript,@babel/plugin-transform-runtime,@babel/runtime), removed three plugins with no 8.x release, bumpedbabel-jestto 30.4.1, and switched Jest'scoverageProvidertov8.Checklist (Global DoD / PR)
🤖 Generated with Claude Code