RFC: Move to pnpm

[belgattitude]

Is it worthy to move to pnpm and reduce carbon emissions ?

WIP PR in https://github.com/belgattitude/nextjs-monorepo-example/pull/2765

Criteria

• Time on CI and ability to start in warm cache
• Vercel deployment time and size
• Easy to maintain versions of the pm in ci, docker... (corepack will help in the future but not yet)
• Easy ways to build a docker image
• Best integration with tools like nx, turbo

Checklist

Tested on this monorepo with nextjs 12.3.1. At first sight pnpm is faster, but going into details... not sure.

Check	Yarn 4rc	Pnpm 7	Winner
Laptop (cold cache)	71.410 ± 1.835	34.696 ± 1.413	pnpm (x2)
Laptop (warm cache)	21.576 ± 0.390	10.780 ± 0.881	pnpm (x2)
Github action (cold)	±2m	±1m20	pnpm (x1.8)
Github action (warm)	±1m20	±50s	pnpm (x1.3)
Vercel (warm)	±2m20	±3m30s	yarn
Vercel (ssr lambda size)	25MB (8.88Mb)	50MB (25Mb zip)	yarn
Vercel (api routes)	68Mb (22Mb zip)	49.4 MB (22.6Mb zip)	pnpm

• Yarn is slower in ci & local but with the automatic rotation of its cache, it's run always (mostly) warm everywhere. So the difference is not huge. The warm cache works also in vercel.
• Yarn is commited in the github repo. No need to take care of different versions on CI, Github, local machines... Install is reproducible
• Vercel deployments/previews are slower (couldn't make pnpm cache as good as yarn).
• Lambdas size differs a lot... need more investigations (vercel/nft...)

PS: locally bench were done with hyperfine, timings on github are based on few runs and include the install and the action/cache (de-)compression. As yarn already compress the archives, the post compression is very fast (zstd is disabled for files that does not compress)

Links

• Benchmarks local & CI: https://gist.github.com/belgattitude/0ecd26155b47e7be1be6163ecfbb0f0b
• Vercel time and lambda size: https://gist.github.com/belgattitude/38bc4b779d14d17793316c936879f06e
• Pnpm action used: https://gist.github.com/belgattitude/838b2eba30c324f1f0033a797bab2e31
• Yarn action used: https://gist.github.com/belgattitude/042f9caf10d029badbde6cf9d43e400a

[belgattitude]

Not sure to move to pnpm. Might be too early

• Install speed on CI: no significant difference
• Locally pnpm is still slower (especially when downloading bigger files, ie nextjs, but also when switching branches with different locks)
• Vercel lambda sizes are often bigger leading to longer cold start (lack of supportedArchitectures leads to uneeded deps with native binaries,ie musl+amd64).This can tuned in nextjs but hard to maintain
• Storage size: it's actually much more than yarn (this looks weird cause pnpm present itself as storage efficient)
• With pnpm 8.5+ deduplication starts to work (peers too)... but still dedupe checks are slow and tools like renovate will introduce duplicates over time. So it's more to maintain.
• More to maintain as pnpm change often (sometimes you'll have to deal with regressions, or breaking changes)
• Ecosystem is not yet totally ready for strict isolation - not the fault of pnpm per se
• While it's getting better, auto-install-peers is sometimes required (makes size and install time grow)

So in the end, yarn still rocks for this repo example and covers most needs... the one lacking most is pnpm deploy (but it's okay with standalone support in nextjs or turbo with docker)

Benchmarks

📥 Install speed

Measured through github actions. See latest run

• PNPM 8.5.1 - 25s => 16s + 9s (for cache fetch / decompress), see .npmrc
• Yarn 4.0.0-rc.44 / nmLinker - 28s (26s+2s with compressionLevel:0), see .yarnrc.yml
• Yarn 4.0.0-rc.44 / nmLinker - 37s (34s+3s with compressionLevel:mixed), see .yarnrc.yml

With cache

CI Scenario	Install	CI fetch cache	Total	Cache size	CI persist cache
yarn4 mixed-compression	34s	3s	37s	201Mb	(±5s)
yarn4 no compression	26s	2s	28s	155Mb	(±8s)
pnpm8.5.1	16s	9s	25s	253Mb	(±30s)

Without cache

CI Scenario	Install	Diff with cached run
yarn4 mixed-compression / no cache	±83s	slower than 37s
yarn4 no compression / no cache	±45s	slower than 28s
pnpm8 / no cache	±48s	slower than 25s