Repository navigation
[windows] pnpm 12 is slow #16468
Description
Verify latest release
- I verified that the issue exists in the latest pnpm release
pnpm version
v12.8.1
Which area(s) of pnpm are affected? (leave empty if unsure)
No response
Link to the code that reproduces this issue or a replay of the bug
No response
Reproduction steps
Use windows 10 and install latest pnpm v12 and run any pnpm command
Describe the Bug
Latest version of v12.8.1 takes ~1500% as much time compared to the latest version of v11.28.3
pnpm self-update 11
Checking for updates...
Switching pnpm from v12.8.1 to v11.28.2...
The current project has been updated to use pnpm v11.28.2
Successfully updated pnpm to v11.28.2
pnpm i
Scope: all 36 workspace projects
Already up to date
Done in 6.1s using pnpm v11.28.3
pnpm self-update
Checking for updates...
Switching pnpm from v11.28.2 to v12.8.1...
Successfully updated pnpm to v12.8.1
pnpm i
Scope: all 36 workspace projects
Already up to date
Done in 1m 32.4s using pnpm v12.8.1
Expected Behavior
Not to be slow
Which Node.js version are you using?
24.15.0
Which operating systems have you used?
- macOS
- Windows
- Linux
If your OS is a Linux based, which one it is? (Include the version if relevant)
No response
Contributing a fix
- I am working on a fix
Activity
zkochan commentedon Oct 1, 2026
Thanks for the report. We found a likely cause, and a fix is in progress.
What happens
When an optional dependency's build fails, pnpm deletes that package's directory so nothing loads a half-built copy. On Windows this is common for packages that need
node-gypand a C++ toolchain. pnpm deletes only the directory. The project'snode_modules/<name>link stays and now points at nothing.Since 12.7.0 (and 11.28.0), the "Already up to date" check treats a direct-dependency link that points at nothing as a broken install. That check was added in #15569. So every
pnpm installskips the fast path and runs a full install. The full install imports the package again, reruns its failing build, and deletes it again. On Windowsnode-gypcan spend a long time looking for Visual Studio and Node headers before it fails, and that time is added to every install.We reproduced this on Windows with the optional
fuse-nativedependency in the pnpm repository. Every repeatpnpm installreran itsnode-gyp rebuildand never reported "Already up to date".Can you confirm it is the same for you?
Please run this in your workspace (PowerShell):
If you see
repeat-install fast path skipped ... reason: "a direct dependency link points to a missing target", this is the same problem. If the reason is different, please paste it here. Then we can tell whether something else is slow.The fix will stop a known-failed optional build from forcing a full install on every run. We'll link the PR here.
Written by an agent (Claude Code, Opus 5.5).
fix(install): keep the repeat-install fast path when an optional buil…
zkochan commentedon Oct 1, 2026
The fix is in #16478. It stops a failed optional build from forcing a full install, and a rerun of that build, on every
pnpm install. If theTRACEoutput above shows a different reason for you, please post it here.Written by an agent (Claude Code, Opus 5.5).
fix(install): keep the repeat-install fast path when an optional buil…
fix(install): remove the links of an optional dependency whose build …
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
perf(workspace): replace 3x wax manifest walks with single-pass direc…