What Programming Languages Does code-review-graph Support and How to Add New Languages

code-review-graph supports dozens of languages—including Python, JavaScript, TypeScript, Java, Go, Rust, C, C++, PHP, C#, Ruby, and Julia—via Tree-sitter grammars, and enables users to add custom languages through configuration files without modifying core source code.

code-review-graph is an open-source semantic code analysis tool that parses repositories into queryable graphs. It ships with a comprehensive built-in language catalog that maps file extensions and shebangs to canonical language identifiers, while providing an extensible plugin system for adding new languages through simple YAML or JSON configuration files.

Built-in Language Support in code-review-graph

The tool leverages Tree-sitter grammars to parse source code. At the core of its language detection system lies a robust mapping infrastructure that connects file signatures to language parsers.

Extension-to-Language Mapping

The primary registry resides in code_review_graph/parser.py at line 713, where EXTENSION_TO_LANGUAGE defines a dictionary mapping thousands of file extensions to canonical names like "python", "javascript", "typescript", "tsx", "java", "go", "rust", "c", "cpp", "php", "csharp", "ruby", and "julia". When the parser encounters a file, it examines the suffix against this mapping to determine the appropriate Tree-sitter grammar to invoke.

Shebang Detection

For scripts lacking standard extensions, code-review-graph inspects shebang lines. The SHEBANG_INTERPRETER_TO_LANGUAGE dictionary, located at line 819 of parser.py, maps interpreter paths (e.g., #!/usr/bin/python3) to language identifiers. This ensures that executable scripts are correctly categorized even when they use non-standard or no file extensions.

Language Families and Scoped Analysis

Certain languages share structural families. The graph.py file defines these relationships at lines 44-46, grouping related languages like JavaScript, TypeScript, and TSX. Additionally, some advanced analyses—such as receiver-scope and typed-call resolution—only apply to specific languages. The scoped_resolver.py file maintains these lists at lines 72-76, defining _SCOPED_LANGUAGES = ("php", "rust", "csharp") and similar tuples to restrict scope-sensitive operations to supported targets.

How code-review-graph Handles New Languages

Adding support for a new language requires no core code changes. The system provides three extension points that automatically integrate custom definitions into the parsing and analysis pipeline.

Custom Language Configuration Files

Repositories can supply a custom_languages.yaml or custom_languages.json file to declare additional extensions or override existing mappings. The loader in custom_languages.py enforces a MAX_CUSTOM_LANGUAGES = 20 limit to prevent configuration bloat.

The load_custom_languages() function reads these configurations and returns CustomLanguage objects. During parser instantiation, the Parser.__init__ method merges these definitions with built-in mappings at lines 2455-2459:

# From parser.py - merging custom languages into built-in catalog

builtin_extensions=EXTENSION_TO_LANGUAGE,
builtin_languages=BUILTIN_LANGUAGES

This merge strategy allows custom definitions to shadow or extend the default EXTENSION_TO_LANGUAGE dictionary without modifying the source file.

Automatic Tree-sitter Grammar Loading

Once a language identifier is registered, code-review-graph attempts to load the corresponding Tree-sitter grammar automatically. The probing logic in parser.py (lines 610-665) includes _parser_load_probe_succeeds() and _load_tree_sitter_parser() functions that test grammar availability. If the grammar cannot be loaded, the system emits a warning and silently ignores the language, preventing runtime crashes while allowing the analysis to continue for other supported languages.

Integration with the Analysis Pipeline

After registration, the new language automatically participates in the full analysis workflow:

• Node Generation: The generic Tree-sitter visitor creates nodes for functions, classes, imports, and other constructs regardless of language.
• Statistics Aggregation: The get_stats() method automatically includes the new language in its languages set, derived from all parsed node rows.
• Query Support: Language-specific patterns in flows.py and other modules can target the new identifier using entry-name regexes and filters.

Practical Examples

Detecting Languages in a Repository

To list all languages present in a codebase, instantiate the Graph class and inspect the statistics:

from code_review_graph import Graph

graph = Graph(root_path="path/to/repo")
stats = graph.get_stats()
print("Languages detected:", sorted(stats.languages))

# Output: Languages detected: ['python', 'javascript', 'go', ...]

Adding a Custom Language via Configuration

Create a custom_languages.yaml file in your repository root:

- name: "mydsl"
  extensions: [".mydsl"]
  parser: "tree-sitter-mydsl"

Then load the graph with the custom language path:

from code_review_graph import Graph

graph = Graph(root_path="path/to/repo", custom_lang_path="custom_languages.yaml")
print(graph.get_stats().languages)  # Output includes 'mydsl'

Querying Functions by Language

Filter nodes to retrieve functions from a specific language:

from code_review_graph import Query

q = Query(graph)
python_funcs = q.nodes.filter(language="python", kind="function")
for fn in python_funcs:
    print(fn.file_path, fn.name)

Key Source Files for Language Support

File	Purpose	Key Location
code_review_graph/parser.py	Core parser with extension and shebang mappings	Lines 713, 819, 2455-2459
code_review_graph/custom_languages.py	Custom language loader with MAX_CUSTOM_LANGUAGES limit	load_custom_languages() function
code_review_graph/graph.py	Language family definitions and utilities	Lines 44-46
code_review_graph/scoped_resolver.py	Scoped-language lists for advanced analyses	Lines 72-76
code_review_graph/flows.py	Language-specific query patterns	Entry-name regex definitions

Summary

• code-review-graph supports dozens of languages out-of-the-box—including Python, JavaScript, Go, Rust, and Java—via comprehensive extension and shebang mappings in parser.py.
• The tool uses Tree-sitter grammars for parsing, automatically probing for grammar availability at runtime (lines 610-665).
• Users can add custom languages without code changes by providing a custom_languages.yaml file, subject to a limit of 20 custom definitions.
• Custom languages merge seamlessly with built-in mappings during Parser.__init__ (lines 2455-2459) and immediately participate in statistics and query operations.
• Language families and scoped analysis targets are defined in graph.py and scoped_resolver.py, enabling fine-grained control over advanced features.

Frequently Asked Questions

Which programming languages are supported by code-review-graph out of the box?

code-review-graph ships with built-in support for dozens of languages including Python, JavaScript, TypeScript, TSX, Java, Go, Rust, C, C++, PHP, C#, Ruby, and Julia. The complete mapping is defined in the EXTENSION_TO_LANGUAGE dictionary at line 713 of code_review_graph/parser.py, which associates thousands of file extensions with canonical language identifiers.

How do I add a custom language to code-review-graph without modifying the source code?

Create a custom_languages.yaml or custom_languages.json file in your repository root that specifies the language name, file extensions, and Tree-sitter parser name. Pass the path to this file via the custom_lang_path parameter when instantiating the Graph class. The parser automatically merges your definitions with the built-in catalog during initialization.

What happens if a Tree-sitter grammar is missing for my custom language?

If the specified Tree-sitter grammar cannot be loaded, code-review-graph emits a warning and silently ignores that language, allowing the analysis to continue for other supported files. The probing logic in parser.py (lines 610-665) includes _parser_load_probe_succeeds() to test grammar availability before attempting full initialization.

Is there a limit to how many custom languages I can add?

Yes, code-review-graph enforces a maximum of 20 custom languages per repository via the MAX_CUSTOM_LANGUAGES constant in custom_languages.py. This limit prevents configuration bloat and ensures parsing performance remains consistent. If you need to support more languages, you must modify the source code to increase this threshold.

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