Paste your npm error. Get the actual fix.
Stop manually tracing an ERESOLVE unable to resolve dependency tree error through a wall of red text. Paste the full error and get the two conflicting packages, the versions they each want, and a copy-paste fix.
How ERESOLVE Explainer works
- 1
Paste the full npm ERESOLVE error
Copy everything npm printed, starting from ERESOLVE unable to resolve dependency tree through the final Fix the upstream dependency conflict line. The more complete the paste, the more the parser can extract.
- 2
The error is parsed entirely in your browser
Nothing is sent to a server. The parser strips the npm error / npm ERR! line prefixes, then looks for the While resolving, Found, and Could not resolve dependency sections that npm always prints in this order.
- 3
The two conflicting packages are identified
The parser extracts the package already resolved in your tree (and where it came from) and the peer dependency requirement that conflicts with it (and which package declared that requirement).
- 4
A plain-English summary is generated
Instead of raw npm output, you get a sentence explaining which package wants which version, and whether it's a direct dependency in your package.json or pulled in transitively by something else.
- 5
Copy-paste overrides and resolutions blocks appear
Both an npm overrides block and a Yarn resolutions block are generated from the actual package names and versions in your error, ready to drop into package.json.
- 6
Fix the conflict without --force or --legacy-peer-deps
Apply the generated block, delete node_modules and your lockfile if needed, and reinstall. The conflict is resolved instead of silently suppressed.
What each part of the result means
Every ERESOLVE conflict comes down to two packages disagreeing about a third package's version.
The package and version npm already resolved in your tree, taken from the error's Found: line. This is usually either what your own package.json declares directly, or what another dependency pulled in first.
Found: typescript@7.0.0-rc
node_modules/typescript
typescript@"^7.0.0-rc" from the root projectThe conflicting peer dependency requirement, taken from the error's peer ... from line. This is the range some other package insists on, that the already-installed version doesn't satisfy.
peer typescript@"<6.1.0" from typescript-eslint@8.15.0An npm overrides entry that pins the conflicting parent's dependency to match whatever version is already resolved at the root, using the $packageName syntax so it stays in sync if you upgrade later.
{
"overrides": {
"typescript-eslint": {
"typescript": "$typescript"
}
}
}Shown when the pasted text is missing the Found: block or the peer ... from line, usually because only part of the error was copied. Paste starting from ERESOLVE unable to resolve dependency tree for the best result.
# Make sure your paste includes both:
Found: <package>@<version>
peer <package>@"<range>" from <parent>@<version>npm ERESOLVE error format reference
Every npm 7+ ERESOLVE error follows the same structure, just with different package names.
npm error code ERESOLVE
npm error ERESOLVE unable to resolve dependency tree
npm error
npm error While resolving: my-app@1.0.0 // your project
npm error Found: typescript@7.0.0-rc // what's already resolved
npm error node_modules/typescript
npm error typescript@"^7.0.0-rc" from the root project // declared directly
npm error
npm error Could not resolve dependency:
npm error peer typescript@"<6.1.0" from typescript-eslint@8.15.0 // the conflict
npm error node_modules/typescript-eslint
npm error typescript-eslint@"^8.15.0" from the root project // also direct
npm error
npm error Fix the upstream dependency conflict, or retry
npm error this command with --force or --legacy-peer-deps
npm error to accept an incorrect (and potentially broken) dependency resolution.Older npm versions (3 through 6) print a shorter npm WARN message instead of failing outright, since peer dependency conflicts were warnings, not hard errors, before npm 7.
When to use ERESOLVE Explainer
| Scenario |
|---|
| npm install fails right after adding a package |
| Upgrading a major framework version (React, TypeScript, Next.js) |
| CI fails on npm ci but works locally |
| Reviewing a teammate's failing build without their terminal |
| Deciding whether --legacy-peer-deps is actually safe here |
| Auditing a TypeScript 7 upgrade for eslint/jest breakage |
Frequently Asked Questions
What does npm ERESOLVE mean?
ERESOLVE means npm could not find a single set of package versions that satisfies every dependency and peer dependency in your project. Two (or more) packages in your tree require incompatible versions of the same package, and npm refuses to guess which one you want.
- Most common cause: a peer dependency range that hasn't been updated yet for a new major version of a package you just installed or upgraded.
- When it appears: running
npm installornpm ciafter adding a package, upgrading a framework version, or restoring a lockfile in CI. - Why npm 7+ is stricter: npm 3 through 6 silently ignored peer dependency conflicts. npm 7 made them a hard error by default, which is more correct but surfaces conflicts that used to be invisible.
How is this different from reading an ERESOLVE explainer article?
| Static explainer articles | ERESOLVE Explainer | |
|---|---|---|
| Input | None: you match your error to their examples | Your actual pasted error |
| Output | General advice | The two exact packages and versions in conflict |
| Fix generated | No: you write the override yourself | Yes: copy-paste overrides or resolutions block |
| Direct vs transitive | You trace node_modules paths manually | Identified automatically from the error text |
Articles are useful for understanding peer dependencies conceptually. This tool is for the moment you're staring at your own terminal and need the specific fix for your specific error.
Does this tool send my error or package names to a server?
No. Parsing happens entirely in JavaScript inside your browser. Nothing in the pasted error, including package names, versions, or your project name, is sent anywhere. The tool works even if you're offline after the page loads.
How do I fix the ERESOLVE error from typescript-eslint after upgrading to TypeScript 7?
This is one of the most common ERESOLVE errors right now. typescript-eslint's peer range only allows typescript below 6.1.0, so installing typescript@7 alongside it fails before you even run a lint. Keep typescript pinned to the 6.x line for your tooling instead of upgrading it directly:
{
"overrides": {
"typescript-eslint": {
"typescript": "^6.9.0"
}
}
}See our full writeup on why TypeScript 7 breaks ESLint, ts-jest, and ts-morph for the complete side-by-side setup that lets you keep the faster tsgo compiler without breaking your existing tools.
Is --legacy-peer-deps or --force safe to use instead of fixing the conflict?
Both flags make the ERESOLVE error go away without actually resolving the conflict, which is exactly the problem.
- `--legacy-peer-deps` skips peer dependency checking entirely, reverting to how npm 3 through 6 behaved. The conflicting versions still both get installed; npm just stops warning you.
- `--force` installs the exact tree npm originally wanted, even though it knows a peer dependency requirement is unmet.
What is the difference between npm overrides and Yarn resolutions?
Both let you force a specific version of a nested dependency regardless of what its parent package originally requested. The syntax and matching rules differ.
| Feature | npm overrides | Yarn resolutions |
|---|---|---|
| Available since | npm 8.3 | Yarn 1 (Classic) and Berry |
| Syntax | Nested object per parent package | Flat glob-style path keys |
| Reference root version | `"$packageName"` syntax | Not supported the same way |
| Scope | Whole tree or a specific parent | Whole tree (`**/pkg`) or a specific path |
Our SemverExplainer tool is useful right after this one: once you've generated an override or resolution, it can confirm exactly what version range the new constraint allows.