Should we move from npm to pnpm?

[Astro-Han]

We use git worktrees heavily. On my machine right now there are 70 worktrees of this repository, roughly 23 of them created per day, holding 23.6 GB of node_modules between them. Seventeen of those worktrees hold a byte-identical dependency tree, stored seventeen times over. npm has no store shared across checkouts, so this is structural rather than a hygiene problem I can clean up.

I measured the alternative on the same machine and the same repository:

	npm	pnpm (isolated)
disk per worktree	1.21 GB	0.31 GB
steady state	23.6 GB	~9 GB
written per day	~28 GB	~7 GB
install, --ignore-scripts	4.7s	3.2s

I also ran a spike to find out whether Electron packaging survives pnpm's non-hoisted layout, because that is the usual reason desktop projects either avoid pnpm or fall back to a flattened node_modules. In a clean checkout, pnpm install → pnpm run build → electron-builder --mac --arm64 --dir passes, and the app.asar production closure matches the npm baseline package for package.

The cost was about 25 lines across three files, plus moving the three entries in patches/ to pnpm's patchedDependencies, plus one missing dependency declaration. Two of those three files are already broken on main regardless of this decision, and I have filed them separately as #4367 and #4368. They are not a pnpm tax; pnpm only made them visible.

What the spike did not cover is the part that matters most. It stops at macOS --dir. It does not touch the 13 workflows and roughly 10 release scripts that hardcode npm, and it does not touch Windows packaging, code signing, notarization, or auto-update. That is where the real work and the real risk sit, and I do not think we should decide anything on the strength of a packaging result alone. I would also target pnpm 11.24.0 rather than 12, which is still published under the next-12 tag.

So I am not proposing a migration.

1. Is the disk and worktree cost above worth acting on at all, or is it one maintainer's workflow rather than a project problem?
2. If it is worth acting on, is it worth spiking the release lane — macOS signed and notarized, plus Windows — to learn whether the migration is bounded?
3. If that spike passes, would we want the strictness that comes with it, or would we prefer a flattened layout that keeps the current tooling assumptions intact?

This discussion is only about the direction. There is no implementation PR. I have the full reproduction locally and can share the branch or the diff if that would help the conversation.

Analysis and drafting produced with Claude Code at the contributor's direction and reviewed by the contributor of record. The measurements are from a single machine and should be reproduced before anyone relies on them.

[liuxiaocs7]

Thanks for sharing the measurements and the initial spike. The results show that pnpm could provide a meaningful improvement to the development experience, especially for contributors who use multiple worktrees. I think this is a real project-level concern rather than merely one maintainer’s workflow.

However, our current priority should be completing the core functionality and establishing a stable release process. Migrating the package manager would affect CI, packaging, signing, notarization, Windows support, and auto-update workflows, introducing additional risk and maintenance work at this stage.

I suggest preserving the spike and its findings, then revisiting this after the release workflow has stabilized. At that point, it would be worth reproducing the measurements on another machine and validating the complete release lane, including macOS signing and notarization, Windows packaging, CI, and auto-update.

If those checks pass and we decide to migrate, I would prefer pnpm’s isolated layout. Its stricter dependency handling is valuable, and individual compatibility issues can be addressed explicitly rather than enabling a flattened layout by default.

In short, I support continuing this work later because it can improve the development experience, but I would not prioritize the migration before the project’s functionality and release process are more mature.