TypeScript: calls to methods of exported object-literal constants resolve no edges (same-file or cross-file) — constant is not a STATIC_MEMBER_CONTAINERS kind

[IAliceBobI]

Summary

Methods defined on an exported object-literal constant are extracted as nodes, but no call site of the shape obj.method() ever links to them — not from another file via import, and not from the defining file itself. codegraph callers / impact return zero, and because this is a static property access (not one of the runtime-dispatch forms), boundary surfacing (#835) doesn't flag it either — the gap is fully silent.

Repro (v1.5.0, macOS arm64)

a.ts:

export const obj = { m() { return 1; } };
export class C { static s() { return 2; } }
export function sameFileCallers() { return obj.m() + C.s(); }

b.ts:

import { obj, C } from "./a";
export function crossFileCaller() { return obj.m() + C.s(); }

After codegraph init:

$ codegraph callers m
ℹ No callers found for "m"        # expected 2 (sameFileCallers, crossFileCaller)

$ codegraph callers s

Callers of "s" (2):
function    sameFileCallers
  a.ts:3

function    crossFileCaller
  b.ts:2

Identical call shapes in the same expressions; the only difference is the container kind.

Real-world scale

In a real TypeScript repo, one exported object-literal serves as the app's API-wrapper namespace (100+ methods, called from everywhere). Measured there: one method with 170+ call sites reports 0 callers, and the wrapper's core call method has ~100 call sites in the defining file alone with ≈0 resolved. export const api = {...} is a common way to organize an API surface in TS, so callers/impact systematically under-report on repos using it.

Root cause

src/resolution/import-resolver.ts:

const STATIC_MEMBER_CONTAINERS = new Set<Node['kind']>([
  'class', 'struct', 'union', 'interface', 'enum', 'trait', 'protocol',
]);

Container.member resolution (#825) only descends into those kinds. A constant container resolves to the constant node and stops — the member node is never reached, so the edge is never minted (the same-file path included).

Suggested direction

Extending the #825 mechanism to constant containers whose initializer is an object literal looks natural: members are already looked up by ${container.qualifiedName}::${member} scoped to the container's file, so name+file scoping should keep the same decoy-safety properties validated for chained resolution in #750. Happy to work on a PR if this direction sounds right.

[colbymchenry]

Reproduced on current main with your a.ts/b.ts exactly: cross-file obj.m() produced an edge to the constant (the #1292 instance-member path can't infer a type from a literal, so it fell back to the constant edge), and same-file obj.m() produced nothing at all (the local-receiver inference finds no declaration, and Strategy 3 only considers method kinds — the literal's members are extracted as plain functions with bare qualified names, m not obj::m).

Your suggested direction was right in spirit, and we went resolver-side rather than re-qualifying the members at extraction (that would mean a byte-parity change in the native kernel for every TypeScript repo). Fix in #1597:

• A new containment lookup: container.member where the container is a constant/variable resolves to the node named member whose source range lies inside the container's, in the container's own file. A helper declared inside a member's body is not a member and is skipped; nothing else in the file can donate a match.
• Wired into both halves: the import path (import { api } from './api'; api.call() → call, confidence 0.9) and the same-file path (0.85). Arrow-property and method members both resolve; C.s()-style statics are untouched; a value holding a factory result (const obj = makeObj()) keeps today's behaviour rather than guessing.

With the fix, codegraph callers m on your repro reports both sameFileCallers and crossFileCaller, and the stray edge to obj is gone — so the export const api = {…} namespace pattern you measured (170+ call sites, 0 callers) should report properly once you re-index on the next release. Thanks for the offer to PR and for the root-cause pointer — it made this quick. If you'd like to help further, running the next release against that real repo and reporting the before/after callers counts would be a genuinely useful validation.