ESLint 9.0: Mandatory parserOptions.project for TypeScript rules

ESLint 9.0: Mandatory parserOptions.project for TypeScript rules

Starting with ESLint 9.0, any rule that relies on TypeScript type information (e.g., @typescript-eslint/no-unused-vars) now throws a configuration error unless parserOptions.project points to a valid tsconfig.json. The change is documented in the 9.0 release notes and is intended to enforce consistent type-aware linting across a codebase.

For projects that mix JavaScript and TypeScript, this requirement forces every workspace to maintain a tsconfig.json, even if only a subset of files contains TypeScript. In many monorepos, some packages contain only JavaScript and have no tsconfig.json, yet the global ESLint configuration still references parserOptions.project for the entire workspace.

ESLint documentation does not currently provide guidance on how to handle linting of TypeScript files when a tsconfig.json is absent or when only a subset of files should be type‑checked. This leaves teams uncertain whether to create a minimal in‑memory configuration, to skip TypeScript rules, or to restructure the repository.

Unresolved questions:

• Should ESLint automatically provide a minimal in‑memory tsconfig.json when parserOptions.project is omitted for TypeScript rules?
• What is the recommended approach for linting TypeScript files in a mixed-language repository that lacks a project‑wide tsconfig.json?
• How can developers avoid configuration errors while still enabling type‑aware linting for only the relevant TypeScript files?