Supported Languages and Config Formats

Supported Languages and Config Formats

Use this page for

checking whether a file type is supported for indexing, search, syntax diagnostics, repository intelligence, or structural edits.

Source Languages

SymForge uses tree-sitter extractors for 19 source languages.

Group	Languages
Core coding paths	Rust, Python, JavaScript, TypeScript, Go
Broader backend/system languages	Java, C, C++, C#, Ruby, PHP, Swift, Kotlin, Dart, Perl, Elixir
Frontend assets	HTML, CSS, SCSS

Support depth is not identical across all languages. Start with read/search flows on unfamiliar file types before relying on structural edits.

Config And Document Formats

Format	Extensions	Indexed facts
JSON	.json	Nested key paths
TOML	.toml	Tables, keys, arrays of tables
YAML	.yaml, .yml	Nested key paths and CI workflow facts where applicable
Markdown	.md	Section-header hierarchy
Env	.env	Variable names

GitHub Actions YAML

GitHub Actions workflow files receive extra repository-intelligence facts through the YAML extractor. SymForge can surface:

• workflow name
• trigger keys
• permissions
• top-level env keys
• job names
• job needs
• job runs-on
• strategy matrix keys and values
• step name
• step uses
• step run
• step working-directory

Normal, large, empty, comment-only, and malformed workflow fixtures are covered in the test corpus.

Syntax Diagnostics

Use validate_file_syntax when a source or config file may be malformed. For code files, diagnostics come from tree-sitter. For supported config formats, diagnostics use the relevant parser when available.

Malformed files should be isolated. A bad file may be degraded or excluded from symbol-level answers until it reindexes cleanly, but it should not poison the whole repository.

Editing Support

Editing support is format-sensitive:

• source-code symbols are the primary structural-edit target;
• JSON, TOML, and YAML can participate in structured config inspection and some symbol-like edits;
• Markdown and env files are usually better served by exact reads or scoped text edits;
• HTML, CSS, and SCSS should be treated conservatively unless the project has validated the target workflow.

Practical Guidance

• Use get_file_context first for source files.
• Use get_file_content when exact literal text matters.
• Use search_text(structural=true) for AST-shaped source-code search.
• Use validate_file_syntax before editing malformed config.
• Use analyze_file_impact after changing indexed files.