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

TypeScript: a local that shadows a project import is ignored from a nested arrow; the call links to the import

Aperta
  • Qualcosa non va?
#2,949 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à
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
68/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
tooling

Direzione di ricerca

Start in src/resolution/frameworks/react.ts around lines 391-401, where the nested skipValue arrow calls a local skipString but the edge lands on the import from object-literal.ts; the same shape repeats around lines 432-441. Compare that project-import path with the package-import path fixed in #2855, then reproduce with the use.ts sample to see the lexical shadow check only inspects the call node's own scope. Done means enclosing-function bindings win for project imports too, with tests covering both nested-arrow const and function shadows.

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

Descrizione

If a function declares a local that shadows a name the file imports from a project file, a call to that name from a nested arrow links to the import instead of the local. The same code importing from a package resolves correctly in every shape, thanks to #2855.

// lib.ts
export function skipString(j: number): number { return j + 1; }

// use.ts
import { skipString } from './lib';
export function scanA(s: string) {
  const skipString = (j: number): number => j + 2;
  return skipString(0);                                          // line 4
}
export function scanB(s: string) {
  function skipString(j: number): number { return j + 3; }
  return skipString(0);                                          // line 8
}
export function scanC(s: string) { return skipString(0); }       // line 10
export function scanD(s: string) {
  const skipString = (j: number): number => j + 2;
  const skipValue = (j: number): number => skipString(j);        // line 13
  return skipValue(0);
}
export function scanE(s: string) {
  function skipString(j: number): number { return j + 3; }
  const skipValue = (j: number): number => skipString(j);        // line 18
  return skipValue(0);
}
call from './lib' (project) from 'some-pkg' (package) expected
line 4 (scanA, own local) no edge local at line 3 local
line 8 (scanB, own local function) no edge local at line 7 local
line 10 (scanC, no shadow) lib.ts skipString none (package) the import
line 13 (nested arrow, const shadow) lib.ts skipString (resolvedBy: import) ✗ local at line 12 local
line 18 (nested arrow, function shadow) lib.ts skipString (resolvedBy: import) ✗ local at line 17 local

The two marked rows are wrong edges. The two "no edge" rows for the project import are missing edges rather than wrong ones. The import resolver appears to check for a shadow only in the calling node's own scope, not in the functions around it, and only the package-import path (#2855) prefers the local.

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

In this repo. src/resolution/frameworks/react.ts has the same shape. readObjectValue declares const skipString (lines 392–396), and the nested skipValue arrow calls it at line 401. That call links to skipString in object-literal.ts, which react.ts imports. The same shape occurs again at line 441, against a second local skipString declared at line 432. I found these by checking every TS calls edge against the TypeScript checker.

Expected. Apply the same lexical shadow check to a name imported from a project file as to one imported from a package: the innermost binding in scope at the call wins, including bindings in enclosing functions.

Related: #2855, #1715.

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

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.