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

[AlexisDevMaster]

🔎 Search Terms

normalizeSlashes, getLocalModuleSpecifier, computeModuleSpecifiers, getSpecifierForModuleSymbol, symbolToNode, "Cannot read properties of undefined (reading 'includes')"

🕗 Version & Regression Information

Crashes on typescript@6.0.3. The identical project on typescript@5.9.3 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
typescript@6.0.3	crash
typescript@5.9.3, 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.

[yksr-melt]

I looked into this and I think I found the cause.

In getLocalModuleSpecifier (src/compiler/moduleSpecifiers.ts), when package.json "imports"
resolution is enabled (e.g. module: nodenext) but neither paths nor baseUrl is set, the base
directory passed to getNormalizedAbsolutePath is undefined:

getNormalizedAbsolutePath(getPathsBasePath(compilerOptions, host) || baseUrl!, host.getCurrentDirectory())

This normally works because the current directory is combined in, but if the host reports an empty
current directory, normalizeSlashes receives undefined and throws. Since #62726 the node builder
always has a module specifier host, so typeToString can now reach this path, which would explain
why this is a regression in 6.0.

I can reproduce the same TypeError in a unit test with a compiler host whose getCurrentDirectory()
returns "". The fix is a one-line fallback to the current directory:
yksr-melt@18d4e7f

I haven't confirmed that the ESLint setup in this report actually ends up with an empty current
directory, so this may be only part of the story.

Would you accept a PR for this against release-6.0? (The patch was written with the help of Claude Code.)