NPM vs PNPM: Which One Node JS Package Manager Should You Use?

The job of a node js package manager is to install, update, and remove software packages and their dependencies. NPM has been the standard package manager for JavaScript for a long time, but companies are quickly switching to the pnpm package manager because it has so many advantages.

Before discussing the npm vs pnpm in-depth, we will take a look at what are npm and pnpm.

What is NPM?

Npm, which stands for Node Package Manager, is a library and registry for JavaScript software packages. It has command-line tools to support installing the different packages and handling their dependencies. It is free and also relies on over 11 million developers at a global level.

What is PNPM?

PNPM is a updated version of NPM that Node.js package manager uses to store all the files in a single place hence package manager can effectively use them if required.


Npm and pnpm are both package managers for Node.js which allow you to manage your project’s dependencies. There are some differences between them, even though they serve a similar purpose. So, let’s discuss about:-


Packages can’t be installed with pnpm without first being saved to the file package.json. If you don’t give any parameters to pnpm add, packages are saved as normal dependencies.

With –save-dev and –save optional, you can install packages as dev or option dependencies, just like an npm node package manager does in installation.

Due to this limitation, projects that use pnpm won’t have any extra packages only if they remove a dependency and leave it an orphaned package.

Because of this, the prune command in pnpm doesn’t let you choose specific packages to prune. Instead, it always removes all unused and orphaned packages.

Directory Dependencies

Directory dependencies begin with the file: prefix and point to a directory in the filesystem. Like npm, pnpm symlinks those components. Unlike npm, pnpm doesn’t install files that depend on each other.

It implies that if you have a package called foo (root>/foo) that depends on bar@file:../bar, running pnpm install on foo won’t install root>/bar.

If you want to install multiple packages simultaneously, like in a monorepo, you must look at the documentation for pnpm -r.

NPM’s Flat Tree

As of version 3, npm keeps track of a flattened dependency tree. It uses less disc space with a messy node_modules directory as a side effect.

Conversely, pnpm manages node_modules by hard and symbolic linking to a global on-disk content-addressable store. It will save you a lot of space on your hard drive and maintain your node_modules clean. If you want to learn more about how the store is set up, you can read about it.

The positive thing about pnpm’s proper node_modules structure is that it is difficult to use modules not listed in the project’s package.json, which ” assists in preventing silly bugs.”

Why Not NPM?

Npm uses flattened node_modules. Because of the flattened dependency, there are many problems, such as:

  1. The algorithm for flat dependency trees is hard to understand.
  2. Some packages need to be copied into the node_modules folder of another project.
  3. Modules can use packages that they don’t need.

Let’s use a simple example to understand its meaning. One of your projects needs an express module, and express needs a dependency package called “debug.” It is how the node_modules will be formulated:

node modules

You can use the required (‘debug’) in your code even if you don’t explicitly depend on the package.json file. Let’s talk about two things that can go wrong:

  1. Express updates its debug dependency by making breaking changes.
  2. Express does not depend on debugging anymore.

In both cases, your code will fail because it depends on debugging in an unstated way. That is a very big issue. In the same way, it will be much harder to keep track of a project’s dependencies if you work with a large monorepo. Another problem is that there are too many packages.

How Does PNPM Solve these Problems?

Hard links and symlinks are used by pnpm to keep the node_modules structure fairly strict. So, what makes a hard link different from a weak link? A hard link is another way to talk about the same file.

You make a new file with a weak link whose contents point to a different path. Symlinks are symbolic links pnpm uses to build a structure of dependencies nested inside each other.

Let’s look at the pnpm versions of the express and node_modules we talked about before.

node js modules

The file structure of your project is shown in the picture above. The first thing you will notice is that your code can’t access the “debug” package because it is not directly under the node_modules directory. Pnpm has made a special folder called “.pnpm” with hard links to all the modules.

If you look at express/4.0.0, the express module is a hard link to the global pnpm-store and a debug symbolic link to the debug hard link, which also links to the global pnpm-store.

