Crash in getLocalModuleSpecifier when formatting a type: normalizeSlashes receives undefined (regression in 6.0)
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 45/100
- issue の種類
- バグ
- 明瞭さ
- 明確に書かれている
- 活発さ
- 活発
- 技術スタック
- javascript, nodejs, typescript
調査の方向性
The crash occurs in getLocalModuleSpecifier when normalizeSlashes receives undefined. Start by examining the TypeScript source at src/compiler/moduleSpecifiers.ts and src/compiler/utilities.ts around the normalizeSlashes call. Reproduce the issue with the provided ESLint setup to see the stack trace. Look for where the importing file's path becomes undefined during the second parse after a fix is applied. Check how SourceFile paths are handled in the language service or program reuse scenarios.
索引モデルが issue の本文から書いたものです。
説明
🔎 Search Terms
normalizeSlashes, getLocalModuleSpecifier, computeModuleSpecifiers, getSpecifierForModuleSymbol, symbolToNode, "Cannot read properties of undefined (reading 'includes')"
🕗 Version & Regression Information
Crashes on [email protected]. The identical project on [email protected] does not crash — nothing else changed, only the typescript dependency. So this is a regression between 5.9 and 6.0.
⏯ Playground Link
Not reproducible in the playground: it needs a Program created from a tsconfig with a package in node_modules, and a second parse of modified file text.
💻 Code
Four files. npm install, then two commands.
package.json
{
"name": "ts6-fix-crash-repro",
"private": true,
"type": "module",
"devDependencies": {
"eslint": "10.10.0",
"typescript": "6.0.3",
"typescript-eslint": "8.70.1",
"vitest": "5.0.0"
}
}
tsconfig.json
{
"compilerOptions": {
"target": "ES2022",
"module": "NodeNext",
"moduleResolution": "NodeNext",
"strict": true,
"noEmit": true
},
"include": ["src"]
}
eslint.config.mjs
import tseslint from 'typescript-eslint';
export default tseslint.config({
files: ['src/**/*.ts'],
extends: [...tseslint.configs.recommendedTypeChecked],
languageOptions: {
parserOptions: { project: './tsconfig.json', tsconfigRootDir: import.meta.dirname },
},
});
src/index.ts
/* eslint-disable @typescript-eslint/no-explicit-any */
import { vi } from 'vitest';
export const f = vi.fn();
Run:
npx eslint src # exit 0 — one warning, the unused disable directive
npx eslint src --fix-dry-run # exit 2 — crash
The eslint-disable comment on line 1 is deliberately unused. It is the only fixable thing in the project, so it is what makes the second command apply a fix and re-parse the file. Delete that line and --fix-dry-run exits cleanly.
🙁 Actual behavior
TypeError: Cannot read properties of undefined (reading 'includes')
Occurred while linting .../src/index.ts:4
Rule: "@typescript-eslint/no-unsafe-assignment"
at normalizeSlashes (typescript/lib/typescript.js:8853:15)
at getNormalizedAbsolutePath (typescript/lib/typescript.js:8899:12)
at getLocalModuleSpecifier (typescript/lib/typescript.js:50210:25)
at computeModuleSpecifiers (typescript/lib/typescript.js:50155:19)
at getModuleSpecifiersWithCacheInfo (typescript/lib/typescript.js:50089:18)
at getModuleSpecifiers (typescript/lib/typescript.js:50056:10)
at getSpecifierForModuleSymbol (typescript/lib/typescript.js:57728:27)
at createExpressionFromSymbolChain (typescript/lib/typescript.js:57987:29)
at symbolToExpression (typescript/lib/typescript.js:57974:14)
at symbolToNode (typescript/lib/typescript.js:55769:14)
normalizeSlashes is called with undefined. The named rule is incidental — it is whichever type-aware rule reaches the file first. Disabling no-unsafe-assignment moves the crash to no-misused-promises, and disabling that moves it to no-unnecessary-type-assertion.
🙂 Expected behavior
getLocalModuleSpecifier should not dereference an absent path on the importing file, or the caller should not reach it with one. Formatting a type should not throw.
Additional information
Conditions, each verified by changing one thing and re-running:
| change | result |
|---|---|
[email protected] |
crash |
[email protected], everything else identical |
no crash |
parserOptions.project |
crash |
parserOptions.projectService: true instead |
no crash |
TSESTREE_SINGLE_RUN=false in the environment |
no crash |
remove the unused eslint-disable line (so no fix is applied) |
no crash |
recommendedTypeChecked or strictTypeChecked |
crash either way |
npm or pnpm for the install |
crash either way |
A fix being applied is necessary: without one there is no second parse and no crash.
I could not reduce this below the ESLint harness. Calling checker.typeToString(type, enclosingDeclaration, TypeFormatFlags.UseFullyQualifiedType) directly does not reproduce it, including when enclosingDeclaration is a SourceFile from a different Program, or one built with ts.createSourceFile whose path I removed — those all format fine. So the pathless importing file appears to arise from something more specific than a detached SourceFile, and I have not identified what.
Related: typescript-eslint#12749 reported the same stack from a different trigger (CI=true, so the same single-run Program inference that TSESTREE_SINGLE_RUN=false disables above). It was closed as external on the grounds that the stack is inside TypeScript, with a request to file here and to include a reproduction. This is that reproduction.
Environment: macOS 27.0 arm64, Node v26.8.1.
- 主要言語
- Go
- スター
- 111k
- フォーク
- 14.4k
- 平均マージ
- 2日 5時間
- マージ済み PR(30日)
- 116
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
microsoft/TypeScript のほかの issue
-
Possible Improvement
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
microsoft/TypeScript#64278 · コメント 1 件 · リアクション 1 件 ·
-
Docs
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
microsoft/TypeScript#64118 · コメント 1 件 ·
-
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
microsoft/TypeScript#64094 ·
-
Docs
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
microsoft/TypeScript#63959 · コメント 5 件 ·
-
Domain: lib.d.ts Help Wanted
難易度 1/5 1時間未満 初心者へのやさしさ 91/100
microsoft/TypeScript#63722 · コメント 4 件 · リアクション 1 件 ·
microsoft/TypeScript の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
bazel-contrib/rules_go#4726 · コメント 1 件 ·
-
area/auto-scaling area/monitoring area/ops-productivity kind/enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
-
Type/Improvement
難易度 1/5 1〜3時間 初心者へのやさしさ 90/100
OpenNSW/nsw-srilanka#522 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 92/100