## 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

```text
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

```bash
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

```bash
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:

```bash
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

```bash
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