Here is a picture of the real pnpm-store, which keeps the packages. It is where all the dependencies that have been downloaded are kept. Before downloading a dependency, pnpm checks whether it is already in this store. If the dependency is in the store, pnpm makes it by developing a hard link.

pnpm vs npm modules

Because of this, pnpm re-uses the same packages again if they have already been installed for another project. Now we can talk about the many benefits of pnpm.

Let’s talk about some of them.

Advantages of PNPM

PNPM did a great job with the disc memory. Let’s look at how pnpm keeps the interrelations in a global store on your machine, making a strong link between projects and dependencies. So, the projects share the exact interactions, which saves a lot of space.

In npm, it will also copy the same dependencies and store them in the project-specific node components, which takes up more storage space.

Let’s delve a bit more into the benefits of pnpm.

PNPM Uses a Non-flat Directory

By default, pnpm makes a symbolic link between the project node plugin and the global store. However, you can see that each project’s node_modules take up space on the disc.

Due to hard links, measuring which point would be on the exact same place as the original file is hard. But for a version, only one copy of the dependency is decided to keep in memory. See the picture below.

non-flat directory

Let’s look at a real-world example:-

Common Dependencies of each React App

“dependencies”: {

“@testing-library/jest-dom”: “⁵.16.5”,

“@testing-library/react”: “¹³.3.0”,

“@testing-library/user-event”: “¹³.5.0”,

“react”: “¹⁸.2.0”,

“react-dom”: “¹⁸.2.0”,

“react-scripts”: “5.0.1”,

“web-vitals”: “².1.4”


Projects developed with NPM

project with npm

Total Size in Disk: 1260 MB

Projects developed with PNPM

projects with pnpm

Note: All dependencies will be in global stores, not each project. The above table is used to tell things apart.

Total Size in Disk: 500 MB

Common dependencies are put in the global store, which the project can use to get what it needs. Based on the example above, dependencies that are used often have 380MB.

From the above example, we can see that pnpm has helped us save 60% of disc space smartly. You can also hire a node js developer to install the program with pnpm.

PNPM is Faster

pnpm is faster than other dependency managers because its installation has no steps that can’t be done simultaneously. Each dependency has its stage, and the next stage begins as soon as each dependency is installed.

pnpm is faster

Pnpm is the yellow part that installs packages much faster than npm in most cases. It will also install packages twice as fast as npm.

Let’s look at the benchmark information, which compares pnpm and npm:

npm vs pnpm differences


Overall, pnpm is still much faster than npm when installing packages.

Efficient Use of Disk Space

On the inside, pnpm stores all packages and dependencies on a disc with a content-addressable file system. It indicates that the same packages will not be copied. Even if the different version of the same package, pnpm is intelligent enough to re-use the maximum code.

If a package version 1 has 1000 files and version 2 has added another file, then pnpm will not write 1001 files for version 2. Instead, it will make a hard link to the original 1000 files and write the new file. If you compare it to npm, version 2 will also be loaded with duplicating the original 1000 files.

For large monorepo projects, it can create a big difference. For example, if hundreds require a package of other packages, it will fill your disk space unless you use pnpm.

High Security

Because of the flat structure of node_module, if A relies on B and B relies on C, then A can utilise C directly, but the issue is that A does not disclose C as a dependency.

So, this type of unauthorised access happens in the case of npm. But pnpm has made a set of methods for managing dependencies and different folder structure of node_modules that addresses this issue well and keeps things safe.

Moreover, pnpm provides great assistance for monorepo and offline modes. You can also consult the node js development company to install the pnpm safely.


In conclusion, pnpm is faster and better at managing disc memory than npm. It is a big difference between pnpm vs npm. Because, it gives us a lot of disc space to work with many projects and small front-end apps at once.

Putting dependencies in the global store and using them again is more efficient. It is something that the npm package manager can’t do.

Related Posts