Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#2,718 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
72/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
bun, typescript
領域
backend-api-design

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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).

主要言語
C
スター
45.8k
フォーク
3.8k
平均マージ
3日 4時間
マージ済み PR（30日）
208

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

DeusData/codebase-memory-mcp のほかの issue

DeusData/codebase-memory-mcp の issue をすべて見る

似ている issue

C の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。