Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
#64,412 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
javascript, nodejs, typescript

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

🔎 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.

Lenguaje dominante
Go
Estrellas
111k
Forks
14.4k
Merge medio
2 d 5 h
PR fusionados (30 d)
116

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de microsoft/TypeScript

Todos los issues de microsoft/TypeScript

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.