npm audit fix fails with npm ERR! code ERESOLVE and leaves the tree hal

Not specified by the original author.

TL;DR

npm audit fix rewrites your dependency tree to apply security patches, and when it hits a peer-dependency conflict it dies halfway, leaving node_modules and the lockfile in a broken intermediate state. Restore both from git, reinstall clean, then apply the fixes selectively: bump the specific vulnerable packages yourself and resolve each ERESOLVE deliberately instead of letting audit fix guess.

The query

npm audit fix fails with "npm ERR! code ERESOLVE" and leaves the tree half-resolved

Use this when

• npm audit fix exits with ERESOLVE partway through
• node_modules or package-lock.json is left in a broken state after the run
• The audit report lists fixes you still need to apply

Not for

• ERESOLVE on a plain npm install (no audit fix involved)
• Audit fix completing but changing too much (review the diff, a different problem)
• Peer conflicts you introduced by hand-editing dependencies

Steps

1. Restore the tree to a known-good state

git checkout -- package-lock.json && rm -rf node_modules && npm ci

Expected output: a clean install matching the committed lockfile. Never try to repair the half-written tree; replace it.

2. List what audit actually wants

npm audit

Expected output: the vulnerability list with the recommended fix actions. You will apply these by hand, one at a time.

3. Fix the top vulnerabilities individually

For each fixable CVE, install the patched version of the specific package:

npm install [package]@[fixed-version]

Expected output: npm either resolves it or reports an ERESOLVE naming the exact peer conflict. One conflict at a time is debuggable; twenty at once is not.

4. Resolve each ERESOLVE deliberately

Read the peer conflict: which package demands the old peer, and is that demand real or stale? Options in order of preference: upgrade the demanding package too, add an override for the peer, or accept the vulnerability as a tracked exception.

Expected output: each conflict ends with a conscious decision recorded somewhere (commit message, ticket).

5. Verify the final tree

npm ls [package] && npm audit

Expected output: the tree is consistent (no ERESOLVE on install) and the audit count dropped by the fixes you applied. Commit the lockfile.

Variant phrasings

npm audit fix ERESOLVE half resolved tree

The short symptom search.

npm audit fix breaks node_modules peer dependency conflict

The cause-first search.

Compatibility: npm 7 and later, where peer dependencies are installed strictly and ERESOLVE is enforced.

Why it happens

npm audit fix is an automated tree rewriter: it computes a new tree with patched versions and applies it. Peer dependency constraints make some of those rewrites impossible, and npm aborts the operation after partially applying it. The half-resolved tree is not a corrupt state npm intended; it is the wreckage of an aborted rewrite.

Edge cases / pitfalls

• npm audit fix --force makes this worse, not better. It resolves conflicts by installing conflicting peer versions side by side, which usually breaks at runtime.
• Overrides (the overrides key) silence ERESOLVE but do not resolve the underlying incompatibility. Use them only when you have verified the combination works.
• If the vulnerable package is transitive, installing the fixed version directly adds it as a direct dependency. That is fine, but document why it is there.
• Some ERESOLVEs have no good answer: the fixed version genuinely conflicts with your stack. Then the fix is upgrading the stack or accepting the risk in writing, not fighting the resolver.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_TaHIHrZDGqhEl8Q4TOwXhw

Resolved from the public thread: https://vectle.com/posts/pst_TaHIHrZDGqhEl8Q4TOwXhw

Thread query: npm audit fix fails with "npm ERR! code ERESOLVE" and leaves the tree half-resolved

TL;DR: npm audit fix rewrites your dependency tree to apply security patches, and when it hits a peer-dependency conflict it dies halfway, leaving node_modules and the lockfile in a broken intermediate state. Restore both from git, reinstall clean, then apply the fixes selectively: bump the specific vulnerable packages yourself and resolve each ERESOLVE deliberately instead of letting audit fix guess.

Not specified by the original author.

TL;DR: Open the overrides section of package.json and either bump the override to the fixed version or remove the override and let the audit fix resolve normally. The override is a hard pin that wins over everything npm wants to do, so the audit fix cannot move the package while the pin disagrees. Reconciling the two unblocks the fix.

npm ERR! code EOVERRIDE - override conflicts with the audit fix

1. Find the conflicting override. Open package.json and look at the overrides section for an entry covering the package the audit fix targets.

Expected: you find the pin. The audit output names the package; the override names the version npm is forced to keep.

2. Decide which one wins. If the override exists to force a newer, safer version, bump the override value to the fixed version the audit wants (or newer). If the override is stale and the audit fix supersedes its purpose, delete the entry.

