Code-Graph-RAG Language Support Matrix: Complete Guide to Supported Languages and Features

Code-Graph-RAG supports 13 programming languages with production-ready parsing and call-graph extraction, including Python, JavaScript/TypeScript, Java, Go, Rust, C/C++, C#, PHP, Lua, Dart, and Scala (in development).

The Code-Graph-RAG repository implements a language-agnostic code analysis engine that builds call-graphs across heterogeneous codebases. Its multilingual architecture relies on a three-layer design: a centralized language registry, per-language metadata definitions, and concrete parser specifications that drive Tree-Sitter grammars. This article breaks down the complete language support matrix and explains how each layer works together.

---

How Language Support Is Structured

Code-Graph-RAG organizes multilingual capabilities across three tightly-coupled components in the source code:

Component	Location	Purpose
SupportedLanguage enum	codebase_rag/constants/languages.py#L20-L35	Stable identifiers for every supported language
LANGUAGE_METADATA	codebase_rag/constants/languages.py#L48-L69	Support status, feature lists, and display names
LanguageSpec / FQNSpec	codebase_rag/language_spec.py#L14-L66	File extensions, node types, import handling, and parsing queries

This separation allows the graph builder to treat languages uniformly while preserving language-specific parsing logic.

---

SupportedLanguage Enum and Status Levels

The SupportedLanguage StrEnum in codebase_rag/constants/languages.py provides canonical identifiers:

class SupportedLanguage(StrEnum):
    PYTHON = "python"
    JS = "javascript"
    TS = "typescript"
    TSX = "tsx"
    C = "c"
    CPP = "cpp"
    LUA = "lua"
    RUST = "rust"
    JAVA = "java"
    GO = "go"
    SCALA = "scala"
    PHP = "php"
    CSHARP = "csharp"
    DART = "dart"

Each language maps to a LanguageStatus of either FULL (production-ready) or DEV (experimental). Only Scala currently carries DEV status; all others are FULL.

---

Complete Language Support Matrix

The LANGUAGE_METADATA dictionary in codebase_rag/constants/languages.py#L48-L69 serves as the authoritative language support matrix:

Language	Status	Key Features
Python	FULL	Type inference, decorators, nested functions
JavaScript	FULL	ES6 modules, CommonJS, prototype methods, object methods, arrow functions
TypeScript	FULL	Interfaces, type aliases, enums, namespaces, ES6/CommonJS modules
TypeScript (TSX)	FULL	All TS features plus JSX elements and components
C	FULL	Functions, structs, unions, enums, preprocessor includes
C++	FULL	Constructors, destructors, operator overloading, templates, lambdas, C++20 modules, namespaces, preprocessor macros
Lua	FULL	Local/global functions, metatables, closures, coroutines
Rust	FULL	impl blocks, associated functions, macro_rules! macros
Java	FULL	Generics, annotations, modern features (records/sealed classes), concurrency, reflection
Go	FULL	Receiver methods with cross-file binding, structs, interfaces, type declarations, function-local types
Scala	DEV	Case classes, objects
PHP	FULL	Classes, interfaces, traits, enums, namespaces, PHP 8 attributes
C#	FULL	Namespaces (block and file-scoped), classes/structs/records/interfaces/enums, generics, inheritance/interfaces/overrides, typed call resolution with overloads, using directives
Dart	FULL	Classes, mixins, extensions, enhanced enums, factory/named constructors, Flutter widgets, package/relative/dart: imports, part directives, pubspec dependencies

---

LanguageSpec and Runtime Resolution

Concrete parsing behavior lives in codebase_rag/language_spec.py. Each LanguageSpec instance bundles:

• File extension mappings
• Tree-Sitter node types for functions, classes, and modules
• Import/require detection logic
• FQNSpec (fully-qualified name resolution rules)

The module builds an O(1) lookup table at import time:

# From codebase_rag/language_spec.py

_EXTENSION_TO_SPEC: dict[str, LanguageSpec] = {}

for _config in LANGUAGE_SPECS.values():
    for _ext in _config.file_extensions:
        _EXTENSION_TO_SPEC[_ext] = _config


def get_language_spec(file_extension: str) -> LanguageSpec | None:
    """Return the LanguageSpec for a given file extension."""
    return _EXTENSION_TO_SPEC.get(file_extension)


