Support of CommonJS for @babel/generator, @babel/traverse and other v8 packages

[coderaiser]

💻

• Would you like to work on this feature?

What problem are you trying to solve?

Would be great if @babel/generator v8 can be not only imported but has also commonjs support, it will make transition smoother and easier.

Describe the solution you'd like

Export commonjs versions of files in a similar to way used in @babel/parser v8

Describe alternatives you've considered

Since ESLint (and lots of other packages) doesn't supports ESM and even async rules, would be great to have both ways to import @babel/generator, @babel/traverse and other packages as ESM and as CommonJS.

Documentation, Adoption, Migration Strategy

No response

[babel-bot]

Hey @coderaiser! We really appreciate you taking the time to report an issue. The collaborators on this project attempt to help as many people as possible, but we're a limited number of volunteers, so it's possible this won't be addressed swiftly.

If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack community that typically always has someone willing to help. You can sign-up here for an invite.

[liuxingbaoyu]

prettier/prettier-vscode#3016
microsoft/vscode#130367

I agree with that. In fact even vscode still doesn't support direct use of ESM, prettier was deeply troubled by it before.

[nicolo-ribaudo]

In Babel 7 we had the problem that some of our dependencies were migrating to ESM and thus we were stuck on older versions (or we had to swap them), I don't want to have the same problem in Babel 8.

Babel is popular enough that we are in a position to push the ecosystem to better support ESM. If vscode didn't support, for example, classes, nobody would even think of opening an issue "please do not use classes because they don't work in vscode": they would instead bug vscode to support that ES6 feature, released 8 years ago.

For ESLint, you can use @babel/eslint-parser which is CommonJS.

[nicolo-ribaudo]

Also note that the reason we had a CJS version for Babel parser was prettier, but now that prettier uses ESM we probably do not need it anymore.

[coderaiser]

The reason I'm asking is eslint-plugin-putout which gives ability to run Babel-based 🐊Putout code transformer, which should also migrate to ESM and most likely it will work slower as sync CommonJS ESLint plugin that somehow loads ESM.

Anyways,

Babel is popular enough that we are in a position to push the ecosystem to better support ESM.

that's true, so if you decide to move ESM-only, I'll try to figure out something to get things working...

[nicolo-ribaudo]

Also, note that ESLint is planning a rewrite that would allow it to support asynchronous parsers/plugins: eslint/eslint#16557

[coderaiser]

Also, note that ESLint is planning a rewrite that would allow it to support asynchronous parsers/plugins: eslint/eslint#16557

Yes, but it takes some time for complete rewrite (maybe year or two 🤷‍♂️), best possible solution would be use both ESM + CommonJS for v8, and use only ESM for v9 for migration period. I just migrated @putout/printer to support all changes from migration guide, but ESLint is blocker for me to upgrade, since in other case I should write from scratch plugins for all IDE's.

Would be great if Babel Team provide some kind of solution or workaround, I see that there is deasync, and even way to use it, which is completely fine, since it has pre-built binaries:

const deasync = require('deasync');
const tryToCatch = require('try-to-catch');

module.exports = (promise, ...args) => {
    let result;

    tryToCatch(promise, ...args).then((a) => {
        result = a;
    });

    while (!result) {
        deasync.sleep(1);
    }

    return result;
};

But it hang when I use it in tests. Maybe you can suggest me some way to run async code in a sync way?

[liuxingbaoyu]

In Babel 7 we had the problem that some of our dependencies were migrating to ESM and thus we were stuck on older versions (or we had to swap them), I don't want to have the same problem in Babel 8.

I agree with that. But I fear there may be worse obstacles downstream. (e.g. Jest was blocked by Node ESM's memory leaks and segfaults for several years)

Would be great if Babel Team provide some kind of solution or workaround, I see that there is deasync, and even way to use it, which is completely fine, since it has pre-built binaries:

As much as I like dasync, it is currently unreliable. The Node team once had a similar PR, but it was rejected.

Maybe you can suggest me some way to run async code in a sync way?

https://github.com/un-ts/synckit

You can try this. While it may not be very convenient, it is relatively reliable.

[coderaiser]

https://github.com/un-ts/synckit

As I understand i doesn't support passing functions, since it is worker thread...

OK, here is one of possible solutions: pre-built all CommonJS in separate package @putout/babel, it will simplify supporting of Babel codebase, and makes ability to use Babel 8 inside ESLint and other places which cannot migrate to ESM now.

[coderaiser]

Unfortunately this way not really works with @babel/core which is more then 6mb bundled, so looks like I'm stuck with Babel v7. For how long it will be supported? Will new features arrive to v7? Can this AST changes came to v7 with some env flag, so v7 was CommonJS and v8 ESM.

[coderaiser]

Just made an upgrade to Babel v8, also for editor and mobile editor 🎉.

It works like a charm 🥳 !

[nicolo-ribaudo]

Awesome, I'm happy you found a solution :)