Repository navigation
pnpm 12.8: no-op lockfile updates are ~3.5× slower #16418
Description
Last pnpm version that worked
12.7.0
pnpm version
12.8.1
Code to reproduce the issue
- Clone the repository.
- With pnpm 12.8.1, run this. Nothing has changed, so it should be a no-op:
pnpm install --lockfile-only --trust-lockfile --ignore-scripts
The trigger is webpack@5.88.2, which is in patchedDependencies and is also a peer of thread-loader. webpack and webpack-cli are peers of each other.
Expected behavior
As in 12.7.0: a no-op lockfile update skips resolution and returns quickly.
Actual behavior
Every no-op run does a full resolution (resolve_workspace appears under TRACE='pacquet::install::phase=info') and writes back a byte-identical lockfile, so every later run repeats it.
In the reproduction repo provided (Local, Mac M4):
| Version | Median no-op lockfile update |
|---|---|
| 12.7.0 | ~0.6 s |
| 12.8.1 | ~1.5 s |
In our private repo (Local, Mac M4):
| Version | Median no-op lockfile update |
|---|---|
| 12.7.0 | ~8–11 s |
| 12.8.1 | ~36 s |
Additional information
Bisected to 89547446e — fix(lockfile): detect stale patch hashes in pnpm-lock.yaml (#15336). Its parent, a509dc7, is good.
The resolver collapses a peer in a peer cycle to a bare name@version, so the lockfile has thread-loader@4.0.4(webpack@5.88.2) with no (patch_hash=…). The new check in patched_dep_paths.rs (peer_to_judge) expects a patched registry peer to carry the hash, so it treats the lockfile as stale and forces a full resolution. The resolver then writes the same lockfile again.
Node.js version
24.18.0
Operating System
macOS
Contributing a fix
- I am working on a fix
Activity
zkochan commentedon Sep 30, 2026
Oz triage is running now and will classify this issue and apply one pnpm
state:label.The Oz follow-along link is not available yet.
Written by an agent (Codex, GPT-5).
zkochan commentedon Sep 30, 2026
Triage result: Ready to implement (
state: accepted).This is a bounded regression in the shared lockfile patch-hash freshness check. The reproduction and bisection identify the failing peer-cycle shape, and the relevant implementations are isolated in the Rust and TypeScript lockfile packages.
#16419 already provides matching v12 and v11 fixes and regression tests. The next step is review and merge of that PR rather than a duplicate implementation.
Written by an agent (Codex, GPT-5).
zkochan commentedon Sep 30, 2026
Correction to my triage note: pnpm v11 is affected too. #16419 reproduces the same behavior on 11.28.2 and includes matching TypeScript and Rust fixes and tests.
The readiness result remains
state: accepted; the required scope is both CLI implementations.Written by an agent (Codex, GPT-5).
fix(lockfile): don't treat a patched peer collapsed by a peer cycle a…
fix(deps): update dependencias no-major (#23)
chore(deps): update pnpm to v12.9.0
chore(deps): update pnpm to v12.9.0
chore(deps): update pnpm to v12.9.0
chore(deps): update pnpm to v12.9.0
chore(deps): update pnpm to v12.9.0