feat: add .pyi/.phtml/.rake/.gemspec extensions, condense comparison table

[carlos-alm]

Summary

• New file extensions: .pyi (Python type stubs), .phtml (PHP templates), .rake/.gemspec (Ruby) — updated WASM registry, native Rust registry, and import resolution (both JS and Rust sides)
• Condensed comparison table: 28 rows × 8 competitors → 12 rows × 4 competitors. Grouped related features, verified all claims against actual repos, fixed incorrect counts (joern ~12 not 14, code-graph-rag 7 not 11), added security scanning row ("intentionally out of scope"), moved lesser tools to footnote
• Backlog docs: add feature backlog and track file moves in hooks #71 (type inference) marked as DONE with PR feat: type inference for all typed languages (WASM + native) #501 link
• Ruby/HCL type inference column changed from — to N/A with footnote (dynamic/declarative languages)

Test plan

• vitest run tests/unit/parser.test.js — 6/6 pass
• Verify README table renders correctly on GitHub
• Verify .pyi/.phtml/.rake/.gemspec files are picked up by codegraph build

[greptile-apps]

Greptile Summary

This PR extends language support with four new file extensions (.pyi, .phtml, .rake, .gemspec) across both the WASM registry and native Rust registry, and bundles several previously-reviewed fixes: the AST-aware backfillTypeMap shim for native binaries < 3.2.0, depth guards on extractTypeMapWalk, multi-name Go var_spec iteration in both JS and Rust, removal of the dead methodCandidates block, and the corrected integration test comment. The README comparison table is condensed from 28×8 to 12×6 and backlog item #71 is marked done.

Key observations:

• hasReceiver shim heuristic is overly broad — every native build of a repository with zero type-annotated code (plain JS, Ruby, Python without annotations) will run supplementReceiverEdges unnecessarily because nativeEdges.some(e => e.kind === 'receiver') is false. The function is a no-op in those cases but adds an O(all-calls) pass on every incremental build until all binaries hit 3.2.0.
• Missing /__init__.pyi in import probes — .pyi was added to the file-level probe in both resolve.js and import_resolution.rs, but /__init__.pyi was not added alongside /__init__.py. Python stub-only packages (those shipping package/__init__.pyi without a .py) won't have their imports resolved.
• The backfillTypeMap / createParsers() path is correctly memoized; no per-call WASM init overhead.
• Go multi-name var_spec fix is correct in both JS and Rust — value expressions are always wrapped inside an expression_list child node, so iterating direct identifier children captures only the declared names.

Confidence Score: 4/5

• Safe to merge — all logic is correct and the two flagged issues are low-severity gaps rather than regressions.
• The core extension additions and the four fixes from previous review rounds are all correct. The hasReceiver heuristic adds unnecessary work (not incorrect results) on annotation-free repos, and the missing /__init__.pyi is a minor coverage gap in the new .pyi feature, not a breaking change. No data integrity or graph-corruption risk was found.
• src/domain/graph/builder/stages/build-edges.js (hasReceiver heuristic), src/domain/graph/resolve.js and crates/codegraph-core/src/import_resolution.rs (missing /init.pyi probe)

Important Files Changed

