Um dos melhores recursos do pnpm é que em um projeto, uma versão específica de um pacotesempre terá um conjunto de dependências. There is one exception fromthis rule, though - packages withpeer dependencies.

As dependências de peer são resolvidas a partir de dependências instaladas mais acima no gráfico de dependência, pois compartilham a mesma versão que seu pai. That meansthat iffoo@1.0.0 has two peers (bar@^1 andbaz@^1) then it might havemultiple different sets of dependencies in the same project.

- foo-parent-1
  - bar@1.0.0
  - baz@1.0.0
  - foo@1.0.0
- foo-parent-2
  - bar@1.0.0
  - baz@1.1.0
  - foo@1.0.0

In the example above,foo@1.0.0 is installed forfoo-parent-1 andfoo-parent-2. Both packages havebar andbaz as well, but they depend ondifferent versions ofbaz. As a result,foo@1.0.0 has two different sets ofdependencies: one withbaz@1.0.0 and the other one withbaz@1.1.0. Tosupport these use cases, pnpm has to hard linkfoo@1.0.0 as many times asthere are different dependency sets.

Normally, if a package does not have peer dependencies, it is hard linked to anode_modules folder next to symlinks of its dependencies, like so:

node_modules
└── .pnpm
    ├── foo@1.0.0
    │   └── node_modules
    │       ├── foo
    │       ├── qux   -> ../../qux@1.0.0/node_modules/qux
    │       └── plugh -> ../../plugh@1.0.0/node_modules/plugh
    ├── qux@1.0.0
    ├── plugh@1.0.0

However, iffoo has peer dependencies, there may be multiple sets ofdependencies for it, so we create different sets for different peer dependencyresolutions:

node_modules
└── .pnpm
    ├── foo@1.0.0_bar@1.0.0+baz@1.0.0
    │   └── node_modules
    │       ├── foo
    │       ├── bar   -> ../../bar@1.0.0/node_modules/bar
    │       ├── baz   -> ../../baz@1.0.0/node_modules/baz
    │       ├── qux   -> ../../qux@1.0.0/node_modules/qux
    │       └── plugh -> ../../plugh@1.0.0/node_modules/plugh
    ├── foo@1.0.0_bar@1.0.0+baz@1.1.0
    │   └── node_modules
    │       ├── foo
    │       ├── bar   -> ../../bar@1.0.0/node_modules/bar
    │       ├── baz   -> ../../baz@1.1.0/node_modules/baz
    │       ├── qux   -> ../../qux@1.0.0/node_modules/qux
    │       └── plugh -> ../../plugh@1.0.0/node_modules/plugh
    ├── bar@1.0.0
    ├── baz@1.0.0
    ├── baz@1.1.0
    ├── qux@1.0.0
    ├── plugh@1.0.0

We create symlinks either to thefoo that is insidefoo@1.0.0_bar@1.0.0+baz@1.0.0 or to the one infoo@1.0.0_bar@1.0.0+baz@1.1.0.Como consequência, o resolvedor do módulo Node.js encontrará os pares corretos.

If a package has no peer dependencies but has dependencies with peers that areresolved higher in the graph, then that transitive package can appear in theproject with different sets of dependencies. For instance, there's packagea@1.0.0 with a single dependencyb@1.0.0.b@1.0.0 has a peer dependencyc@^1.a@1.0.0 will never resolve the peers ofb@1.0.0, so it becomesdependent from the peers ofb@1.0.0 as well.

Here's how that structure will look innode_modules. In this example,a@1.0.0 will need to appear twice in the project'snode_modules - resolvedonce withc@1.0.0 and again withc@1.1.0.

node_modules
└── .pnpm
    ├── a@1.0.0_c@1.0.0
    │   └── node_modules
    │       ├── a
    │       └── b -> ../../b@1.0.0_c@1.0.0/node_modules/b
    ├── a@1.0.0_c@1.1.0
    │   └── node_modules
    │       ├── a
    │       └── b -> ../../b@1.0.0_c@1.1.0/node_modules/b
    ├── b@1.0.0_c@1.0.0
    │   └── node_modules
    │       ├── b
    │       └── c -> ../../c@1.0.0/node_modules/c
    ├── b@1.0.0_c@1.1.0
    │   └── node_modules
    │       ├── b
    │       └── c -> ../../c@1.1.0/node_modules/c
    ├── c@1.0.0
    ├── c@1.1.0