def get_language_for_extension(file_extension: str) -> cs.SupportedLanguage | None:
    """Return the SupportedLanguage enum value for a file extension."""
    spec = _EXTENSION_TO_SPEC.get(file_extension)
    if spec and isinstance(spec.language, cs.SupportedLanguage):
        return spec.language
    return None

The main graph builder in codebase_rag/main.py calls these helpers during repository traversal to select appropriate parsers dynamically.

---

Working with the Language Support Matrix in Code

Query Language Metadata

from codebase_rag.constants import languages as cs

lang = cs.SupportedLanguage.JS
meta = cs.LANGUAGE_METADATA[lang]
print(f"{meta.display_name} ({meta.status.value}): {meta.additional_features}")

# Output: JavaScript (FULL): ES6 modules, CommonJS, prototype methods, object methods, arrow functions

Resolve Parsing Spec from File Extension

from codebase_rag.language_spec import get_language_spec, get_language_for_extension

ext = ".cpp"
spec = get_language_spec(ext)
print(f"Language for {ext}: {spec.language}")

# Output: Language for .cpp: cpp

print(f"Function node types: {spec.function_node_types}")

Build a Multi-Language Call-Graph

from pathlib import Path
from codebase_rag.main import build_graph

repo_root = Path("/path/to/mixed/codebase")
graph = build_graph(repo_root)  # Automatically selects specs per file extension

print(f"Graph contains {len(graph.nodes)} nodes across {len(set(n.language for n in graph.nodes))} languages")

---

Key Design Benefits

Extensibility — Adding a new language requires only three steps: extend SupportedLanguage, add a LanguageMetadata entry, and implement a LanguageSpec with appropriate Tree-Sitter queries.

Consistency — Higher-level graph logic operates against the abstract FQNSpec interface, enabling uniform traversal regardless of source language.

Performance — Extension-to-spec resolution happens once at import time via dictionary lookup, eliminating repeated filesystem scans or string parsing during graph construction.

---

Related Source Files

File	Responsibility
codebase_rag/constants/languages.py	Enum definitions, status constants, and LANGUAGE_METADATA matrix
codebase_rag/language_spec.py	LanguageSpec/FQNSpec classes, LANGUAGE_SPECS registry, lookup helpers
codebase_rag/constants/lang_tooling.py	CLI messages for grammar management
codebase_rag/main.py	Graph orchestration and spec selection
codebase_rag/parsers/*	Language-specific utility modules (e.g., js_ts/utils.py, csharp/utils.py)

---

Summary

• Code-Graph-RAG supports 13 languages with 12 at FULL status and Scala in DEV.
• The language support matrix lives in LANGUAGE_METADATA inside codebase_rag/constants/languages.py.
• Runtime resolution uses get_language_spec() and get_language_for_extension() from codebase_rag/language_spec.py for O(1) lookups.
• Each language's parsing behavior is encapsulated in a LanguageSpec that configures Tree-Sitter grammars, node types, and import handling.
• The architecture enables uniform call-graph construction across heterogeneous repositories without language-specific branches in core logic.

---

Frequently Asked Questions

How do I check if a specific file extension is supported?

Use get_language_spec() from codebase_rag/language_spec.py. It returns None for unsupported extensions or a complete LanguageSpec otherwise. Alternatively, check get_language_for_extension() to receive a SupportedLanguage enum value directly.

What distinguishes FULL from DEV language status?

FULL languages have complete Tree-Sitter query coverage, tested call-graph extraction, and stable import resolution. DEV languages (currently only Scala) have partial implementations with known gaps in feature coverage and may produce incomplete graphs.

Can I add a new language without modifying core files?

You must extend SupportedLanguage in codebase_rag/constants/languages.py and add a corresponding LanguageSpec in codebase_rag/language_spec.py. The codebase_rag/constants/lang_tooling.py module contains CLI scaffolding to assist with grammar integration, but registry entries require source modifications.

How does Code-Graph-RAG handle multi-language repositories?

During traversal, build_graph() in codebase_rag/main.py calls get_language_for_extension() for each file and instantiates the appropriate LanguageSpec. The resulting graph nodes carry a language attribute, enabling mixed-language analysis and filtering.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}