Languages · 50 hand-written analyzers
Fifty languages. One index.
Every language below has its own analyzer writing into the same local graph — no generic fallback a language can drop onto. Open one to see the extensions it claims, the registry ids it answers to, the symbols it records and the relationship types it constructs.
The register.
One card per display family. The dot is the language’s own mark, the line under the name is the extensions the analyzer claims, and the count is how many of the 14 relationship types that analyzer can actually construct.
What an analyzer can say.
Fourteen relationship types, and the number of analyzers that construct each one. A format with no invocation syntax produces no calls edge — that is a fact about the format, not a gap in the tool.
Derived at build time from each analyzer module’s own emitted set. A bar shorter than 50 means the format itself does not carry that relationship.
Three alias ids.
A registry id does not have to be a language. Three ids resolve to a parent analyzer instead of adding a branch — same code path, same relationship vocabulary.
Alias route
TypeScript
The TypeScript analyzer also answers to “tsx”, resolved by the same tree-sitter grammar and the same emitted vocabulary.
typescript · tsx
Alias route
CSS
The CSS analyzer also answers to “sass”, resolved by the same tree-sitter grammar and the same emitted vocabulary.
css · sass
Alias route
HCL / Terraform
The HCL / Terraform analyzer also answers to “terraform”, resolved by the same tree-sitter grammar and the same emitted vocabulary.
hcl · terraform
Where this register comes from.
Extensions, registry ids and the recorded symbols are read from the table the engine’s own SUPPORTED_LANGUAGES registry generates; the relationship types are derived from the analyzer modules in src/ast rather than typed in beside them. If a card here disagrees with the code in front of you, that is a bug worth reporting.