add support for ALL languages having Tree-sitter grammar.

[vitali87]

See: https://github.com/vitali87/code-graph-rag/blob/main/docs/advanced/adding-languages.md
It is better to add all langauges ourselves in development mode and get rid of this adding-languages option for users. Any thoughts?

[vitali87]

Thoughts, as asked — with the caveat that the decision is yours and I have not implemented anything.

Short version: I think you are right, and the evidence for it is already in the repo.

The current option promises more than it delivers

docs/advanced/adding-languages.md advertises exactly this:

cgr language add-grammar ruby
cgr language add-grammar kotlin

Both of those have open issues asking for support (#118, #1233). If add-grammar genuinely delivered support, those issues would not exist. That gap is the argument for your position, stated by the repo itself.

What add-grammar actually produces

It wires node-type tuples into language_spec.py from node-types.json. What it cannot infer is everything language-specific:

• codebase_rag/tools/language.py contains no reference to LanguageHandler — the flow never produces one
• 9 handler registrations against 15 SupportedLanguage members

So the output is a language that parses and yields definitions, and then diverges from a supported language in ways nobody sees until they look.

I measured exactly this on Scala last week

Scala had node-type tuples wired and no handler. It produced classes, objects, traits, methods, modules and CALLS — and:

• no INHERITS edges at all — extends A with B produced nothing
• no import resolution — every form returned an empty mapping
• and once inheritance existed, foo.Service[Int] bound to a same-named local class, inventing an edge the source never expressed

None of that is inferable from node-types.json. Each needed reading the grammar and deciding what the language means. That is the work add-grammar cannot do and quietly implies it has done.

Why "development mode only" is the sounder default

The failure mode of a self-service path is silent partial support: a user adds Kotlin, indexes, gets a graph, and has no way to know it is missing inheritance and imports. There is no error — just a quieter graph. That is the same silent-smaller-than-truth shape that has produced several bugs here already.

Doing it in development means each language arrives with a handler, fixtures and an oracle, and the support matrix means something. It also makes the demand question honest: the cost of a language is not "run a command", it is the handler work, so deciding which languages to do is a real prioritisation rather than a config toggle.

Two caveats

1. Removing the option is a breaking change for anyone using it today. A deprecation that keeps it working while stating the limitation would land the honesty without the breakage.
2. The docs are the more urgent fix either way. Whatever you decide about the command, "What Happens Automatically → Enables Parsing" currently reads as "you now support this language". It does not say the result lacks a handler. I would correct that regardless — it is what makes the current state misleading rather than merely limited.

Happy to implement whichever direction you pick. Not proceeding on my own, since the question you asked is a product decision.