Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

TypeScript: an import resolves to a same-named method of an exported object literal instead of the exported function

未关闭 适合新手
  • 哪里不对？
#2,945 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

@inth3shadows 已经在做这个了。

开始于 2026年10月28日。

  • #2990 来自 @inth3shadows —— 未关闭

评估

难度
2/5
预计耗时
1-3 小时
新手友好度
75/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
node.js, typescript
领域
tooling

调研方向

从 src/resolution/import-resolver.ts 中的 getFileExportIndex 开始，大约在第 279 行，这里每个名称的第一个已导出节点胜出，而对象字面量方法 hashDriver::symbolHref 遮蔽了真正的导出。用 nav.ts/walk.ts 双文件 fixture 复现（issue 显示了确切形态），然后应用并比较建议的 tie-break，使用 CODEGRAPH_KERNEL=0 运行 __tests__/ui-package.test.ts 以及 import/export/reexport/barrel/commonjs 套件。完成意味着 walkTo 链接到 nav.ts:6，并且这些套件保持通过。

由索引模型根据 Issue 内容生成。

描述

import { f } from './m' resolves to a method named f inside an exported object literal in m.ts, instead of m.ts's exported function f, when the object comes first in the file.

// nav.ts
export interface Driver { symbolHref(id: string): string; }
export const hashDriver: Driver = {
  symbolHref(id) { return '#' + id; },          // line 3
};
let driver: Driver = hashDriver;
export function symbolHref(id: string): string { return driver.symbolHref(id); }   // line 6

// walk.ts
import { symbolHref } from './nav';
export function walkTo(id: string) { return symbolHref(id); }
expected actual
walkTo calls symbolHref at nav.ts:6 symbolHref at nav.ts:3 (hashDriver::symbolHref, resolvedBy: import)

Reproduced on main at 31ec9082 with CODEGRAPH_KERNEL=0, and on 69af19ac with the native kernel too (Linux/WSL2, Node 22.23.2). The same thing happens in this repo: ui/src/lib/walk.ts calls symbolHref/navigate, and __tests__/ui-package.test.ts calls symbolHref/fileHref/mapHref/flowHref. All of them land on hashNavigation's methods in ui/src/lib/navigation.ts (lines 123–187) rather than the exported functions at lines 240–272.

Cause. The object's method is indexed as function symbolHref, isExported = 1, qualifiedName hashDriver::symbolHref (presumably through the object-literal extraction for an exported const). getFileExportIndex keeps the first exported node per name (import-resolver.ts#L279), so the method shadows the real export.

Possible fix. When two exported nodes share a name, let a top-level declaration replace a member:

const prev = idx.byName.get(n.name);
if (!prev || (prev.qualifiedName !== prev.name && n.qualifiedName === n.name)) idx.byName.set(n.name, n);

With that change walkTo links to nav.ts:6, and the 62 __tests__ files matching import/export/reexport/barrel/store/commonjs/require/default pass (490 tests, CODEGRAPH_KERNEL=0). I haven't run the full suite, and a stricter version might keep members out of byName entirely.

Not fixed by #2754 or #2800: I ran this fixture on both heads and the edge still lands on line 3. I also searched open issues and PRs for object-literal methods and import namesakes, and found nothing else that covers it.

主要语言
C
星标
73.2k
派生
4.7k
平均合并
3 小时 13 分钟
30 天内合并 PR
579

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

colbymchenry/codegraph 的其他 Issue

查看 colbymchenry/codegraph 的全部 Issue

相似的 Issue

更多 C Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。