DEV Community

Cover image for Tree-Sitter Grammars Explained: Leveraging Data for Clarity
Adam Poulemanos for Knitli

Posted on • Originally published at blog.knitli.com on

Tree-Sitter Grammars Explained: Leveraging Data for Clarity

How a Week of Jargon and 25 Languages Resulted in Creating the Parser I Needed


Clarity Engineering


TL;DR: If You're Here Because Tree-sitter's node-types.json Makes No Sense

You're not alone. Tree-sitter's terminology is confusing because it evolved from internal implementation details, not developer clarity.

The Core Problems

  • "Named" doesn't mean "has a name" (everything has a name). It means "corresponds to a named grammar rule" an internal detail that's noise for most use cases.
  • "Fields" and "children" are both parent-child relationships but the distinction is unclear. Fields are semantic ("this node's condition"), children are positional ("this node's first child").
  • Everything is a "type" : Nodes, edges, and abstract categories all use the same terminology, obscuring the differences that matter.

This post uses formatting unsupported by dev.to, please view the rest at our website

Top comments (0)