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

Q: Do we need extra node flags if people are requiring @babel/parser in a Jest vm?

I guess people will need to use --experimental-vm-modules to enable ESM support in Jest, but that's already the case with all the other packages we'll publish.

Actually, looking at jestjs/jest#15275, the answer is: Jest doesn't support require(esm) at all. People require()ing Babel packages inside Jest will either have to use import(), or use jest-light-runner.

I wish require(esm) can support TLA, that's the last block that prevents us from removing the worker implementation of eslint-parser/register.

I wish require(esm) can support TLA, that's the last block that prevents us from removing the worker implementation of eslint-parser/register.

Is it? Since now .parseSync also works with ESM plugins (thanks to require(esm)), it is probably good enough. It will not work with custom plugins that use TLA, but the solution in that case is to pre-load them and pass them in the ESLint config.

I wish require(esm) can support TLA, that's the last block that prevents us from removing the worker implementation of eslint-parser/register.

Is it? Since now .parseSync also works with ESM plugins (thanks to require(esm)), it is probably good enough. It will not work with custom plugins that use TLA, but the solution in that case is to pre-load them and pass them in the ESLint config.

Yes. If a Babel config used import() to load a plugin, then require(@babel/core) will throw top level await is not supported, even if we removed the cjs proxy.