Aryan Shaily

Why do we even need pnpm?

We use pnpm for our monorepo at work. I remember when I first asked why use pnpm? A senior of mine had said that it saves space by using a central store and it was a good enough answer for me. Yeah ik that was stupid of me to not ask more questions. In this blog lets try to understand why do different package managers exist?

As I already mentioned we at work use pnpm for our monorepo but we also use yarn for our marketing website and yes we’ve used npm here and there in some internal tools as well. So yes there are a lot of options out there and people like us are using almost all of them. Some prefer one over the other. So why’s that? Why do we even have different package managers? Why do we use pnpm for our monorepo but not in the website project? How does pnpm save space? These are all the questions that I should’ve asked my senior the first time I asked them about the choice of our package manager for monorepo and now I’m gonna try to answer them.

There are three different package managers npm, yarn, and pnpm. We all already know npm its the first package manager that we get to know about when dipping our foot into the javascript world. Yarn and pnpm come a little later as you explore more projects on the internet or you explore tutorials of more complex projects. Npm was the first package manager that came with node. It was nice and easy to use. You had package.json to mention all your dependecies and a node_modules folder where all the dependecies would go. The package-lock.json file would store the dependency graph with the exact versions of the dependencies installed. All of this came with a few drawbacks as well. The node_modules folders were gigantic and you had multiple such node_modules folders in your projects. The package downloads were also serial and the package-lock file also not deterministic meaning less consistant/reliable behaviour.

This is where yarn comes with deterministic lock files and faster package downloads. The lockfiles were human readable and you didn’t need to spend countless hours trying to fix conflicts in your package_lock files. More deterministic lock file also meant that we could reliably install projects in multiple devices without getting weird dependency version mismatches. Pnpm improved on both yarn and npm, the lock file is human readable and deterministic and the dependencies to the dependencies are scoped to their parent packages meaning there’s no conflict incase multiple versions of the same dependencies are installed. All the pacakges are hardlinked from a central store and symlinks are used in the local folders to scope dependencies to their corresponding packages.

While working with package managers you’ll come across terms like hoisting, peerDependencies and dependency resolution. So lets discuss them as well. Dependency hoisting is an optimization technique used by package managers by putting the packages that are shared between packages on the top level of the node_modules. peerDependencies are the dependecies that are required by some package and is not included in its installed dependencies, in this case the parent package then need to install the packages mentioned in peerDependencies. Dependency Resolution is the how Node knows what package to look for in node_modules.

Pnpm is very strict in nature for how it handles dependency resolution. As already mentioned earlier the dependencies are scoped to their parent packages to avoid any inconsistencies during dependency resolution and avoid packages from accessing other packages not mentioned in their dependencies. This comes in very handy when working with monorepos, as monorepos can easily have multiple packages that might install different versions of the same repositories. This is the reason why we use pnpm for our monorepo as well. It makes the dpenedencies much more predictable and also saves space on the device.