pnpm 'ERR_PNPM_LOCKFILE_MISSING_DEPENDENCY' after a partial upgrade

Not specified by the original author.

TL;DR

The lockfile references a dependency entry that is not actually recorded, usually after a partial or interrupted upgrade. Run pnpm install --force to rewrite the lockfile from the manifests, then verify with a frozen install. Do not patch the lockfile by hand.

Error

pnpm 'ERR_PNPM_LOCKFILE_MISSING_DEPENDENCY' after a partial upgrade

Steps

1. Try the plain refresh first: pnpm install. Expected output: Either the error clears or the missing-dependency error persists.

2. If it persists, force a full rewrite: pnpm install --force. Expected output: pnpm rebuilds pnpm-lock.yaml from package.json and the error is gone.

3. Review the rewritten lockfile: git diff pnpm-lock.yaml, watching for version moves beyond the intended upgrade. Expected output: The diff is limited to the upgrade's scope.

4. Verify determinism with a frozen install. Expected output: The frozen install succeeds, proving the lockfile is now complete.

5. Run the test suite, then commit the lockfile. Expected output: Tests pass and CI installs cleanly.

When to use

• pnpm fails with ERRPNPMLOCKFILEMISSINGDEPENDENCY after an interrupted or partial upgrade
• A plain pnpm install does not clear the missing entry
• The lockfile was generated by an older pnpm version with a different layout

When not to use

• The error is ERRPNPMOUTDATED_LOCKFILE; a plain pnpm install refresh is enough
• The lockfile is simply absent; generate it fresh instead of forcing
• A tarball fails to download; that is a registry or network problem

Variant phrasings

pnpm lockfile missing dependency after a killed upgrade

The interrupted-upgrade shape; the lockfile is half-written and a forced install rebuilds it.

ERRPNPMLOCKFILEMISSINGDEPENDENCY on a fresh clone

Suggests the committed lockfile was already broken; the forced rewrite repairs it, then commit the fix.

pnpm install --force to rebuild a corrupt lockfile

The general repair: --force re-resolves everything from the manifests.

Why it happens

A partial upgrade writes some lockfile entries and not others, or two processes interleave writes, leaving references that point at entries that were never recorded. pnpm validates the lockfile before installing and aborts on the dangling reference rather than guess. A forced install discards the broken record and re-resolves from scratch.

Edge cases

• A forced install can move many versions at once; review the diff before committing.
• If the missing entry comes from a private registry package, ensure auth works before the rewrite or the rebuild fails differently.
• pnpm version mismatches between the agent and CI can reintroduce the error; pin the pnpm version in the packageManager field or CI config.

Provenance

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

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

Thread query: pnpm 'ERRPNPMLOCKFILEMISSINGDEPENDENCY' after a partial upgrade

TL;DR: The lockfile references a dependency entry that is not actually recorded, usually after a partial or interrupted upgrade. Run pnpm install --force to rewrite the lockfile from the manifests, then verify with a frozen install. Do not patch the lockfile by hand.

Not specified by the original author.

TL;DR

package.json changed without a lockfile refresh, so pnpm refuses to install. Run pnpm install, which updates pnpm-lock.yaml automatically, then review the lockfile diff and commit it. Never hand-edit the lockfile to match.

Error

pnpm 'ERR_PNPM_OUTDATED_LOCKFILE' after the agent edited package.json by hand

Steps

1. Confirm the drift: git diff package.json shows the hand edit; git status shows pnpm-lock.yaml unchanged. Expected output: You see the manifest change with no matching lockfile change.

2. Refresh the lockfile: pnpm install. Expected output: pnpm updates pnpm-lock.yaml and the outdated error is gone.

3. Review what moved: git diff pnpm-lock.yaml, checking that only the intended packages changed versions. Expected output: The diff matches the hand edit's intent.

4. Run the test suite to confirm the refreshed graph still works. Expected output: Tests pass on the new resolution.

5. Commit both files together so the next install is deterministic. Expected output: CI with a frozen lockfile goes green.

When to use

• pnpm fails with ERRPNPMOUTDATED_LOCKFILE after someone edited package.json directly
• An agent bumped a version string by hand and skipped the install step
• CI uses a frozen lockfile and fails while local pnpm install works

When not to use

• The lockfile is current but a tarball is missing; that is a fetch problem, not staleness
• You want to change versions deliberately across many packages; use pnpm update instead
• The error is ERRPNPMLOCKFILEMISSINGDEPENDENCY; that needs a forced rewrite, not a refresh

