How compatible is esast with the rest of the unist ecosystem?

[Persola]

esast defies the unist specification by not using the children field, and instead storing children under other fields. I assume this was done so that esast could be a superset of ESTree. Modifying the representation of the tree structure itself would seem to have severe implications for compatibility, though, right? I see the children field used in the standard way in a number of unist-util-* packages, so I assume they don't work with esast-formatted trees. The only general-purpose utility that I see reimplemented for esast's structure is estree-util-visit as a replacement for unist-util-visit. Is that because other utilities just haven't been needed yet, or am I somehow overestimating the compatibility issues?

Context: I'm thinking about adopting unist in a project which currently uses a custom AST format. The one feature of the custom format I'm hesitant to give up is having labeled edges between parents and children, which is equivalent to storing children under arbitrary field names. esast therefore provides an example of what it's like to mostly conform to the unist spec, but with labeled edges instead of the children field. At the moment I'm actually leaning towards just adopting standard unist, but I thought I should consider this possibility. Since my motivation for having labeled edges is supporting them in programming language ASTs, this relates to #10.

[wooorm]

I assume this was done so that esast could be a superset of ESTree

Yup! (The rest of my comment aligns with what you found out too!)

And: how even would children work for things can have different “slots”? E.g., arguments and body of a function?

In almost all cases, markup has just one slot of children, assuming attributes don’t have to be nodes.
Programming languages defies this.
Some problems around this exist for JSX, used in MDX, so in markdown, which can have expressions (arbitrary nodes) as their attribute values. But that again is: programming languages.

Similar problems would also present itself for CSTs: in a CST, markup would have to represent whitespace, comments, random stuff, in markup as well.
CSTs is something we’ve approached several times but haven’t done yet with unist/unified.

---

esast is a pretty new addition with xdm/MDX 2 to unist. It’s pretty useful having it “connected” to unist/unified, hence why it exists.

---

I’d recommend trying to stick with normal unist if possible. But if not... 🤷‍♂️

[Persola]

The rest of my comment aligns with what you found out too!

OK, good to hear.

how even would children work for things can have different “slots”?

In my experience, which is 90% playing around on AST Explorer, what you might expect a PL AST spec to represent as a direct child of another syntactic node is often instead wrapped by a node specifying the relation between the two. So if you expected type A to have children of type B, but in two distinct slots, it might actually be that type A has children of types C and D, each representing one of those slots, and then types C and D each have one child of type B. That being said, AST formats also seem to use labeled edges as well, so maybe I would be wise to assume all that flexibility is necessary in the long run.

Some problems around this exist for JSX, used in MDX

Anything you can link me to? I would be useful to see an example of the kind of problem I might run into if I abandon the labels.

CSTs

Luckily, I don't have to deal with CSTs at all.

If you or anyone else knows of any other language-neutral AST specifications out there I'd love to hear about them. I've searched a lot and found very few, and unist is the best for my purposes so far. (For people who might come across this, here's another place I asked about language-neutral AST specs.) If I decide to keep using my own, maybe I'll publish a spec that copies unist but just changes children to a map, or one that also works with esast.