Babel 8.0.6 and 7.29.9 shipped eight seconds apart

v7.29.9 and v8.0.6 were published eight seconds apart

The release list holds two major lines moving at once. v8.0.6 was published at 13:57:24 UTC on 2026-09-18 and v7.29.9 at 13:57:16 UTC on the same day, with v8.0.5 eleven days earlier. The repository's own package.json carries version 8.0.6 and is marked private, so the main branch builds the 8.x line while the 7.x line is still being patched. Nothing in the short README explains the policy, and the blog at babeljs.io/blog is the place release posts live. The practical consequence is that your dependency declaration is a branch decision. A team on 7.x is not behind in the ordinary sense, they are on a maintained line, and a security fix or a regression can arrive in one line and not the other for weeks. Check which line a package on npm actually resolves to before you assume a changelog entry applies to you.

The REPL link you are handed is preloaded with loose mode and every transform on

The README sends you to a REPL with a query string already filled in, and the parameters change what you see. It sets loose to true, applies the env preset twice as presets=env with the two joined by an encoded comma, turns on shippedProposals, sets sourceType to script, and most consequentially sets forceAllTransforms to true. That last one is why the demo output looks aggressive: the REPL is showing you what a maximal transform produces, not what a normal project configuration emits. If you copy the output shape from that page into a ticket or a Stack Overflow answer, you are describing a compilation no real config produces. For evaluating Babel, paste the same input into a second session with the browsers setting left at its default and compare, because the difference between the two is the part of Babel you would actually configure.

The shipped nullish coalescing example compiles down to loose equality

The README's one worked example starts here:

// ES2020 nullish coalescing
function greet(input) {
  return input ?? "Hello world";
}

and ends here:

function greet(input) {
  return input != null ? input : "Hello world";
}

The output uses != rather than !==, which is the loose equality the REPL's loose flag permits, and it is the only way to express the nullish check without two separate comparisons. That makes the example a demonstration of an option rather than of the default. Nothing in the text mentions the flag, so a reader comparing the input and output sees a transform that looks lossy and cannot tell whether that is Babel's behaviour or a configuration choice. The rest of the flow is the documented one: you write the newest syntax, Babel compiles features down to a version your supported environments run, and everything else in the tool is a plugin or preset deciding how.

make is a front for Makefile.js, which is generated from TypeScript

The build system is three files. Makefile.source.ts holds the logic, a script packs it, and the Makefile delegates to the result:

Makefile.js: Makefile.source.ts yarn.lock .yarn/install-state.gz
	$(NODE) ./scripts/pack-script.ts

Every public target is a one-line forward, build, build-bundle, build-no-bundle, generate-tsconfig, bundle-babel-parser-dts, build-flow-typings, build-standalone, watch, lint, fix, clean and test all call node Makefile.js with the target name. test itself is lint followed by test-only, and code-quality is an alias for lint. A make.cmd file exists for Windows. The consequence is that grepping the Makefile gives you an inventory of names but no behaviour, and a target that does not appear in the Makefile may still exist in Makefile.source.ts. The repository is also a monorepo of many npm packages under packages/, with the sources list covering packages, codemods and eslint, so a change can span a plugin, a codemod and the lint rules in one commit.

Flow, test262 and TypeScript are pinned as commit hashes, not as dependencies

Three upstream toolchains are frozen in the Makefile by revision:

FLOW_COMMIT = ce660230358806c4d210ad24c170b02f5395bfce
TEST262_COMMIT = 7ab7fafa0003f73fc85c1b95d88094d33f7eb8bd
TYPESCRIPT_COMMIT = 2dfdbbabae955186f821925c629a37d8df76bab2

They are not in package.json, so a dependency audit will not show them and renovate will not touch them. The targets that use them are named in the same file, including build-flow-typings for the Flow definitions, build-standalone for the standalone build, and build-typescript-legacy-typings with the comment for TypeScript older than 3.7. That last one is a small artefact of history: the typings Babel ships still have to be consumable by compilers long predating the ones in the lockfile. The consequence for a contributor is that upgrading a type-checking toolchain here is a Makefile edit reviewed on its own merits, and a stale pin shows up as generated output that disagrees with upstream rather than as a failed install.

Every package.json script is a make wrapper, so npm test runs make

The root manifest is private and thin. Its scripts forward: bootstrap, build, lint, test, test-only and fix each call a make target of the same name, and codesandbox:build calls make build-no-bundle. Two scripts do not. postinstall runs node scripts/postinstall.ts, and version runs yarn with the immutable cache flag and then stages the lockfile with git add yarn.lock. The runtime tests have their own entry points, test:esm, and three runtime integration scripts for generating an absolute runtime, running against bundlers and running against node. Underneath, packageManager pins yarn at 4.17.0 with a hash, and the repository carries yarn.lock, a .yarn directory and a .yarnrc.yml. The consequence is that anything which shells out to npm scripts to test a Babel checkout inherits make, Git and a generated file, so an environment without those three fails before it reaches Babel at all.

A handful of volunteers, fifteen sponsor slots, and a roadmap in another repository

The FAQ answers the maintenance question in one line: mostly a handful of volunteers, funded by you. The README then asks for developer time and for funds through Open Collective or GitHub sponsors, and the sponsor block reserves fifteen slots rendered from the Open Collective page. The project describes itself as community-driven and maintained by volunteers, and the site links a team page. Priorities are not written down in this repository: the roadmap lives in the babel/notes repository, TC39 proposal progress in babel/proposals, and release posts on the blog. There is also a podcast and a videos page. The consequence for an adopter is that no company sets the direction on a schedule you can plan around, and the consequence for a contributor is that the good first issue and help wanted labels, plus the link to the closed versions of those same labels, are the real signal about what is worth picking up.

AGENTS.md and AI_POLICY.md sit in the root, and the README points elsewhere

The top-level listing of a compiler project now includes agent instructions and an AI policy, alongside the files a contributor would expect: CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md, CHANGELOG.md and AGENTS.md. The README does not mention the two new files. Its contribution route is unchanged and specific: read CONTRIBUTING.md, fill in the issue template, look for good first issue or help wanted labels, say hello in the development Slack channel, and consider the closed versions of those labels to see what kinds of issues people actually take. A translator's Sublime project, a Gulpfile, five tsconfig files, a tstyche config and a knip config complete the picture of a large repository with several toolchains in it. If you are about to open a pull request against Babel, read the AI policy file first, because the README will not tell you it exists.

Editorial conclusion

Pin the major line you depend on and read the blog post for that release rather than tracking the 8.x default, because the repository's own version field sits on 8.0.6 while 7.29.9 is still receiving patches. Before you patch the toolchain, know that the build runs through make into a generated Makefile.js, and that Flow, test262 and TypeScript are pinned by commit hash, so upgrading any of them is a deliberate edit to the Makefile rather than a dependency bump.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes