Frequently Asked Questions
Why does my node_modules folder use disk space if packages are stored in a global store?
pnpm creates hard links from the global store to the project's node_modules
folders. 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, not 2MB.
For more on this subject:
- Why do hard links seem to take the same space as the originals?
- A thread from the pnpm chat room
- An issue in the pnpm repo
Does it work on Windows?
Short answer: Yes. Long answer: Using symbolic linking on Windows is problematic to say the least, however, pnpm has a workaround. For Windows, we use junctions instead.
But the nested node_modules approach is incompatible with Windows?
Early versions of npm had issues because of nesting all node_modules (see
this issue). However, pnpm does not create deep folders, it stores all packages
flatly and uses symbolic links to create the dependency tree structure.
What about circular symlinks?
Although pnpm uses linking 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/node_modules, but foo is in node_modules together with its
own dependencies.
Why have hard links at all? Why not symlink directly to the global store?
One package can have different sets of dependencies on one machine.
In project A