babel-handbook VS estree

For more information about building Babel plugins, check the Kent's Babel Handbook or this awesome Babel handbook by Jamie.

Babel does this by compiling down JavaScript code written with the latest standards into a version that will work everywhere today. This process is known as source-to-source compiling, also known as transpiring. Source: Jamie Kyle

I'll be honest, my approach to getting used to working with ASTs is a bit weird, but it worked for me. For some reason the thought of working with the TypeScript AST sounds really attractive to me. I'm sure most people recommend to start deep diving into babel first before getting used to working with an AST with the TypeScript compiler, but I started it the other way around. There is a great library called ts-morph that focuses on making it easier for developers to work with the TypeScript compiler. Learning hands on with ts-morph while getting used to their compiler api made babel much easier to understand without ever touching babel.

Those videos gave me a base for the task but I needed more sources to achieve it, so I read a lot of source code for other libraries built with babel-plugin-macros, read the plugin's authoring documentation and Jamie Kyle's Babel Handbook.

If you want to learn more about parsing, reading the code of an actual recursive parser might be a better idea. Esprima is a decent place to start if you're interested in JS grammar. Then you can look at the babel handbook to learn more about AST transformations. From there, the literature gets quite a bit more heavy. If you get this far and are willing to push further, you'll probably want to grab yourself a copy of the dragon book at a minimum.

Babel handbook

ESLint's AST format, ESTree, would represent this line of code as:

That was a super interesting link, thank you.

For the ontological problem, I presume you're referring to how there are so many differing ideas of how to represent ASTs (apologies for mixing languages, these URLs were just handy):

* https://lisperator.net/uglifyjs/ast#nodes

* https://github.com/estree/estree#the-estree-spec

* ... likely others

which makes it hard for ls1 to ask ls2 about "the for-of iteration variable Node" because ls2 could be using UglifyJS or ESTree or their own(!) AST nomenclature?

And all of this is made worse by (e.g.) Java1.3 versus Java19 because languages are rarely static

I find it better to actually look at the AST for javascript.

These are expressions:

https://github.com/estree/estree/blob/master/es5.md#expressi...

These are statements:

https://github.com/estree/estree/blob/master/es5.md#statemen...

I guess the confusing part for many is how an expression can also be a statement. But if you look at the ExpressionStatement you see that an expression is not also a statement. It's just the wrapper statement!

When I started the NodeSecure project I had almost no experience 🐤 with AST (Abstract Syntax Tree). My first time was on the SlimIO project to generate codes dynamically with the astring package (and I had also looked at the ESTree specification).

ESTree compatible output, AST explorer on WASM

The parser we wrote transforms the GraphQL AST into ESTree structure, so it allows you to travel the GraphQL AST tree easily.

For espree parser(the one eslint uses) we can refer here Eslint AST Node Types