The error, verbatim
Jump to the fix ↓npm error code ERESOLVE
npm error ERESOLVE unable to resolve dependency tree
npm error While resolving: my-app@1.0.0
npm error Found: typescript@7.0.2
npm error Could not resolve dependency:
npm error peer typescript@">=4.8.4 <6.1.0" from typescript-eslint@8.70.1
# and after forcing the install:
Error: typescript-eslint does not support TS 7.0.
See also https://github.com/typescript-eslint/typescript-eslint/issues/10940 for tracking typescript-eslint's support for TS >=7.1
Tested on
- typescript-eslint
- 8.70.1
- ESLint
- 10.11.0
- TypeScript
- 7.0.2 + @typescript/typescript6 6.0.2
- Node / npm
- 24.14.0 / 11.9.0
- OS
- Windows 11 Pro
Contents
You get one of two errors, depending on how far you got. A normal npm install refuses outright with ERESOLVE. Force it past that and ESLint starts, then stops before linting a single file.
The fix
Keep TypeScript 7 for tsc, and give typescript-eslint the TypeScript 6 API it’s built on. This is the side-by-side setup Microsoft recommends in the TypeScript 7.0 announcement:
npm install -D "@typescript/native@npm:typescript@7.0.2" "typescript@npm:@typescript/typescript6@^6.0.2"package.json ends up with:
{
"devDependencies": {
"@typescript/native": "npm:typescript@^7.0.2",
"typescript": "npm:@typescript/typescript6@^6.0.2",
"eslint": "^10.11.0",
"typescript-eslint": "^8.70.1"
}
}No change to eslint.config.mjs is needed.
When will typescript-eslint support TypeScript 7?
Not in 7.0, and not because of anything typescript-eslint could fix: TypeScript 7.0 has no JavaScript API to support. The error message itself points to issue #10940, which tracks support for TypeScript 7.1 and later. The TypeScript team says 7.1 will ship a new and different API, so typescript-eslint will need a new release built against it even then.
Until that release exists, the side-by-side setup above is the supported way to run TypeScript 7 and ESLint in the same project.
Why the aliases work
Two things are true at once in that setup, and it’s worth checking both on your machine:
npx tsc --version # Version 7.0.2 (the Go compiler)
node -p "require('typescript').version" # 6.0.3 (the API tools import)tsc comes from the package installed as @typescript/native, which is TypeScript 7. But when typescript-eslint does require('typescript'), npm’s alias hands it @typescript/typescript6, a package Microsoft publishes to carry the 6.x JavaScript API alongside 7. The peer range <6.1.0 is satisfied, so npm stops complaining too.
Why it happens
TypeScript 7 is the compiler rewritten in Go, and version 7.0 ships no JavaScript API. typescript-eslint parses your code by calling that API, so on plain TypeScript 7 it has nothing to call:
node -p "Object.keys(require('typescript'))"
# TypeScript 7.0.2 → [ 'version', 'versionMajorMinor' ]typescript-eslint knows this, which is why the error is a clear refusal rather than a crash. Its peer range, >=4.8.4 <6.1.0, exists so npm stops you before you get that far.
What didn’t work
Other tools in the same project
The same fix covers ts-node, ts-jest, TypeDoc and ts-loader, which break for the same reason. I ran nine tools against plain TypeScript 7 and against this setup in TypeScript 7 compatibility: 9 tools tested. If ts-node is what’s failing, its error is different: ts-node TypeError reading ‘fileExists’.
Run it yourself
The setup is on GitHub with scripts that break it and restore it, so you can watch each failure and fix on your own machine:
git clone https://github.com/nils44344/node-ts-error-repros
cd node-ts-error-repros/05-typescript-7-side-by-side
npm install && npm run allHow this was tested
A fresh project with ESLint 10.11.0, typescript-eslint 8.70.1 and typescript@7.0.2 on Node 24.14.0 and npm 11.9.0. Strict install first (the ERESOLVE above), then forced installs to reach the runtime error with both the recommended and recommendedTypeChecked configs, then a clean install of the side-by-side setup. Every error and every version number above is the real output from those runs.
— N.K., end of entry No.022