Language support

Repowise ships language-aware resolvers under packages/core/src/repowise/core/ingestion/resolvers/. Every language lands on one rung of a five-rung ladder, and the rung decides which pipeline stages produce meaningful output. Languages below the parsing rungs still appear in the documentation and still carry git history.

Coverage matrix#

Tree-sitter parsing stops after the Partial rung. The first three rungs are the 28 languages parsed to a full AST; all five rungs are the 42 on the ladder. Both numbers are worth stating and neither is worth stating alone, so the useful thing to take from this page is the rung your language sits on rather than either count.

SQL and shell sit outside the ladder on purpose, because each has a coverage shape the rungs cannot describe. SQL is parsed by sqlglot rather than tree-sitter and gets symbols, wiki pages and health markers but no call graph, with import edges only inside a dbt project. Shell gets symbols, source edges and function-level complexity, but reachability means little for a script invoked by name.

What each tier gets from the pipeline#

Scala's import resolution is partial: it shares the JVM index with Java and Kotlin and falls back to parsing SBT or Mill build files. Apex has no imports: names resolve case-insensitively within each sfdx project, a declared package dependency or a namespace prefix. Every other Full and Good language resolves imports outright.

COBOL files and programs get no dead-code claims. JCL, schedulers and dynamic program calls are external entry paths the repository graph cannot observe. The one claim is a paragraph that nothing names and nothing falls through into, at low confidence and never deletion-ready.

GDScript has a dedicated import resolver and Godot-specific framework edges, but no named bindings. Scenes, autoloads and class_name declarations connect scripts that no import statement ever linked.

Svelte, Vue and Astro share the TypeScript resolver: a single-file component's <script> blocks (and an Astro file's frontmatter) and markup expressions are projected to a TypeScript buffer at byte-identical offsets, so the same queries, config and code-health dialects apply. Astro frontmatter imports and exports become symbols and edges, PascalCase markup tags become component calls, and pages and endpoints under src/pages are entry points.

COBOL#

COBOL is read in fixed reference format, with EXEC SQL, EXEC CICS and EXEC DLI blocks and COPY statements masked before parsing.

Code health measures each paragraph and section as a function: IF, WHEN arms, PERFORM UNTIL/VARYING loops and AND/OR add to its complexity. The advisory cobol_unstructured_flow marker lists paragraphs with ALTER, GO TO ... DEPENDING ON or a GO TO that does not jump forward to its own ...EXIT, and never deducts from a score. Dynamic CALL targets and free-format source produce no edges.

Salesforce#

Apex (.cls, .trigger, .apex) is a Full language. Lightning Web Components, Aura, Visualforce, flows, Lightning pages and quick actions are entry points, and object and field metadata link to the Apex that names them. Flows and SObject metadata become symbols; Aura and Visualforce markup carries none. References are followed when the name is literal: runtime-built names, and objects with no metadata file in the repository, get no edge. Apex dead-code findings are review-only, since the platform also reaches classes by name, and a third-party library in a static resource counts as vendored. Apex code health carries advisory markers for SOQL injection and related shapes (see code health).

Grammars on offline machines#

The COBOL and Apex grammars download on first use, and only when the repo holds that language. To index offline, stage them on a machine with network access, copy the directory over and point REPOWISE_GRAMMAR_DIR at it.

repowise grammars fetch ./grammars
export REPOWISE_GRAMMAR_DIR=./grammars

grammars fetch DIRECTORY downloads every runtime grammar into DIRECTORY and exits non-zero if any fails. repowise doctor reports whether each grammar is cached, and repowise init warns once, with a file count, when COBOL indexes without symbols because its grammar did not load.

Config and build files#

Framework awareness#

Repowise recognises common framework conventions and emits edges for them, even when the underlying call goes through a decorator or a runtime registry.

Dead-code awareness#

The dead-code detector knows about dynamic dispatch patterns that look unused to a static analyzer but aren't:

• Naming patterns: *Plugin, *Handler, *Adapter, *Middleware
• Dynamic imports: importlib.import_module(), __import__(), dynamic require()
• Framework convention files (Flask blueprints, FastAPI routers, Django apps, Rails controllers, Laravel providers, TYPO3 extensions)
• Deprecation annotations: @Deprecated, [Obsolete], @deprecated and their siblings feed a finding's confidence
• Symbols a docs build or an API dump names, and symbols reached by a framework, a container, or a registration decorator

These are excluded from safe_to_delete findings to keep the false-positive rate near zero.

Code-health marker rollout#

Health markers run off a per-language walker map that is independent of .scm parsing, so a language can parse perfectly for the graph and still need this map before markers fire. This table is most of the reason a language is Full rather than Good.

COBOL measures paragraphs and sections as functions. Apex also gets four advisory markers: SOQL injection, a class with queries and no sharing keyword, hardcoded record Ids and SeeAllData=true tests. Scala has a dataflow def/use dialect, which is what Extract Method needs.

C, F# and Objective-C reach the complexity walker and carry real cyclomatic complexity and maintainability numbers, without the rest of the marker suite. Swift has a complexity map: function rows (CCN, nesting, cognitive complexity, parameters) and class rows (methods, fields, LCOM4, TCC).

Code Health serves findings on every language. Where a layer measured below the precision bar on a language, its findings carry a Preview label with the latest hand-judged measurement, in the web UI, REST, MCP and the CLI.

Every cell is a deliberate call rather than an oversight: a language reaches a dialect or it stays silent, and an n/a records a metric the language cannot carry rather than one nobody got to. Kotlin's Extract Method is blocked on the grammar, not unscheduled.

Adding a language#

Adding new language support is five required steps: a LanguageSpec module, a manual LanguageTag registration, a tree-sitter .scm query file, a LanguageConfig entry, and the grammar dependency. Two of those are one-line registrations, but the LanguageTag edit can't be derived and has to be made by hand. No changes to parser.py, graph.py, or any other analysis core file. See architecture/language-support.md in the OSS repo for the full recipe, including the optional steps that buy heritage extraction, named bindings, and call resolution.