Releasing Babel 8 today: ESM-only, drop ES5 default, and a smooth migration path
Today we are releasing Babel 8. It's been 8 years since we released Babel 7. And that's not without reason.
Over these past 8 years, the JavaScript ecosystem has changed significantly. In addition to Babel, SWC and Oxc have emerged as alternative JavaScript compilers, and the JavaScript language itself has evolved with new features and proposals (many of which were prototyped and tested in Babel before being standardized!).
You might imagine that Babel became less relevant because of that. But reality begs to differ. Babel has grown from 1.7 million weekly downloads in 2018, to 651 million weekly downloads this week (Jun 2026). Babel has doubled its weekly download counts in the last year.
This usage comes with a huge responsibility to our users. Babel is used in so many build pipelines across the world that even minor breaking changes can cause hundreds of thousands of developers to be blocked from shipping their code. That's why we've not done a major release with breaking changes in 8 years, and why we are taking a very careful approach to Babel 8.
Today's release is not one with many features. In fact, it has no new features over Babel 7. Instead, we are modernizing Babel at its core, to make it ready for the next 8 years. Babel 8 is now ESM-only, ships TypeScript types for all Babel packages, and also no longer compiles to ES5 and CommonJS by default.
We are doing this to push the JavaScript ecosystem forward. The vast majority of users are on browsers that support ES6 and above. The days of IE11 are long over, so it's time to move on. Babel 8 now targets the evergreen browsers, a moving target. As new features become available widely, Babel will automatically stop compiling them away (reducing your bundle sizes!).
With require(esm) support now available in all LTS versions of Node.js, the ESM-only change is also a natural step forward. It allows us to modernize the Babel codebase and reduce its package sizes, while not breaking users who are still using CommonJS in their own code.
TypeScript types are now available for all Babel packages, which means that you can now use Babel's programmatic API in your TypeScript projects without having to install @types/babel__* packages.
Babel 8 is an incremental improvement over Babel 7, trying to minimize the amount of breakage that users have to go through. For those of you that remember the Babel 5 to Babel 6 and Babel 6 to Babel 7 migrations: don't worry, this time it will be simpler!
Before getting on with the changelog, we want to tell you one more thing. We, the Babel core team, consisting of Huáng Jùnliàng, liuxingbaoyu, and Nicolò Ribaudo, are incredibly grateful to all the companies that have supported the project over the years, and that have made this release possible. However, the amount of donations and sponsorships that Babel has been receiving has unfortunately been steadily decreasing over the past few years. We say more about what that means, and how you and your organization can help, in the Funding section below.
Major Breaking Changes
Babel 8 is ESM-only
Babel now ships as ESM, and requires Node.js 24, 26, or newer.
Node.js 22 and 25 reached end-of-life earlier this year, and will not receive any more security fixes: if you are using any of those versions, or even older ones, we strongly recommend you upgrade to a supported version of Node.js.
Stop compiling to ES5 by default
In Babel 8, @babel/preset-env no longer compiles your code to ES5 by default. Instead, we rely on Browserslist's defaults query, which as of today means roughly defaulting to ES2023. Note that this is a moving target, and it will automatically change over time as users update to newer browsers.
Babel still allows you to compile to ES5 (even to ES3, for some features), but you'll need to explicitly define your targets in your configuration.
As part of this change, @babel/preset-env also defaults to compiling to ESM rather than to CommonJS.
Deprecate loose and spec options
Babel has for a long time supported loose and spec options, both in @babel/preset-env and in individual plugins. They were used to tweak the balance between spec compliance and output size/performance, but it was often unclear how they were actually changing semantics of compiled code.
In Babel 8, we are removing them from @babel/preset-env and deprecating them from individual plugins. Instead, you should use assumptions, which give you fine-grained control over what tradeoffs you want to make.
If you are currently using @babel/preset-env's loose or spec options, we highly recommend you migrate to assumptions before migrating to Babel 8 (they have been supported since Babel 7.13.0). You can find the equivalent assumptions-based configuration in the docs.
Extract polyfill injection to separate packages
In 2020 we started the babel-polyfills project, which allows better control over how Babel injects polyfills while transpiling your code. The original goal was that other polyfill maintainers would be able to implement their own version of the polyfill injector, but in practice core-js remained the only one properly supported.
In Babel 8, we are removing the corejs/useBuiltIns options from @babel/plugin-transform-runtime and @babel/preset-env in favor of babel-plugin-polyfill-corejs3, which provides a centralized way of controlling core-js injection.
We recommend you migrate to this new plugin before updating to Babel 8.
Other breaking changes
There is a large list of additional breaking changes: most applications will be affected by a few of them. You can find the full migration docs in the Upgrade to Babel 8 guide.
If you are developing a tool that internally embeds Babel, or if you maintain Babel plugins and presets, you can read the Upgrade to Babel 8 (API) guide too.
Funding
The Babel core team wants to reiterate how thankful we are for all the companies that have supported the project over the years, and that have made this release possible.
We would like to especially thank Germany's Sovereign Tech Agency, for their significant financial support in the last year, and to Igalia for contributing engineering time over the past few years. We would also like to thank tidelift (Sonar) for help with security-related funding, and to all the companies and individuals that are sponsoring us on OpenCollective and GitHub Sponsors.
We need your help!
Unfortunately, donations in the past few years have been steadily decreasing. If it wasn't for the Sovereign Tech Agency's support, which is scheduled to end soon, and Igalia's, we would not have been able to continue guaranteeing the high quality bar that the project needs to meet.
We've been seeing the opposite trend when it comes to download counts, which keep increasing over time: Babel's user base is not shrinking, and we need your help to continue maintaining it.
If you or your company want to support Babel but aren't sure how, you can donate to us on our Open Collective and, better yet, work with us on the implementation of new ECMAScript proposals directly! Reach out at team@babeljs.io if you'd like to discuss more!
@babel/core, from 2020 to 2026.Screenshot from npmx.dev's
@babel/core stats.Babel 7
With Babel 8 becoming stable, we will stop backporting fixes and new features to Babel 7. We will still provide security support for one year (until June 2027), as per our security policy.
If you need features or fixes that have been released in Babel 8 to be backported to Babel 7, please open an issue or reach out to us at team@babeljs.io. Depending on the amount of requests, we might consider backporting some features on a case-by-case basis.