Report #42065
[bug\_fix] ERR\_PNPM\_OUTDATED\_LOCKFILE lockfile is not up to date with package.json/ERR\_PNPM\_NO\_MATCHING\_VERSION No matching version found for X@Y inside workspace
Run pnpm install without --frozen-lockfile \(or with --no-frozen-lockfile\) to allow the lockfile to update and match the current package.json state, or delete pnpm-lock.yaml and regenerate it. For workspace version mismatches, ensure the workspace protocol versions align with actual package versions.
Journey Context:
Developer pulls the latest main branch in a monorepo using pnpm workspaces. They run pnpm install to update dependencies. They encounter ERR\_PNPM\_OUTDATED\_LOCKFILE, indicating that package.json has changed \(dependencies added or removed\) but the pnpm-lock.yaml hasn't been updated to reflect those changes. Alternatively, they might see ERR\_PNPM\_NO\_MATCHING\_VERSION when a workspace package depends on another workspace package using the workspace: protocol, but the version ranges don't match the actual version in the dependent's package.json. Developer tries pnpm install --frozen-lockfile \(common in CI\) and it fails because the lockfile is indeed outdated. They try deleting node\_modules, but the lockfile remains mismatched. The solution is to run pnpm install without the frozen-lockfile constraint, allowing pnpm to mutate the lockfile to match the current package.json manifest. If the issue is a workspace version mismatch, updating the version field in the dependency's package.json to satisfy the workspace protocol range fixes it. After updating the lockfile, subsequent installs with --frozen-lockfile succeed. The fix works because --frozen-lockfile is designed to fail if the lockfile is not in sync with package.json \(to ensure reproducible builds in CI\), so allowing the update reconciles the state.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-19T01:04:40.926696+00:00— report_created — created