-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
pnpm 12.8: no-op lockfile updates are ~3.5× slower #16418
Copy link
Copy link
Closed
Labels
area: lockfilearea: patchingarea: peersarea: resolutionregressionstate: acceptedThe required changes are defined. There is consensus on the change. Development can be startedThe required changes are defined. There is consensus on the change. Development can be started
Description
Activity
Metadata
Metadata
Assignees
Labels
area: lockfilearea: patchingarea: peersarea: resolutionregressionstate: acceptedThe required changes are defined. There is consensus on the change. Development can be startedThe required changes are defined. There is consensus on the change. Development can be started
Last pnpm version that worked
12.7.0
pnpm version
12.8.1
Code to reproduce the issue
Reproduction repository
The trigger is
webpack@5.88.2, which is inpatchedDependenciesand is also a peer ofthread-loader.webpackandwebpack-cliare 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_workspaceappears underTRACE='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):
In our private repo (Local, Mac M4):
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 hasthread-loader@4.0.4(webpack@5.88.2)with no(patch_hash=…). The new check inpatched_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