Big idea: Interpret babel config

[Milo123459]

A lot of big projects have custom babel config, which is not allowing them to use SWC (for example, some large scale Next.js apps have babel config so they can't use SWC). In order to promote usage, and this has a very low-priority due to it essentially having to support everything babel can do, it interprets the Babel config and runs it via SWC. This would mean you get the speed of SWC whilst having the good config from Babel.

Just a little idea I had, and I didn't see anything about it so I thought I'd make this. This doesn't need priority or anything, and is probably a late term goal.

[kwonoj]

I've been thinking this idea bit as well. This'll obviously can help to reduce some migration churn. But also problem is if application is reasonably small enough it'll be straightforward config conversion can be done in a short time, in opposite if application is large enough it'll have a lot of custom configs / plugins may not able to replicated automatically.

The closest model I can think of is something like https://github.com/typescript-eslint/tslint-to-eslint-config.

• Converts your TSLint configuration to the closest reasonable ESLint equivalent : babel / swc in this case
• Try to emit reason if there's no equivalent or similar config if it cannot be migrated, make a leftover user can manually proceed

While SWC is close drop-in replacement to babel even for today, probably we can't make 1:1 corresponding configs. As long as tool can notify those to users it'd be probably fine though. Probably worth for a userland implementation?

[Milo123459]

I think it is theoretically possible to support every Babel config and run it via SWC. It's just a matter of time. For this to be achieved, we simply have to find the best solution to converting the configuration. You of course have the .babelrc in the project, but then if that extends something (ie next/preset) we would have to interpret that. It's a long list of things to interpret, but overall would be worthwhile IMO. I imagine this taking a while to convert so what could happen is it converts the file and generates a .swcrc, then, if .babelrc changes, it updates the .swcrc. This could make migration to SWC to get the speed of it theoretically no-hassle and no configuration required, it just generates and out comes SWC config from your previous babel config.

[kwonoj]

Hypothetically yes, but given a lot of babel configs are 1. Actually JS codes, which runs several dynamic values specific to babel 2. SWC's config is not 1:1 correspond to babel (this is probably solvable though) 3. Non-core plugin, or preset, or etcs in config value cannot be ported over - there won't be corresponding swc plugin, etcs will be available to achieve same behavior.

tslint-eslint migration already proves how hard it is to make perfect migration in a real world. It does great job, but cannot make all the things work automatically at once.

I don't have strong suggestions around how this should be approached, in the end it's up to someone who'll work on this. My take is 1. I think this is probabably better to be userland that swc/core may not able to expand its responsibility to create interops 2. I think eslint's approach seems more feasible by trying best and let user adjust remaining pieces.

[Milo123459]

Number 2 can be solved, and, the js functions can just be interpreted and run by some runtime (if not a mini version of v8)