Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/60804

Open in StackBlitz

commit: 007f7bd

require(esm) still doesn't support top-level await, but this usage doesn't seem to exist in our worker.

require(esm) still doesn't support top-level await, but this usage doesn't seem to exist in our worker.

Users can use top level await in babel.config.mjs, since the eslint-parser could be required from eslint.config, maybe we should add a test case about this scenario.

By the way, ESLint v10 is about to be released as a stable version. Do we plan to drop ESLint v8?

Technically without the worker we don't support top-level await, but I suspect that that's fine. The motivation for the worker was originally to use ESM, I expect that top-level await in Babel configs is very rare and can be replaced with sync operations (since probably the only common I/O might be to read some config file somewhere).

It may be a bit late to drop asynchronous support now, because our core has supported asynchronous operations for a long time, many plugins have already used asynchronous operations, and some third-party packages only provide asynchronous operations.

I will investigate how much time it takes us to execute the entire configuration file in order to obtain the parser options.

Users can do this with the fast path now. :)

I mean for when they still have a config, since in most cases everything will be fully sync anyway. Or we should at least document that if you have configFile: false then it will run in the same thread.

It seems most users only need to provide a list of parser plugins.
They can be configured using configFile: false + parserOpts: {}.

By the way, I remember we used to want to disable the babelrc search by default in Babel 8.
Because it significantly impacts performance.

The motivation for the worker was originally to use ESM, I expect that top-level await in Babel configs is very rare and can be replaced with sync operations (since probably the only common I/O might be to read some config file somewhere).

Before require(esm) is implemented, the top level await scenario I can think of is that users might migrate old config from

{
  plugins: [
    require("@babel/plugin-transform-class-properties")
  ]
}

to

{
  plugins: [
    await import("@babel/plugin-transform-class-properties")
  ]
}

because it is easier to find-and-replace and users don't have to name every plugins again in static import. Now that require(esm) is there, they can probably stay with require so top level await should be rare for Babel 8 users.

It seems most users only need to provide a list of parser plugins. They can be configured using configFile: false + parserOpts: {}.

Yes, but that requires duplicating your syntax configuration across your Babel config ans ESLint config.

I just tested the performance of using vs not using the worker in our repository (by commenting out the @typescript-eslint usage since it would dominate the linting time, and using Babel to parse everything), and there is zero difference. I am not worried anymore about this PR.

To recap, since a couple of things changes since @JLHwung's approval:

• we still support TLA and export default async function in configs
• we will now always use the worker
• the entry point is now @babel/eslint-parser, and @babel/eslint-parser/experimental-worker is gone
• the worker does not have a noticeable performance overhead