That may lead you to the question I asked when I first heard about PNPM: Is it just another NPM alternate?
Is it really a good idea to use an NPM alternative when the default (NPM) actually works fine, but is maybe a bit slow?
Generally speaking, I'd say no, not necessarily! There's a ton of value in using the ubiquitous option — which, unlike the word ubiquitous, is the one people best understand and are most comfortable using.
But there are two scenarios in which I'd welcome a change:
When NPM's performance becomes an issue, I'd likely first switch to Yarn. Yarn has significant performance improvements over NPM, and it's a more popular and accepted option when compared to PNPM.
And if your project is a monorepo, PNPM and Yarn are both good options.
Yarn has a feature called Workspaces that is geared toward making Yarn work well for monorepos. PNPM, on the other hand, seems very much focused on monorepo support. Its approach to structuring the
node_modules directory is of great benefit when managing several projects with
package.json files in the same repository.
That said, I don't feel like I can fairly evaluate the two because I don't have enough experience with Yarn Workspaces. I came across PNPM and it was instantly beneficial to me, so I stuck with it.
To sum it all up, if you have a monorepo or performance issues with NPM, consider using an alternative option like PNPM or Yarn. Otherwise, stick with the thing everyone is comfortable using.
Want to receive approximately one email every month with new articles, tools, and references I've discovered? Sign up below.