Filename	Overview
src/domain/graph/builder/stages/build-edges.js	Adds supplementReceiverEdges shim for native binaries < 3.2.0; removes dead methodCandidates block. The hasReceiver heuristic used to gate the shim will fire on every build for annotation-free repos, adding unnecessary overhead.
src/domain/parser.js	Adds backfillTypeMap (WASM-based, AST-aware) replacing the previous regex shim; integrates backfill into parseFileAuto, parseFilesAuto, and parseFileIncremental. Logic is correct; createParsers() is cached so repeated calls are cheap.
src/domain/graph/resolve.js	Adds .pyi to the JS import resolution extension probe list. Missing /__init__.pyi means package-level Python stub-only packages won't resolve correctly.
crates/codegraph-core/src/import_resolution.rs	Adds .pyi to the Rust import resolution extension probe list (same gap as the JS side: no /__init__.pyi).
crates/codegraph-core/src/parser_registry.rs	Adds .pyi → Python, .rake/.gemspec → Ruby, .phtml → PHP to the native Rust language kind matcher. Straightforward and correct.
crates/codegraph-core/src/extractors/go.rs	Fixes multi-name var_spec extraction by iterating all identifier children rather than using child_by_field_name("name"). Values are always wrapped in an expression_list child, so only name identifiers are captured.
src/extractors/go.js	JS mirror of the Rust var_spec multi-name fix — correct for the same reasons.
src/extractors/javascript.js	Adds depth parameter and if (depth >= 200) return guard to extractTypeMapWalk, consistent with every other type-map extractor in the codebase.
tests/integration/build.test.js	Fixes misleading comment: "native deferred" → "native binary may not be present in all test environments".
docs/roadmap/BACKLOG.md	Marks backlog item #71 (type inference) as DONE with a link to PR #501. Copy change only.
README.md	Condenses comparison table from 28×8 to 12×6, updates language extension lists for Python/PHP/Ruby, clarifies type-inference footnote for Ruby/HCL, and revises roadmap numbering.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[parseFile / parseFiles] --> B{Native engine?}
    B -- No --> C[WASM extract\ntypeMap included]
    B -- Yes --> D[native.parseFile / parseFiles]
    D --> E{typeMap empty\nor missing?}
    E -- No --> F[Return patched result]
    E -- Yes --> G[backfillTypeMap\nWASM AST extraction]
    G --> F

    F --> H[buildCallEdgesNative]
    H --> I[native.buildCallEdges]
    I --> J{hasReceiver\nin nativeEdges?}
    J -- Yes >= 3.2.0 + annotations --> K[Done — native edges used]
    J -- No old binary OR no annotations --> L[supplementReceiverEdges\nJS shim]
    L --> K

    style J fill:#f9c,stroke:#c66
    style L fill:#ffd,stroke:#aa0

Loading

_{Last reviewed commit: "fix: replace regex t..."}

[greptile-apps]

Misleading "native deferred" comment

The comment says // Force WASM engine — typeMap resolution is JS-only (native deferred), but native Rust support for typeMap is fully implemented in this very PR — edge_builder.rs has a complete type-map-aware resolution path, and parser_registry.rs / types.rs expose typeMap through the NAPI layer.

The real reason to force WASM in this test is likely that the native binary isn't guaranteed to be compiled in the CI environment where unit/integration tests run, not that the feature is unimplemented. Using an incorrect rationale here will mislead future contributors and could cause someone to remove native support thinking it's still "deferred".

Suggested fix:

Suggested change

	);
	// Force WASM engine — native binary may not be present in all test environments
	await buildGraph(typedDir, { skipRegistry: true, engine: 'wasm' });

[carlos-alm]

Fixed — updated the comment to: "Force WASM engine — native binary may not be present in all test environments". The original rationale was incorrect since native Rust type inference is fully implemented in this PR.

[greptile-apps]

extractTypeMapWalk has no recursion depth guard

Every other JS type-map extractor added in this PR (php.js, python.js, go.js, rust.js, csharp.js) protects against deep ASTs with an explicit depth limit:

