피어가 해결되는 방법

pnpm의 가장 좋은 기능 중 하나는 한 프로젝트에서 패키지의 특정 버전이 항상 하나의 의존성 세트를 갖는다는 것입니다. There is one exception from this rule, though - packages with peer dependencies.

피어 의존성은 그들의 부모와 동일한 버전을 공유하기 때문에 의존성 그래프에서 더 높게 설치된 의존성으로부터 해결됩니다. That means that if [email protected] has two peers (bar@^1 and baz@^1) then it might have multiple different sets of dependencies in the same project.

- foo-parent-1
  - [email protected]
  - [email protected]
  - [email protected]
- foo-parent-2
  - [email protected]
  - [email protected]
  - [email protected]

In the example above, [email protected] is installed for foo-parent-1 and foo-parent-2. Both packages have bar and baz as well, but they depend on different versions of baz. As a result, [email protected] has two different sets of dependencies: one with [email protected] and the other one with [email protected]. To support these use cases, pnpm has to hard link [email protected] as many times as there are different dependency sets.

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

node_modules
└── .pnpm
    ├── [email protected]
    │   └── node_modules
    │       ├── foo
    │       ├── qux   -> ../../[email protected]/node_modules/qux
    │       └── plugh -> ../../[email protected]/node_modules/plugh
    ├── [email protected]
    ├── [email protected]

However, if foo has peer dependencies, there may be multiple sets of dependencies for it, so we create different sets for different peer dependency resolutions:

node_modules
└── .pnpm
    ├── [email protected][email protected][email protected]
    │   └── node_modules
    │       ├── foo
    │       ├── bar   -> ../../[email protected]/node_modules/bar
    │       ├── baz   -> ../../[email protected]/node_modules/baz
    │       ├── qux   -> ../../[email protected]/node_modules/qux
    │       └── plugh -> ../../[email protected]/node_modules/plugh
    ├── [email protected][email protected][email protected]
    │   └── node_modules
    │       ├── foo
    │       ├── bar   -> ../../[email protected]/node_modules/bar
    │       ├── baz   -> ../../[email protected]/node_modules/baz
    │       ├── qux   -> ../../[email protected]/node_modules/qux
    │       └── plugh -> ../../[email protected]/node_modules/plugh
    ├── [email protected]
    ├── [email protected]
    ├── [email protected]
    ├── [email protected]
    ├── [email protected]

We create symlinks either to the foo that is inside [email protected][email protected][email protected] or to the one in [email protected][email protected][email protected]. 결과적으로 Node.js 모듈 resolver는 올바른 피어를 찾습니다.

If a package has no peer dependencies but has dependencies with peers that are resolved higher in the graph, then that transitive package can appear in the project with different sets of dependencies. For instance, there's package [email protected] with a single dependency [email protected]. [email protected] has a peer dependency c@^1. [email protected] will never resolve the peers of [email protected], so it becomes dependent from the peers of [email protected] as well.

Here's how that structure will look in node_modules. In this example, [email protected] will need to appear twice in the project's node_modules - resolved once with [email protected] and again with [email protected].

node_modules
└── .pnpm
    ├── [email protected][email protected]
    │   └── node_modules
    │       ├── a
    │       └── b -> ../../[email protected][email protected]/node_modules/b
    ├── [email protected][email protected]
    │   └── node_modules
    │       ├── a
    │       └── b -> ../../[email protected][email protected]/node_modules/b
    ├── [email protected][email protected]
    │   └── node_modules
    │       ├── b
    │       └── c -> ../../[email protected]/node_modules/c
    ├── [email protected][email protected]
    │   └── node_modules
    │       ├── b
    │       └── c -> ../../[email protected]/node_modules/c
    ├── [email protected]
    ├── [email protected]