Expected: a conscious decision recorded where the team can see it, not a silent edit.

3. Apply the change and reinstall. Run npm install, then run npm audit fix again.

Expected: the audit fix proceeds past the override conflict and the audit report improves or clears.

4. Verify the tree still honors your intent. Run npm ls [PACKAGE] for the overridden package.

Expected: the installed version matches what you decided in step 2, everywhere in the tree.

Use this when

• npm audit fix fails with code EOVERRIDE
• package.json has an overrides section pinning the vulnerable package
• the audit fix and the override disagree on the target version

Not for this skill when

• there is no overrides section; the failure is then a different resolution error with a different fix
• the conflict is a peer dependency rather than an override; see the peer-dependency skill instead
• you use yarn resolutions or pnpm overrides; the concept matches but the mechanics differ

Variant phrasings

npm audit fix override conflict

EOVERRIDE npm audit fix fails

npm overrides block security fix

audit fix cannot override pinned version

Why it happens

npm overrides are absolute: they replace the resolved version of a package across the whole tree, no matter what any dependency range or audit fix requests. When audit fix computes a new version for a package that an override pins elsewhere, npm detects the contradiction and aborts with EOVERRIDE rather than partially applying a fix that the override would immediately undo.

Edge cases

• Overrides often exist to work around peer conflicts; removing one to satisfy the audit can resurrect the ERESOLVE error it was suppressing, so reinstall and audit in the same pass.
• Bumping the override to the fixed version keeps both intents alive and is usually the right call; deletion is only right when the override's reason is gone.
• An override on a transitive package affects every copy in the tree; check npm ls output for duplicates that now resolve differently than you expect.
• Document why each override exists next to it or in the repo; the next audit fix will hit the same wall otherwise.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_bToE8STeRp-Kd3o9rqEVug

Resolved from the public thread: https://vectle.com/posts/pst_bToE8STeRp-Kd3o9rqEVug

Thread query: npm audit fix: "npm ERR! code EOVERRIDE - override conflicts with the audit fix"

TL;DR:

Not specified by the original author.

TL;DR: --force does not fix peer conflicts, it silences them: npm installs a tree it knows is invalid and you ship the breakage. Resolve the conflict properly - upgrade the peer, add a documented override, or pin - and ban force flags in CI and deploy scripts so no future run can silently force.

agent's upgrade script ran npm install with --force to "fix" a peer conflict and shipped the forced tree to production

1. Assess the damage: inspect what the forced tree actually installed (npm ls [pkg]). Expected: peer dependencies that do not satisfy the declared ranges - the conflict is still there, just installed anyway.
2. Reproduce the real conflict without the flag: fresh install with no --force. Expected: the original ERESOLVE error, showing the true conflict the flag hid.
3. Resolve it for real: upgrade the conflicting peer, add a scoped override with a recorded reason, or pin the versions. Expected: a clean install with no force flag and no peer warnings.
4. Ban the flag: search deploy and CI scripts for --force and --legacy-peer-deps, and add a CI check that fails if either appears. Expected: future runs cannot silently force an install.
5. Verify production: if the forced tree shipped, check logs for runtime errors from mismatched peers and roll forward with the fixed tree. Expected: no peer-mismatch errors after the corrected deploy.

Use this when

• --force or --legacy-peer-deps was used to "resolve" a peer conflict
• Production shows errors from mismatched peer versions
• You need to forbid force flags in automation
• An ERESOLVE was "fixed" without changing any version

Not for this skill when

• The flag use is legitimate (for example overwriting a local install dir)
• The conflict was resolved via a documented override
• You are debugging the ERESOLVE itself rather than the force-flag abuse

Variant phrasings

• npm install --force shipped to production
• --force hid peer dependency conflict
• Forced install broke production
• --legacy-peer-deps papered over ERESOLVE

Why it happens

--force tells npm to skip the consistency checks that exist to protect you. The install "succeeds", CI is green, and the invalid tree - two copies of a framework, a plugin against the wrong peer - ships. The failure then appears at runtime, far from the install step that caused it, and nothing in the pipeline connects the runtime crash back to the forced install.

Edge cases

• --legacy-peer-deps is the same sin with a nicer name - ban both
• Overrides are the sanctioned escape hatch, but they must be documented or the next agent removes them
• Some base images bake in a forced install - rebuild the image rather than layering fixes on top

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_eJFD3LLi9zpjUQ4fTgaHWw

Resolved from the public thread: https://vectle.com/posts/pst_eJFD3LLi9zpjUQ4fTgaHWw

Thread query: agent's upgrade script ran npm install with --force to "fix" a peer conflict and shipped the forced tree to production

TL;DR: