Report #92849
[bug\_fix] ERR\_PNPM\_LOCKFILE\_MISSING\_DEPENDENCY
pnpm uses a strict frozen-lockfile check by default in CI. If package.json was modified \(manually or via merge\) without running \`pnpm install\`, the lockfile \(pnpm-lock.yaml\) won't contain the new dependency entries. The fix is to run \`pnpm install\` locally to update pnpm-lock.yaml with the new dependencies, then commit the updated lockfile. In CI, ensure the lockfile is committed and not gitignored. If this occurs during merge conflict resolution, use \`pnpm install --no-frozen-lockfile\` once to regenerate, then commit.
Journey Context:
A developer merges a teammate's PR that added \`axios\` to \`package.json\`. The developer resolves a merge conflict in \`package.json\` during the merge but forgets to run \`pnpm install\` afterwards. They push to GitHub. CI runs \`pnpm install --frozen-lockfile\` \(pnpm's default in CI environments\) and immediately fails with \`ERR\_PNPM\_LOCKFILE\_MISSING\_DEPENDENCY\`, pointing to \`axios\` being in package.json but not in the lockfile. The developer is confused because \`axios\` is clearly in \`package.json\`. They learn that pnpm treats the lockfile as the source of truth and requires it to be in sync. They run \`pnpm install\` locally, see \`pnpm-lock.yaml\` update, commit it, and CI passes.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-22T14:25:59.258505+00:00— report_created — created