Fast, disk space efficient package manager
node_modulesfolder are organized always the same way, the way they are described in
Like this project? Let people know with a tweet.
pnpm uses hard links and symlinks to save one version of a module only ever once on a disk.
When using npm or Yarn for example, if you have 100 projects using the same version
of lodash, you will have 100 copies of lodash on disk. With pnpm, lodash will be saved in a
single place on the disk and a hard link will put it into the
node_modules where it should
As a result, you save gigabytes of space on your disk and you have a lot faster installations!
If you'd like more details about the unique
node_modules structure that pnpm creates and
why it works fine with the Node.js ecosystem, read this small article: Why should we use pnpm?
Install it via npm.
npm install -g pnpm
Do you wanna use pnpm on CI servers? See: Continuous Integration.
pnpm install lodash
pnpm in place of
npm. It overrides
Also, it has some custom commands, like
dislink for unlinking a package (like
yarn unlink but pnpm reinstalls
the dependency after removing the external link). The rest of the commands pass through to
For using the programmatic API, use pnpm's engine: supi.
pnpm uses npm's programmatic API to read configs. Hence, you should set configs for pnpm the same way you would for npm.
Furthermore, pnpm uses the same configs that npm uses for doing installations. If you have a private registry and npm is configured to work with it, pnpm should be able to authorize requests as well, with no additional configuration.
However, pnpm has some unique configs as well:
The location where all the packages are saved on the disk.
Currently if installations are done not on the same disk on which the store is, packages are copied, not linked, from the global store (see issue #712). You can use this config to set a store location that is on the same disk where installation is done.
If true, pnpm will use only packages already available in the store. If a package won't be found locally, the installation will fail.
Controls the maximum number of HTTP requests that can be done simultaneously.
Controls the number of child processes run parallelly to build node modules.
Dangerous! If false, the store is not locked. It means that several installations using the same store can run simultaneously.
Can be passed in via a CLI option.
--no-lock to set it to false. E.g.:
pnpm install --no-lock.
If you experience issues similar to the ones described in #594, use this option to disable locking. In the meanwhile, we'll try to find a solution that will make locking work for everyone.
If true, symlinks leaf dependencies directly from the global store. Leaf dependencies are
packages that have no dependencies of their own. Setting this config to
true might break some packages
that rely on location but gives an average of 8% installation speed improvement.
If false, doesn't check whether packages in the store were mutated.
pnpm is faster than npm and Yarn. See this benchmark which compares the three package managers on different types of applications.
time npm i babel-preset-es2015 browserify chalk debug minimist mkdirp 66.15 real 15.60 user 3.54 sys
time pnpm i babel-preset-es2015 browserify chalk debug minimist mkdirp 11.04 real 6.85 user 2.85 sys
package-lock.jsonare ignored. Unlike pnpm, npm can install the same
name@versionmultiple times and with different sets of dependencies. npm's shrinkwrap file is designed to reflect the
node_moduleslayout created by npm. pnpm cannot create a similar layout, so it cannot respect npm's lockfile format.
bundleDependenciesmanaged by pnpm.
node_modules/.bin) are always shell files not symlinks to JS files. The shell files are created to help pluggable CLI apps in finding their plugins in the unusual
node_modulesstructure. This is very rarely an issue and if you expect the file to be a js file, just reference the original file instead, as described in #736.
D:, you have to have the store on disk
D:. Currently pnpm cannot automatically detect whether the disk is the same or different (see #712). To avoid copying in cases like that, specify the store location manually via the
Got an idea for workarounds for these issues? Share them.
npm. The oldest and most widely used. See pnpm vs npm.
ied. Built on a very similar premise as pnpm. pnpm takes huge inspiration from it.
Yarn. The first Node.js package manager that invented lockfiles and offline installations.
node_modulesfolder use disk space if packages are stored in a global store?
pnpm creates hard links from the global store to project's
Hard links point to the same place on the disk where the original files are.
So, for example, if you have
foo in your project as a dependency and it occupies 1MB of space,
then it will look like it occupies 1MB of space in the project's
node_modules folder and
the same amount of space in the global store. However, that 1MB is the same space on the disk
addressed from two different locations. So in total
foo occupies 1MB,
For more on this subject:
Using symlinks on Windows is problematic indeed. That is why pnpm uses junctions instead of symlinks on Windows OS.
node_modulesapproach is basically incompatible with Windows
Early versions of npm had issues because of nesting all
node_modules (see Node's nested node_modules approach is basically incompatible with Windows). However, pnpm does not create deep folders, it stores all packages flatly and uses symlinks to create the dependency tree structure.
Although pnpm uses symlinks to put dependencies into
node_modules folders, circular symlinks are avoided because parent packages are placed into the same
node_modules folder in which their dependencies are. So
foo's dependencies are not in
foo is in
node_modules/foo, together with its own dependencies.
One package can have different sets of dependencies on one machine.
In project A
firstname.lastname@example.org can have dependency resolved to
email@example.com but in project B the same dependency of
firstname.lastname@example.org. So pnpm hard links
email@example.com to every project where it is used, in order to create different sets
of dependencies for it.
Direct symlinking to the global store would work with Node's
--preserve-symlinks flag. But
with a bunch of different issues, so we decided to stick with hard links.
For more details about why this decision was made, see: https://github.com/nodejs/node-eps/issues/46.