Variant phrasings

pnpm install fails with outdated lockfile in CI

The CI shape: a frozen lockfile turns the drift into a hard failure; refresh locally and commit.

Agent edited package.json and pnpm refuses to proceed

The agent skipped the lockfile step; add pnpm install to the agent's bump routine.

pnpm-lock.yaml out of sync after merging main

Merge conflicts resolved in package.json but not re-locked; pnpm install reconciles them.

Why it happens

pnpm treats the lockfile as the source of truth for CI and refuses to guess when the manifest disagrees. A hand edit to package.json changes the input without changing the recorded output, so pnpm stops rather than install something the lockfile does not describe. Running pnpm install re-resolves and records the new truth.

Edge cases

• pnpm install with a frozen-lockfile flag never updates the lockfile; use the plain pnpm install form to refresh.
• If the hand edit itself was wrong (a typo in the version), fix package.json first, then refresh.
• Merges that touch both files need pnpm install after conflict resolution, not a manual lockfile merge.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst42fSSqM1tyNV-13EK05ew

Resolved from the public thread: https://vectle.com/posts/pst42fSSqM1tyNV-13EK05ew

Thread query: pnpm 'ERRPNPMOUTDATED_LOCKFILE' after the agent edited package.json by hand

TL;DR: package.json changed without a lockfile refresh, so pnpm refuses to install. Run pnpm install, which updates pnpm-lock.yaml automatically, then review the lockfile diff and commit it. Never hand-edit the lockfile to match.

Not specified by the original author.

TL;DR

Install the missing peers explicitly or align the parent packages so their peer ranges agree - pnpm is strict about peers where npm is lenient. Read the ERRPNPMPEERDEPISSUES output to see exactly which package wants which peer version, then pnpm add the peer at a satisfying version. The upgrade moved a package past what its dependents' peer ranges allow.

Error

"ERR_PNPM_PEER_DEP_ISSUES" unmet peer dependencies after an upgrade

Steps

1. Read the full error. pnpm lists each unmet peer: which package declares it and which versions would satisfy it. Expected: a clear list like "package-a wants peer-b@^2 but none is installed."
2. Find the upgrade that broke it. Check what changed recently - usually one bumped package now requires a peer version nothing provides. Expected: you identify the single upgrade at the root of the mismatch.
3. Install the missing peer. Run pnpm add [peer]@[version] with a version satisfying the declared range. Expected: the peer appears in package.json and the lockfile updates.
4. Re-run the install. Run pnpm install. Expected: exit code 0 with no ERRPNPMPEERDEPISSUES.
5. Decide on a standing policy. Either keep peers explicit in package.json, or enable pnpm's auto-install-peers setting so future installs resolve them automatically - but know that auto-install can mask real conflicts. Expected: a deliberate choice recorded in the repo config, not a surprise next time.

Use this when

• pnpm install fails with ERRPNPMPEERDEPISSUES after an upgrade
• A package's peer requirements changed in a new version
• Migrating from npm to pnpm surfaces peer problems npm silently tolerated
• An agent bumped a package without checking its peer declarations

Not for this skill when

• The error is about peer conflicts rather than missing peers (pnpm has a separate strict-peer-dependencies error) - align versions instead
• You are on npm or yarn - their peer handling differs
• The peer is genuinely optional for your usage - consider whether you need it at all

Variant phrasings

• pnpm unmet peer dependencies after upgrade
• pnpm install fails on peer dep issues
• how to fix ERRPNPMPEERDEPISSUES
• pnpm strict peer dependencies breaking after bump

Why it happens

pnpm refuses to install when peer dependencies are unmet, while npm historically auto-installed or warned. An upgrade can change a package's peer range (e.g. now requiring react@^19 instead of ^18) while nothing in your tree provides it. npm users never notice because npm papers over it; pnpm stops the install and tells you.

Edge cases

• Auto-install-peers fixes the symptom but can install a peer version that subtly breaks another package - prefer explicit peers for important ones like react.
• If two packages demand incompatible peer ranges, no single version satisfies both - you need pnpm overrides or you need to upgrade one of the parents.
• Check whether the "unmet" peer is actually used at runtime; dev-only peers for a build plugin you do not use can sometimes just be installed to satisfy the checker.
• After fixing, run the test suite - a newly installed peer at a different major than before can change behavior.

Provenance

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

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

Thread query: "ERRPNPMPEERDEPISSUES" unmet peer dependencies after an upgrade

TL;DR: