npm's flat tree
npm maintains a flattened dependency tree as of version 3. This leads to lessdisk space bloat, with a messy node_modules directory as a side effect.
On the other hand, pnpm manages node_modules by using hard linking andsymbolic linking to a global on-disk content-addressable store. This lets you get the benefits of far less disk space usage, while also keeping yournode_modules clean. There is documentation on the store layout if you wishto learn more.
The good thing about pnpm's proper node_modules structure is that it"helps to avoid silly bugs" by making it impossible to use modules that are notspecified in the project's package.json.
Installation
pnpm does not allow installation of packages without saving them topackage.json. If no parameters are passed to pnpm add, packages are saved asregular dependencies. Like with npm, --save-dev and --save-optional can beused to install packages as dev or optional dependencies.
As a consequence of this limitation, projects won't have any extraneous packageswhen they use pnpm unless they remove a dependency and leave it orphaned. That'swhy pnpm's implementation of the prune command does not allow you to specifypackages to prune - it ALWAYS removes all extraneous and orphaned packages.
Directory dependencies
Directory dependencies start with the file: prefix and point to a directory inthe filesystem. Like npm, pnpm symlinks those dependencies. Unlike npm, pnpmdoes not perform installation for the file dependencies.
This means that if you have a package called foo (<root>/foo) that hasbar@file:../bar as a dependency, pnpm won't perform installation for<root>/bar when you run pnpm install on foo.
If you need to run installations in several packages at the same time, forinstance in the case of a monorepo, you should look at the documentation forpnpm -r.
