Next.js, Prisma & TRPC: Is it Worth Migrating to Pnpm?
It’s common sense to use
yarn since they are not just stable, but also widely popular (not without downsides of course). But there are always other options.
There is a small project written in Next.js with Prisma, TRPC with addition of some other APIs (everything is following t3 stack).
The package manager chosen initially was
npm. Maybe partially due to a shorter cli command than
yarn (subjective due to human laziness).
But let’s put the stability approach to a side and pay attention to the lots of hype about pnpm package manager. It’s possible that we might benefit from migrating this small project to
Based on multiple user feedback typing
pnpm has never been comfortable, and it’s hard to say if it would ever be, but let’s get over this painful moment of
Worst case worse we’ll map it to an alias
p (such an acceptable terrible idea):
The initial assumption has been that IntelliJ Idea integration would be an issue, but it actually worked well. There was a possibility to change Node.js package manager to pnpm in Settings. Run/Debug configuration had this option as well.
This project is using Prisma ORM, and as soon as it was switched to
pnpm it started showing issues with the local client that’s supposed to be located in
node_modules/.prisma directory, which was not there.
After further research it turned out pnpm’s main feature is restructuring (hoisting) directories under
node_modules folder in order to optimize caching and faster access to already downloaded modules. This resulted to the sitation that Prisma simply couldn’t find it. It has been discussed online that this has been a poor choice of Prisma design, which I partially agree with.
Nevertheless, it was possible to work around the issue and add
prisma package to an exception list and disallow pnpm to hoist it.
As a result,
.npmrc file with the following contents has been created:
pnpm i succeeded!
When the time came to benefit from the caching and run
pnpm i for the second time, it failed with an issue of compiling a native package
bufferutil with node-gyp.
pnpm has an ongoing opened Github issue with node-gyp. This issue has been opened since Nov 6, 2019(!).
We can see that pnpm is trying to find node-gyp-build somewhere else.
There seemed to be workarounds, and one of them applied: locking down
node-gyp to an older version just for
It didn’t yield much results, as another issue came up with a different package, after which it was hard to rationalize the time required for fixing current issues, as npm speed was still sufficient.
The exploration of
pnpm had to be stopped, but hopefully some day everything would work with minor issues.
Per another suggestion on Twitter an additional tweak was added to
The issue suggests to set the child-concurrency=1 setting in .npmrc. That doesn't help?— zoltan 🇺🇦 (@ZoltanKochan) June 17, 2023
It has been set in addition to all other parameters. The final file looked like this:
Which didn’t yield any different results and a recurring
pnpm i resulted into the same error of not finding
This migration attempt has been performed for an internal project with only one person on the dev team, but even then it was quite cumbersome and it’s hard to imagine supporting an extensive list of exclusions long-term.
Objectively, npm packages on this project (and other internal projects, to be fair) are not installed so often and there seems to be very little benefit from a faster resolution/caching logic (unless it’s related to CI, of course). So as a result, it’s not worth chasing the performance as much. It’s entirely possible that this idea is biased (and possibly completely wrong, so it would be great to hear more opinions).
As a conclusion,
pnpm is a smart improvement over npm or yarn in terms of storing the packages, but it’s hard to justify moving to it yet and should not be recommended as a primary package manager for mainstream projects.