function extractPhpTypeMapDepth(node, ctx, depth) {
  if (depth >= 200) return;

The inner walk closure in extractTypeMapWalk recurses unconditionally into every child node. For pathologically large or deeply nested files (e.g., auto-generated code, deeply nested template expressions), this can exhaust the call stack and throw a RangeError: Maximum call stack size exceeded.

Add a depth parameter and guard, consistent with every other extractor in this PR:

Suggested change

	function walk(node) {
	const t = node.type;
	if (t === 'variable_declarator') {
	const nameN = node.childForFieldName('name');
	if (nameN && nameN.type === 'identifier') {
	const typeAnno = findChild(node, 'type_annotation');
	if (typeAnno) {
	const typeName = extractSimpleTypeName(typeAnno);
	if (typeName) typeMap.set(nameN.text, typeName);
	} else {
	const valueN = node.childForFieldName('value');
	if (valueN && valueN.type === 'new_expression') {
	const ctorType = extractNewExprTypeName(valueN);
	if (ctorType) typeMap.set(nameN.text, ctorType);
	}
	function extractTypeMapWalk(rootNode, typeMap) {
	function walk(node, depth) {
	if (depth >= 200) return;
	const t = node.type;
	if (t === 'variable_declarator') {

[carlos-alm]

Fixed — added if (depth >= 200) return; guard to extractTypeMapWalk, consistent with every other type-map extractor in this PR. The walk closure now takes a depth parameter, incremented on each recursive call.

[greptile-apps]

methodCandidates guard is effectively dead code

ctx.nodesByName is keyed by node.name (see setupNodeLookups), where class methods are stored under their fully-qualified name (e.g., 'Router.get'). When call.name is the simple method name 'get', ctx.nodesByName.get('get') returns only nodes whose literal .name property equals 'get' — i.e., top-level functions, never class methods. The subsequent .endsWith('.get') filter then eliminates those too, so methodCandidates is always empty and the early-return guard never fires.

This means the new type-aware qualifiedName lookup below is always reachable (good), but the intent of the methodCandidates block is misleading and will confuse anyone reading this path. Consider removing the dead block or adding a comment that explains why methodCandidates is always empty:

// nodesByName is keyed by fully-qualified name (e.g., 'Router.get'),
// so get(call.name) never returns qualified methods — this block is a no-op
// and falls through to the type-aware qualified lookup below.
const methodCandidates = ...

[carlos-alm]

Fixed — removed the dead methodCandidates block entirely. Since nodesByName is keyed by fully-qualified name (e.g. Router.get), get(call.name) with a simple name never returns class methods. The type-aware resolution path is now the clear entry point in resolveByMethodOrGlobal.

[greptile-apps]

Go multi-name var declarations only capture the first name

In Go, a single var_spec can declare multiple variables with the same type:

var x, y MyService

In tree-sitter-go the name field of var_spec is a list, but node.childForFieldName('name') only returns the first name identifier. The same limitation exists in the corresponding Rust implementation (extract_go_type_map_depth in go.rs, line ~337).

Variables after the first (y in the example) will silently fail to appear in the type map, causing type-aware method-call resolution to miss them. This won't cause any errors but means the feature is incomplete for this pattern, which is common in Go:

var req *http.Request
var rw, backup http.ResponseWriter

Consider iterating named children or using children_by_field_name (in tree-sitter Rust) / walking all identifier children before the type node (in JS) to capture all declared names in a var_spec.

[carlos-alm]

Fixed — both JS () and Rust () now iterate all identifier children in a \ node instead of using . Multi-name declarations like \ now register all names in the type map.

[carlos-alm]

@greptileai

[greptile-apps]

Regex matches inside comments and string literals

The pattern /(?:const|let|var)\s+(\w+)\s*=\s*new\s+(\w+)/g has no awareness of comment or string context. Code like:

// Legacy: const client = new HttpClient()
const help = "Example: const x = new Foo()";

…would produce spurious { name: 'client', typeName: 'HttpClient' } and { name: 'x', typeName: 'Foo' } entries in the type map. Those entries then flow into supplementReceiverEdges, where ctx.nodesByName.get('HttpClient.someMethod') might accidentally find a real HttpClient.someMethod node in a different file and emit a false calls edge — corrupting the graph for the duration that the shim is active (i.e., all users still on a native binary < 3.2.0).

Even if the false-positive rate is low in typical code, the consequence (phantom call edges) is silent and hard to debug. Consider stripping single-line and block comments before running the regex, or narrowing the pattern to avoid the most common false-positive shapes (e.g., require the match not be preceded by // on the same line).

[carlos-alm]

Fixed — replaced the regex-based extractTypeMapRegex with backfillTypeMap, which uses WASM tree-sitter AST extraction via wasmExtractSymbols. This is context-aware and will not match patterns inside comments or string literals.

[greptile-apps]

Redundant disk read when source is already in memory

parseFileAuto already has the file content in the source parameter. Calling extractTypeMapRegex(filePath) re-reads the same bytes from disk unnecessarily. For single-file incremental rebuilds this doubles the I/O for every file processed on older native binaries.

extractTypeMapRegex could accept an optional source string to avoid the extra read:

function extractTypeMapRegex(filePath, source) {
  let code = source;
  if (!code) {
    try { code = fs.readFileSync(filePath, 'utf-8'); } catch { return []; }
  }
  // ...
}

Then the parseFileAuto call site becomes:

patched.typeMap = extractTypeMapRegex(filePath, source);

The parseFilesAuto and parseFileIncremental paths don't have source readily available, so they keep the current extractTypeMapRegex(r.file) form unchanged.

[carlos-alm]

Fixed — the new backfillTypeMap function accepts the source as a parameter and only falls back to fs.readFileSync when source is not provided. In the batch path (parseFilesAuto), source is already available from the native parse results, so no redundant disk read occurs.

[carlos-alm]

@greptileai