• I have tried restarting my IDE and the issue persists.
• I have updated to the latest version of the packages.
• I have read the FAQ and my problem is not listed.

Repro

1. My scenario involves an ESLint plugin project in a monorepo with side-by-side versions of TypeScript
2. Upgrade that project to use the latest @typescript-eslint/parser, with an indirect dependency on @typescript-eslint/types
3. A file imported from @typescript-eslint/types fails to compile if your project is not using the very latest release of TypeScript. The error looks like:

   @typescript-eslint/types/dist/ast-spec.d.ts:781:5 - (TS1169) A computed property 
   name in an interface must refer to an expression whose type is a literal type 
   or a 'unique symbol' type.
   

Expected: We can solve this problem by upgrading the TypeScript dependency for our ESLint plugin project, while other monorepo projects continue to use the older TypeScript compiler that they target.

Actual: Upgrading TypeScript for the the plugin package does NOT upgrade the TypeScript import for @typescript-eslint/types. As an indirect dependency, instead it accidentally picks up the older TypeScript version that was installed for a different project. This is because the package manager is not required to make any guarantees about the version (or even existence) of typescript for @typescript-eslint/types, because it was not declared in package.json.

Specifically, the typescript package is referenced here:

dist/ast-spec.d.ts

import type { SyntaxKind } from 'typescript';

...but is only declared as a dev dependency here:

@typescript-eslint/types/package.json

  "devDependencies": {
    "typescript": "*"
  }

This makes typescript into a phantom dependency, which is an incorrect practice when using a package manager with a modern node_modules layout.

Suggested fix

1. Add typescript to the peerDependencies section for @typescript-eslint/types (maybe as an optional peer dependency if we are lazy), OR
2. Rework ast-spec.d.ts so that it does not rely on imports from typescript

It's possible to work around this problem using hacks, but those hacks would need to be applied to each project in this situation that somehow indirectly depends on @typescript-eslint/types.

Versions