Perché la mia cartella
node_modules utilizza spazio su disco se i pacchetti sono salvati in un archivio globale?#
pnpm creates hard links from the global store to 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
Using symlinks on Windows is problematic indeed. That is why pnpm uses junctions instead of symlinks on Windows OS.
Funziona su Windows? Nested
node_modules approach 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
[email protected] can have dependency resolved to
[email protected] but in project B the same dependency of
foo might resolve to
[email protected]. So pnpm hard links
[email protected] 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
--preserve-symlinks comes 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.
The package store should be on the same disk as installations. Otherwise packages will be copied, not linked. This is due to a OS limitation in hard-linking. See Issue #712 for more details.
pnpm functions differently based on the 2 cases below:
If the store path is specified via the store config, then copying occurs between the store and any projects that are on a different disk.
If you run
pnpm install on disk
D:, then the pnpm store must be on disk
D:. If the pnpm store is located on disk
C:, then all required packages will be directly copied to the project location. This severely reduces the benefits of pnpm.
If the store path is not set, then multiple stores are created (one per each drive or filesystem).
If installation is run on disk
D:, the store will be created in
D:\.pnpm-store. If later the installation is run on disk
C:, an independent store will be created in
C:\.pnpm-store. The projects would still maintain the benefits of pnpm, but each drive may have redundant packages.
pnpm store prune do? Is it harmful?#
pnpm store prune removes unreferenced packages.
Unreferenced packages are packages that are not used by any projects on the system. Packages can become unreferenced after most installation operations.
For example: during
pnpm install, package
[email protected] is updated to
[email protected]. pnpm will keep
[email protected] in the store, as it does not automatically remove packages. If package
[email protected] is not used by any other project on the system, it becomes unreferenced. Running
pnpm store prune would remove
[email protected] from the store.
pnpm store prune is not harmful and has no side effects on your projects. If future installations require removed packages, pnpm will download them again.
It is best practice to run
pnpm store prune occasionally to clean up the store, but not too frequently. Sometimes, unreferenced packages become required again. This could occur when switching branches and installing older dependencies. Then pnpm would need to re-download all removed packages, briefly slowing down the installation process.
npm performante. Rico Sta. Cruz ha ideato questo nome.
pnpm does not work with <YOUR-PROJECT-HERE>?#
In most cases it means that one of the dependencies require packages not declared in
package.json. It is a common mistake caused by flat
node_modules. If this happens, this is an error in the dependency and the dependency should be fixed. That might take time though, so pnpm supports workarounds to make the buggy packages work.
In the following example, a dependency does not have the
iterall module in its own list of deps.
The easiest solution to resolve missing dependencies of the buggy packages is to add
iterall as a dependency to our project's
You can do so, by installing it via:
pnpm i iterall
It will be automatically added to your project's
One of the solutions is to use hooks for adding the missing dependencies to the package's
An example was Webpack Dashboard which wasn't working with
pnpm. It has since been resolved such that it works with
It used to throw an error:
The problem was that
babel-traverse was used in
inspectpack library which was used by
babel-traverse wasn't specified in
package.json. It still worked with
yarn because they create flat
Solution was to create a
pnpmfile.js with the following contents:
pnpm-lock.yaml only. No need to delete
node_modules. Then install the dependencies & it should be working.
In case there are too many issues, you can use the
shamefully-hoist config. This creates a flat
node_modules structure similar to the one created by
To use it, try
pnpm install --shamefully-hoist.