Repository navigation
Built-in JS/TS methods on untyped values link to project methods with the same name #1987
Description
What happens
A JavaScript/TypeScript call to a built-in method on a value whose type isn't resolved links to any project method with that name:
// src/cart.ts
export class Cart {
add(item: string): void {}
map(f: (x: string) => string): string[] { return []; }
}// src/tidy.ts
export function tidy(list: string[], seen: Set<string>) {
seen.add('x');
return list.map((x) => x.trim());
}After codegraph init, the graph has tidy → Cart::map as calls. list.map is Array.prototype.map. On larger code the same shape links this.#items.add(x) on a Set to a project class's add, so the callers, impact and trace of such a method fill with unrelated call sites.
Why
isUnresolvedJsMemberCall only declines member calls with three or more segments (a.b.c). A two-segment list.map whose receiver can't be typed falls through to the method-name strategies, which accept any same-named method.
Expected
When the receiver's type is unknown and the method is a JavaScript built-in (Array, Map/Set, Promise, String, Function, EventTarget/EventEmitter, iterators), the call stays unresolved. A receiver that is typed still resolves normally.
A fix we're running
Our fork declines those calls when the receiver is not this/super and the method name is in a built-in method table: bompus#151. On our gate corpora it only removed edges to project methods named like built-ins. Happy to open a PR against main if you'd like this direction.
Activity
fix(resolution): resolve this.#field.method() on the field's type (co…
danusha2345 commentedon Sep 27, 2026
Two PRs cover this.
this.#items.add(x), which fix(resolution): don't guess project methods for untyped JS built-in method calls #1941 alone missed. A call through an ES private field was emitted as the bareadd, so it never reached the typedthis.<field>path (TypeScript: a call throughthis.<field>resolves to the ENCLOSING method when the two share a name — silent self-edge, 0% recall on that shape #1496). It now resolves on the field's declared or constructed type, so aSetfield yields no edge.Checked on the fixture from this issue, plus a
Storeclass with#items = new Set<string>()andput(x) { this.#items.add(x) }:callsedgesmain(ba3c21e)tidy → Cart::map,Store::put → Cart::addStore::put → Cart::addtidy → Cart::mapMerge codex/integration-all-2026-09-26 (colbymchenry#1987, colbymchen…
fix(resolution): require receiver evidence for built-in method calls (#…
colbymchenry commentedon Sep 27, 2026
Thanks for the detailed report, @bompus, and thanks for using CodeGraph! This is fixed on
mainby #2028, which builds on @danusha2345's #1990 (thank you!): a built-in method call such aslist.map(),cache.get()oremitter.emit()on an untyped value no longer links to a project method of the same name, while calls on a constructed, imported, typed orthis.#privatereceiver still resolve. The fix will be in the next release.Merge upstream/main (71 commits, through e63fe2e) into fork/consolidated
perf(resolution): answer an absent call name without inferring the re…
perf(resolution): answer an absent call name without inferring the re…