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

TypeScript: a method call on an object imported through a re-export barrel produces no CALLS edge

Aperta
  • Qualcosa non va?
#2,718 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
72/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
bun, typescript
Ambito
backend-api-design

Direzione di ricerca

Start by reading the TypeScript import and export resolution code and the tests for named re-exports, especially the path from packages/lib/src/index.ts to repo.ts. Reproduce the issue with the seven-file workspace and compare the CALLS edges for viaPackage and viaOwnBarrel with viaDirect. Done when the re-exported findOne calls resolve and plainFn resolves through the import in both barrel cases.

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

Descrizione

bug parsing/quality

v0.12.1, macOS arm64, index_repository --mode full. Follow-up to #1974, which v0.12.0 fixed for us — thank you!

Repro

Seven files, a Bun/npm workspace with one library package that re-exports from src/index.ts.

package.json

{ "name": "barrel-repro", "private": true, "workspaces": ["apps/*", "packages/*"] }

packages/lib/package.json

{ "name": "@x/lib", "type": "module", "module": "src/index.ts" }

packages/lib/src/repo.ts

export const fooRepo = { async findOne(id: string) { return id } }
export function plainFn(id: string) { return id }

packages/lib/src/index.ts

export { fooRepo, plainFn } from './repo'

packages/lib/src/internal.ts — same package, through its own barrel

import { fooRepo, plainFn } from './index'
export async function viaOwnBarrel() { await fooRepo.findOne('c'); plainFn('c') }

apps/app/package.json

{ "name": "@x/app", "type": "module", "dependencies": { "@x/lib": "workspace:*" } }

apps/app/src/job.ts — through the package name

import { fooRepo, plainFn } from '@x/lib'
export async function viaPackage() { await fooRepo.findOne('a'); plainFn('a') }

apps/app/src/direct.ts — control: straight from the defining file

import { fooRepo, plainFn } from '../../../packages/lib/src/repo'
export async function viaDirect() { await fooRepo.findOne('b'); plainFn('b') }

Observed

IMPORTS edges are all there: job.ts → lib/src/index.ts, internal.ts → lib/src/index.ts, lib/src/index.ts → lib/src/repo.ts, direct.ts → lib/src/repo.ts.

CALLS edges:

caller → findOne → plainFn
viaDirect ✅ lsp_ts_namespace ✅ lsp_ts_import
viaPackage ❌ none (only USAGE → fooRepo) ⚠️ unique_name
viaOwnBarrel ❌ none (only USAGE → fooRepo) ⚠️ unique_name

So the package specifier is not the problem — the same loss happens with a relative ./index barrel. The chain is lost at the export { … } from './repo' hop: the method on the re-exported object gets no edge at all, and the plain function lands only via the name heuristic rather than the import (with a non-unique name that path is not guaranteed). Same result with "main" or "exports": { ".": "./src/index.ts" } instead of "module".

Expected

A named re-export is followed to the defining module the way a direct import is, so viaPackage → findOne and viaOwnBarrel → findOne resolve like viaDirect → findOne, and plainFn resolves via the import.

Impact

Our Bun monorepo has one library package that re-exports its repositories (object literals) from src/index.ts; the other apps import them by package name. After v0.12.1 intra-package calls resolve, but every cross-app call to those repositories still shows zero callers — e.g. expireLapsedSubscriptions, needsRun, takeDirty, insertIncoming, bumpInbound, each with 1–2 real call sites. As in #1974, this is indistinguishable from a true negative.

Related but different: #1557 §3 (aliased re-exports produce no node), #2297 (renamed named import).

Lingua principale
C
Stelle
45.8k
Fork
3.8k
Merge medio
3g 6h
PR unite (30g)
201

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 DeusData/codebase-memory-mcp

Tutte le issue di DeusData/codebase-memory-mcp

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.