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

Crash in getLocalModuleSpecifier when formatting a type: normalizeSlashes receives undefined (regression in 6.0)

オープン
#64,412 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

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

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
45/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
javascript, nodejs, typescript
領域
compilers, tooling

調査の方向性

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

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

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

microsoft/TypeScript のほかの issue

microsoft/TypeScript の issue をすべて見る

似ている issue

Go の issue をもっと見る

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

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