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

> Explore the Code-Graph-RAG language support matrix. Discover which languages offer production-ready parsing and call-graph extraction to enhance your code analysis.

- Repository: [Vitali Avagyan/code-graph-rag](https://github.com/vitali87/code-graph-rag)
- Tags: getting-started
- Published: 2026-08-15

---

**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`](https://github.com/vitali87/code-graph-rag/blob/main/codebase_rag/constants/languages.py) provides canonical identifiers:

```python
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`](https://github.com/vitali87/code-graph-rag/blob/main/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:

```python

# 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`](https://github.com/vitali87/code-graph-rag/blob/main/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

```python
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

```python
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

```python
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`](https://github.com/vitali87/code-graph-rag/blob/main/codebase_rag/constants/languages.py) | Enum definitions, status constants, and `LANGUAGE_METADATA` matrix |
| [`codebase_rag/language_spec.py`](https://github.com/vitali87/code-graph-rag/blob/main/codebase_rag/language_spec.py) | `LanguageSpec`/`FQNSpec` classes, `LANGUAGE_SPECS` registry, lookup helpers |
| [`codebase_rag/constants/lang_tooling.py`](https://github.com/vitali87/code-graph-rag/blob/main/codebase_rag/constants/lang_tooling.py) | CLI messages for grammar management |
| [`codebase_rag/main.py`](https://github.com/vitali87/code-graph-rag/blob/main/codebase_rag/main.py) | Graph orchestration and spec selection |
| `codebase_rag/parsers/*` | Language-specific utility modules (e.g., [`js_ts/utils.py`](https://github.com/vitali87/code-graph-rag/blob/main/js_ts/utils.py), [`csharp/utils.py`](https://github.com/vitali87/code-graph-rag/blob/main/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`](https://github.com/vitali87/code-graph-rag/blob/main/codebase_rag/constants/languages.py).
- Runtime resolution uses `get_language_spec()` and `get_language_for_extension()` from [`codebase_rag/language_spec.py`](https://github.com/vitali87/code-graph-rag/blob/main/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`](https://github.com/vitali87/code-graph-rag/blob/main/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`](https://github.com/vitali87/code-graph-rag/blob/main/codebase_rag/constants/languages.py) and add a corresponding `LanguageSpec` in [`codebase_rag/language_spec.py`](https://github.com/vitali87/code-graph-rag/blob/main/codebase_rag/language_spec.py). The [`codebase_rag/constants/lang_tooling.py`](https://github.com/vitali87/code-graph-rag/blob/main/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`](https://github.com/vitali87/code-graph-rag/blob/main/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.