TypeScript external named-import calls resolve to unrelated local same-name functions #330

Summary

For TypeScript/TSX, a call through a named import from an external package can be resolved to an unrelated same-named function inside the repository.

This produces a false calls edge rather than an undercount. graft callers, repo-map hotspots, and transitive blast-radius walks can therefore report that production code depends on a test helper or mock that it never imports.

Because traversal does not expose inferred confidence, these false edges are indistinguishable from extracted ones. The graph therefore cannot be trusted for repository orientation or change-impact decisions without manually verifying the underlying imports and source.

Environment

• @nanonets/graft 0.16.0
• macOS arm64
• Node.js 24.17.0
• Also confirmed in current main at 3a85a2f40e283ac0c9b617d9a4bead18d73c3c70

Minimal reproduction

Create two TypeScript files:

// src/component.ts
import { useRouter } from "next/navigation";

export function Component() {
  return useRouter();
}

// test/next-navigation-mock.ts
export function useRouter() {
  return { push() {} };
}

Then run:

graft build .
graft callers useRouter --json --no-refresh

Actual behavior

The local test/next-navigation-mock.ts#useRouter symbol receives an incoming calls edge from src/component.ts#Component, even though that file imports useRouter from the external next/navigation package.

The same pattern occurs with test-framework imports: calls to expect() imported from vitest can be attached to an unrelated unique local helper named expect.

Expected behavior

The external call must not resolve to the local mock/helper. If the imported module cannot be resolved to a file in the repository, the call should remain external/unresolved or be omitted.

Root cause

The extractor already collects TypeScript named-import bindings, including the local name, exported name, and module specifier:

• collectImportedSymbols()
• collectTsImportBindings()

That provenance is used for non-call references, but it is not attached when a call edge is captured. The raw call keeps only the bare callee name, member flag, and source file:

• call-edge capture

The resolver then sends the bare name through resolveName(). If there is exactly one same-family function with that name anywhere in the repository, it becomes the target with confidence: "inferred":

• bare-call resolution
• resolveName() unique-global fallback

This is especially misleading because traversal drops edge confidence. EdgeHit and the JSON/human callers output do not expose that the edge was inferred:

• EdgeHit construction
• callers --json hit shape

Why this matters

• A unique collision is treated as a positive match; adding a second unrelated local definition would instead make the edge disappear as ambiguous.
• Test helpers and mocks can become false production hubs.
• --depth all can propagate the false edge into a much larger reported blast radius.
• The normal and JSON outputs look as authoritative as extracted edges, so callers cannot filter or audit inferred results.

Suggested fix

1. Preserve import provenance on bare call edges. If the callee identifier is a named import, carry its exported name and module specifier into RawEdge.
2. Resolve that call only within the resolved in-repo target module. If the specifier is external or unresolved, do not fall back to the repo-wide name index.
3. Respect lexical shadowing: a same-file local binding should win when it actually shadows the import.
4. Preserve confidence through EdgeHit, CLI JSON/human output, MCP results, and transitive walks so any remaining inferred edges are visible and filterable.

Suggested regression cases:

• external named import colliding with one local function
• in-repo named import with another same-named function elsewhere
• aliased named import
• local lexical binding shadowing an import
• callers output preserving extracted versus inferred confidence

Related issue

#68 discusses opt-in inferred calls for C/C++ and explicitly requires confidence labeling. It does not cover JS/TS named-import provenance or this external-import false-positive behavior.