Possible move to ESTree?

[RReverser]

ESTree is a standard JavaScript AST representation used by most of devtools (parsers - Acorn, Esprima, ..., transformers, transpilers like Babel, etc.).

Looking at your currently used format, it seems to be simple to migrate, and would allow to interoperate with those tools (feed input from alternative parsers or from transpiler's output).

Would you be open for such migration?

[chicoxyzzy]

I believe that interop with ESTree compatible tools will open very cool possibilities

[jdalton]

Related Shift \cc @michaelficarra

[RReverser]

Well, to be honest, Shift is a good & convenient alternative, but not a community standard. /cc @dherman @mikesherov @sebmck

[mikesherov]

Output to multiple formats is always an option. As far as builtin communities go, ESTree makes sense, but shouldn't preclude a long term goal of also supporting Shift.

[sebmck]

Biggest benefit to ESTree is interoperability which Shift does not have (I know an AST converter exists but it's not really the same thing). Is any outside of Shape using Shift anyway?

[RReverser]

@mikesherov It's not about output but more about input (ability to generate WebAssembly from readily transformed AST). Of course, Shift can easily be plugged in as well, since they already have transformer to ESTree AFAIK.

[mikesherov]

@RReverser right. I meant input.

[michaelficarra]

@RReverser

ability to generate WebAssembly from readily transformed AST

Shift is designed primarily for being the ideal AST for transformation. I recommend you read our blog post about it (which is a bit dated now) to understand our motivations.

As an example, consider the program var a; for(var b;;);. ESTree represents both var a and var b as VariableDeclaration nodes. Shift chooses to wrap the VariableDeclaration node representing var a in a VariableDeclarationStatement node. This is one part of many considerations that were taken in order to give you the guarantee that you can safely replace any Statement node with any other Statement node. You don't have that or any of the many other important features that make for a decent experience transforming ASTs with ESTree.

Shift is a good & convenient alternative, but not a community standard.

Though you may not want to call it a "community standard" because we haven't received much input from the community during its design, we have always asked for community involvement, and anyone can read, fork, and implement the specification freely because we have licensed it under the Apache 2 license.

Of course, Shift can easily be plugged in as well, since they already have transformer to ESTree AFAIK.

And from ESTree to Shift, so the other way around is just as much a possibility.

I'm not personally opinionated about what format this project accepts, but I don't want the decision to be driven by misinformation from this thread. Also, it seems to me that neither of these formats are ideal given the goals listed in the README. It would probably be best for each community to create a transformation from their preferred AST representation to the one that is actually ideal for this project.

Thanks for the mention, @jdalton.