[api-extractor] Reuse TypeScript's module-resolution results to avoid realpath/lstat storm when resolving external package names
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 52/100
- Issue 类型
- 重构
- 描述清晰度
- 基本清楚
- 活跃度
- 冷清
- 技术栈
- node.js, typescript
- 领域
- performance, tooling
调研方向
Start at DeclarationReferenceGenerator._getPackageName, then inspect Collector, AstSymbolTable, and TypeScriptInternals.ts for program-resolution access. Include module and type-reference resolutions, verify packageId and resolvedFileName matching, and run the acceptance-test projects to confirm byte-identical API reports while preserving the filesystem fallback.
由索引模型根据 Issue 内容生成。
描述
Summary
During analysis, DeclarationReferenceGenerator._getPackageName(sourceFile) calls PackageJsonLookup.tryLoadNodePackageJsonFor(sourceFile.fileName) once per external source file. That path (PackageJsonLookup._tryLoadNodePackageJsonInner) calls FileSystem.getRealPath() (Node fs.realpathSync → an lstat per path segment, following symlinks) before the content cache can help, and the upward folder walk in _tryGetPackageFolderFor does it at each directory level. In pnpm workspaces (a node_modules symlink farm) this produces a large lstat storm and shows up as a significant chunk of api-extractor CPU time in profiles.
This was noticed while profiling the type-check optimization in https://github.com/microsoft/rushstack/pull/5891 — after removing the whole-program semantic check, realpathSync→lstat inside FileSystem.getRealPath → tryLoadNodePackageJsonFor was the next-largest chunk.
Insight
TypeScript already resolved every one of these modules during program construction and recorded the answer. Each ResolvedModuleFull carries:
resolvedFileName— the already-realpath'd target (TS paid thelstatcost once, cached), andpackageId.name— the bare package name, which is exactly what_getPackageNamereconstructs via the filesystem walk (packageId.subModuleNameholds the sub-path separately).
Proof of concept
Probing the @rushstack/mcp-server program via the (internal) program.forEachResolvedModule(cb):
resolutions: total=1111, withPackageId=1103, uniqueFiles=258
@modelcontextprotocol/sdk <= @modelcontextprotocol/sdk/dist/esm/server/mcp.d.ts
zod <= zod/index.d.cts
...
99.3% of resolutions carry packageId, and packageId.name came back as the bare package name even for non-index files.
Proposed design
- Build a
Map<resolvedFileName, packageId.name>once (e.g. offCollector/AstSymbolTable) via the internalprogram.forEachResolvedModule(...). Type-reference-directive resolutions (forEachResolvedTypeReferenceDirective) also carrypackageIdand should be included. - In
_getPackageName, consult the map first (keyed bysourceFile.fileName) — zero filesystem access for the common case. - Fall back to
tryLoadNodePackageJsonForon a miss (the ~0.7% withoutpackageId, or files reached via other means), preserving today's exact behavior.
forEachResolvedModule / getResolvedModule are TypeScript internals (not in the public .d.ts), but api-extractor already accesses TS internals via TypeScriptInternals.ts, so this is consistent with existing patterns.
Caveats to validate
packageId.namesemantics — the TS doc comment hints it may include a subpath in some cases; the PoC showed bare names, but this needs verification against@typespackages and deep imports vs. the existingpackageJson.namebehavior.- Key matching —
resolvedFileNamemust equal the program'ssourceFile.fileName(generally true;preserveSymlinksis the edge case). - Correctness — must produce byte-identical API reports across all acceptance-test projects. The fast-path-with-fallback design keeps this low-risk.
Related
- Follow-up to #5891 (type-check pass optimization).
- Also worth checking
SourceMapper.getRealPathusage for the same treatment.
- 主要语言
- TypeScript
- 星标
- 6.5k
- 派生
- 708
- 平均合并
- 2 天 1 小时
- 30 天内合并 PR
- 46
环境准备
我们还没有检查这个项目的环境配置文件。先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
microsoft/rushstack 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 72/100
microsoft/rushstack#5971 · 2 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 65/100
microsoft/rushstack#5902 · 1 个 reaction ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 68/100
microsoft/rushstack#5839 · 1 个 reaction ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 70/100
microsoft/rushstack#5683 · 3 条评论 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 45/100
维护者通常 1 天内回复
查看 microsoft/rushstack 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
automated issue report
难度 1/5 1 小时以内 新手友好度 68/100
-
documentation
难度 1/5 1 小时以内 新手友好度 92/100
github/copilot-sdk#2804 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 62/100
drizzle-team/drizzle-orm#6418 ·
维护者通常 4 天内回复
-
难度 1/5 1 小时以内 新手友好度 92/100
diegosouzapw/OmniRoute#15307 · 1 条评论 ·
维护者通常 2 天内回复