If the speed of your package manager is causing issues for developer velocity you have much bigger issues to contend with. And I categorically reject the statement that either of those are meaningully faster in any way. Maybe you can point to some specific obscure benchmarks that have slightly smaller numbers. But all of that goes out the window the second a dev is stuck with one of those "rough edges" even once. Not even to mention the lockin you've achieved on the tooling front now that your entire stack is nonstandard and reliant on a single highly specific list of dependencies to work, which may or may not even be kept in line with their node/npm counterparts.
https://medium.com/@chaudharyaniket16/from-14-minutes-to-45-...
To list some projects and companies that aren’t on NPM: Prettier, Next.js/Vercel, Cloudflare, Hono, Zod, Expo, Tamagui, Tailwind, the list goes on. I actually had trouble finding any major JS projects that are on NPM. These are serious, widely used packages, and they chose non-standard tooling for a reason.
The post describes moving from an old Yarn version that still suffered from the long, long fixed problem npm had with tree shaking. In fact, their inability to port to the newest Yarn version just highlights my point. Modern npm has solved all of these issues without the compatability problem.
>"Yarn v2 introduced several new features, including a different approach to managing the node_modules folder by eliminating it altogether through its Plug’n’Play mode."
And this is just complete insanity.
That aside, I can see that there's no real argument against pnpm at this point. It wouldn't be the end of the world. I just don't buy saving 20 seconds in CI as a legitimate reason for it.