TypeScript: interface members are never indexed (`method_signature`/`property_signature` missing from the extractor) — every call through a `.d.ts` platform API is invisible

[Leopold-Wieser]

Summary

The TypeScript extractor never indexes interface members. interface_declaration is captured, but the method_signature and property_signature nodes inside it are not, so an interface's methods and properties do not exist in the graph.

The consequence is larger than it first looks: for any codebase whose platform/SDK API is expressed as interface method signatures in a .d.ts (very common — a vendored platform SDK, a generated client, @types/*), every call site through that API is invisible, because there is no declaration node for the call edge to attach to.

Java and C# are unaffected: in those grammars interface methods reuse method_declaration, which is already in their methodTypes. TypeScript is uniquely affected because tree-sitter-typescript uses distinct method_signature / property_signature node types.

Repro

api.d.ts, the whole project:

export interface PlatformContext {
  deleteQueueCustomAck(queueName: string, thingId: number): void
  createQueueCustomAckKey(queueName: string, thingId: number): void
  readonly tenantId: string
}

$ codegraph init
● 2 nodes, 1 edges

Nodes by Kind:
  file            1
  interface       1

$ codegraph node PlatformContext
**PlatformContext** (interface)          ← found

$ codegraph node deleteQueueCustomAck
Symbol "deleteQueueCustomAck" not found in the codebase

$ codegraph node tenantId
Symbol "tenantId" not found in the codebase

Zero method and zero property nodes for an interface that declares two methods and a property.

Note the members are found if a class implements them — the class's method_definition nodes are picked up — which is why this is easy to miss. An interface-only declaration file (.d.ts) exposes it cleanly.

Root cause

src/extraction/languages/typescript.ts:

methodTypes: ['method_definition', 'public_field_definition'],
interfaceTypes: ['interface_declaration'],
// no propertyTypes

Neither method_signature nor property_signature appears anywhere in the file (still true on main as of today).

The traversal side is already correct — isInsideClassLikeNode() in src/extraction/tree-sitter.ts already lists 'interface':

return (parentNode.kind === 'class' ||
        parentNode.kind === 'struct' ||
        parentNode.kind === 'interface' ||   // already handled
        ...);

So the walker will attach members to an interface parent as soon as the node types are declared. This looks like a config omission rather than a design decision.

Suggested fix

methodTypes: ['method_definition', 'public_field_definition', 'method_signature'],
propertyTypes: ['property_signature'],

Verified effect

Applied to a local v1.4.1 install:

	before	after
The 5-line repro above	2 nodes, 0 methods	5 nodes, 2 methods, 1 property
A 500KB vendor platform .d.ts (interfaces only)	338 nodes, 247 interfaces, 0 methods	3,892 nodes, 3,507 methods, 51 properties
A real 5,722-file TS monorepo, full re-index	99,046 nodes	115,406 nodes; property 4,454 → 20,741

Re-index cost was unchanged in practice (47s for the monorepo).

Related but distinct

• resolution: an imports edge lands on a class property or interface method that merely shares the imported name (import path from 'node:path' → SomeType::path) #1537 — an imports edge landing on an interface method that shares a name. That one implies interface methods are expected to be addressable; this issue is why they are not, in TS.
• TS/JS class fields with type annotations are extracted as method-kind nodes #808 (closed) — TS/JS class fields extracted as method-kind nodes. Same file, different node types.

Secondary note (not part of this issue)

For the .d.ts-in-node_modules case specifically, the patch alone is not enough, because node_modules is a hard-coded ignore that neither codegraph.json include nor includeIgnored overrides. Indexing the package as its own project works as a workaround. Mentioning only because it is the most common place platform interfaces live; happy to open that separately if it is worth its own discussion.

Environment

• CodeGraph 1.4.1 (behaviour confirmed unchanged on main)
• macOS, TypeScript sources

[maxmilian]

The diagnosis here holds — typescript.ts:44 has no method_signature and no propertyTypes, and interface members never enter the graph. I prototyped the fix locally and hit something that I don't think should be decided in a PR, so I'm putting it here first. Not claiming the issue.

The two-line change collides with ambient-declaration damping (CG-28).

getAmbientDeclarationPathsAmong (src/db/queries.ts:2074) demotes a file when all four of its conditions hold, and condition 2 is that every declared symbol is type-level — the SQL counts interface/type_alias/enum/enum_member/namespace into typeDeclared and requires declared === typeDeclared (:2090, :2097). The comment above it is explicit that the narrowness is load-bearing:

a rule of "no callables" alone flags 1–18% of a repo, including Kotlin sealed classes, Rust mod.rs re-exports and django's locale constant tables — real source that must not be demoted. This rule flags 0–4%

Once interface members are extracted they arrive as method / property nodes, so a .d.ts of pure interfaces stops satisfying condition 2, ambientDeclaration goes false, and the penalty silently stops applying — a vendored shim can then outrank implementation files. __tests__/explore-declaration-only.test.ts catches exactly this; its fixture assertion at :107 (every kind is interface | type_alias) is described in-file as "the structural test the penalty keys on."

What I measured, adding only method_signature to methodTypes and propertyTypes: ['property_signature']:

• Full suite: 2974 pass / 71 fail on unmodified main → 2968 / 78 with the change on this machine. The 71 are pre-existing here; the delta is this interaction.
• Six of the seven are explore-declaration-only.
• Widening typeDeclared to also count nodes a contains edge ties to an interface is not sufficient on its own: with conditions 3 and 4 stubbed out the file goes 6 fail → 4 fail, so the new member nodes also change the edge shape those two conditions read.

The question I'd rather you answer than guess at: should an interface's members count as type-level for CG-28? They have no body and originate no calls/instantiates, so they seem to belong on the same side as the interface that owns them — but condition 2's threshold was measured against a corpus, and I can't tell from outside whether folding members in keeps it inside that 0–4%.

Two smaller notes for whoever implements it:

• tree-sitter.ts:1295 currently handles property_signature / method_signature to hang their type annotations off the enclosing interface. The methodTypes (:1034) and propertyTypes branches run first and both skipChildren, so that branch becomes unreachable the moment the extractor claims those types — I verified this with a throwing probe: zero hits across the extraction suite. The references edges survive (extractMethod and extractProperty each call extractTypeAnnotations) but move from the interface to the member.
• __tests__/extraction.test.ts's [TypeScript] String literal type arguments in generic tuple elements are not indexed as symbols #634 case asserts no method/property node is named id/name/... — but its own fixture declares interface User { id: string; name: string; }, so those names gain a legitimate source. The assertion needs to key on the source (no declaring interface) rather than the name.

Happy to send the extractor half as a PR if you'd rather land it and adjust CG-28 separately, or to do the whole thing once the condition-2 question has an answer.