Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

TypeScript: a local initialized from a library call takes the one-method guess (follow-up to #2589)

Aperta
  • Qualcosa non va?
#2,947 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
node.js, react, typescript
Ambito
devtools

Direzione di ricerca

Reproduce the five functions from the issue in a TypeScript fixture and run the resolver with CODEGRAPH_KERNEL=0, then trace where a local initialized from an outside-project call is assigned the single same-named project method. Compare that path with the annotated-local handling from #2589/#2811 and the outside-type rule in #2169; the fix belongs there, not in variable-name heuristics. Done means a-d emit no instance-method edge while existing project-local cases still resolve, with coverage for package imports, node: namespaces and DOM-typed receivers.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Follow-up to #2589. A method call on an untyped local initialized from a library call still links to the project's only method with that name. #2811 fixed this for a class component's render() and lifecycle methods, but an ordinary class method is still guessed.

// app.ts
export class App { render(): void {} translate(x: number): void {} close(): void {} }

// use.ts
import { createRoot } from 'react-dom/client';
import * as net from 'net';
import { createServer } from 'net';
export function a(el: HTMLElement) { const root = createRoot(el); root.render(null); }
export function b() { const s = net.createServer(); s.close(); }
export function c() { const s = createServer(); s.close(); }
export function d(canvas: HTMLCanvasElement) { const ctx = canvas.getContext('2d')!; ctx.translate(1); }
export function e(canvas: HTMLCanvasElement) { canvas.getContext('2d')!.translate(1); }
function edge on main expected
a App.render (instance-method) none
b App.close none
c App.close none
d App.translate none
e (chained, no local) none none

Renaming the locals doesn't change anything, so this isn't the variable-name guess in #2946. The chained form e already links nothing; only the assigned local takes the guess. In each case the local's value comes from something the project doesn't declare: a package import, a node: namespace, or a method on a DOM-typed parameter. That fits #2169's "an outside type is not a project type" rule, but the type is never written down, so the rule doesn't fire.

Reproduced on main at 31ec9082 (6162d872 since then only touches the watcher), with CODEGRAPH_KERNEL=0. Linux/WSL2, Node 22.23.2.

Scale (found by checking every TS calls edge against the TypeScript checker). On excalidraw (14bb42e), 63 instance-method edges land on project code where tsc says the method is a library one. For example, every context.translate(…) on a canvas.getContext("2d")! local, as in packages/element/src/renderElement.ts, links to App.translate in packages/excalidraw/components/App.viewport.ts. On this repo there are 58. For example, server.close() on net.createServer(…) in __tests__/cli-unlock.test.ts links to the close() of the viewer's server interface in src/ui-server/index.ts. The interface method gets callers it never has.

Possible direction (not verified). When the local's initializer is a call whose callee resolves outside the project (an import from a package or node:, or a member of a receiver already typed as an outside type), treat the local as outside-typed: the same "no guess" outcome as an annotated const r: Root = createRoot(el) in #2589. #2152 has PHP's version of this ("an untyped receiver keeps a unique method only when named for it").

Related: #2589, #2811, #2169, #2946.

Lingua principale
C
Stelle
73.2k
Fork
4.7k
Merge medio
3h 13m
PR unite (30g)
579

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di colbymchenry/codegraph

Tutte le issue di colbymchenry/codegraph

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.