Model transformation after babel, esbuild or TypeScript?

[Boshen]

I didn't have anyone to talk to when I started the transformation prototype. I modeled it after babel because of its completeness.

The current dx of porting babel is painful and burned both me and @Dunqing out.

But now we have more people involved (@Dunqing, @milesj, @rzvxa and @overlookmotel),
I'd like to rethink about this and plan it out so we can finish it quickly.

The end goal is to make this work in Rolldown, asap. The current approach is not working.

[Boshen]

Babel

[Boshen]

I picked babel because of its completeness, and also the ability to turn off individual plugins.

[Boshen]

esbuild https://github.com/evanw/esbuild/blob/main/internal/js_parser/js_parser_lower.go

[Boshen]

The API surface for esbuild is way simpler. It maybe harder to find how scopes and symbols are constructed.

[Boshen]

TypeScript https://github.com/microsoft/TypeScript/tree/main/src/compiler/transformers

[rzvxa]

I picked babel because of its completeness, and also the ability to turn off individual plugins.

I personally think that whatever we base our transformers on, We should keep them decoupled and have them configurable with TransformerOptions, I think the ability to turn on and off individual plugins is under-rated especially if we want to add some kind of plugin binding for external transformers for the custom builders(let's say a proposal or a JS framework want to implement a new feature on top of it), With that said I'm not sure how much a rust API binding would be useful since most people prefer to write them in javascript instead. We can always easily group options together but we can't go and decouple things after the fact as easily nor as quickly as the other way around.

I'm partially familiar with typescript and babel since I've studied them before and in the case of babel right now I have a pretty good understanding of how things are laid out there for transformers since I was reading them searching for easier ones to implement first. That is actually where I thought of #2818 because it would've provided most of the prerequisites of Babel API given that our approach is much bare metal than theirs.

---

I prefer a more rusty approach, For example, the CreateVars used for creating the lowered variables is an awesome example. It does the exact same thing as what the Babel does but it is implemented nicely and naturally with rust in mind. I think with a few more things like this figured out we can easily write any transformers no matter what our reference is, Right now our toolset and API are limited and that's where most of the pain comes in so the bottom-up approach might prove really useful.

---

The current dx of porting babel is painful and burned both me and @Dunqing out.

Since we already have some of the easier transformers ported from Babel, What were some of the more painful and hideous things to do while porting? We might have something here if we figure out the rough edges.

[Boshen]

What were some of the more painful and hideous things to do while porting?

All the low hanging fruits, edge cases, and process.env.BABEL_8_BREAKING.

[Boshen]

Whichever we pick we'll need to conform to their test suite.

tsc and babel has the most comprehensive test suite, while esbuild have tests all over the place.

[Boshen]

I'm going to make the call here. We'll continue work with babel, due to babel being

• more configurable
• battle tested with better test suite
• familiarity