To be fair one of the tests was a next.js app and one was a “spa”. But the data doesn’t lie. Cloudflare pages was recommended more than workers too
amplifying.ai/research/claud…
There are many changes. I think the biggest and hardest ones were:
*moving to ESM
*using node.js build SEA instead of pkg
*implementing publish
*moving away from npm's config system
*performance improvements to runtime management (node.js, bun, deno)
There's a nice tool for analyzing your node_modules:
github.com/antfu/node-module…
It works with pnpm. (but for some reason for me it only worked via "pnpx node-modules-inspector build && pnpx serve .node-modules-inspector"
pnpm v10.30 is out with improvements and fixes to "pnpm list" and "pnpm why".
pnpm v11.0.0-alpha.5 is also out. This version finally has its own publish command that doesn't run the npm CLI, but rather a library provided by the npm CLI.
If you use @pnpmjs in your project, you can have just one CI job that runs all your tests across the whole monorepo only on packages (including dependents) that changed since the last commit!
- Screen 1: Example GitHub CI setup, one CI job for the whole monorepo that detects affected packages, then dynamically creates parallel jobs to test only them.
- Screen 2: Real example from our monorepo with over 40 packages, a file changed in the `articles` package, so it automatically selected `articles` package and its dependents (`api` and `notifications`), and ran tests on all three in parallel.
The Seattle Times is piloting pnpm’s client-side defenses—blocked lifecycle scripts, release cooldowns, and trust policy—to stop worms like Shai-Hulud 2.0 before they land.
Read their story:
pnpm.io/blog/2025/12/05/news…