通过一个具体的例子理解 npm 的 peerDependency

假设我们有两个 npm module A 和 B，A 是 B 的 plugin.

如果 ABAP 的 package.json 里将 B 定义成其 dependency：

{
  "dependencies": {
     "B": "1.2.0"
  }
}
1
2
3
4
5

那么我们在 host 应用里安装 A 后，层级结果如下：

node_modules
|_ A
  |_ node_modules
    |_ B
1
2
3
4

假设我们又安装了两个 module C 和 D，则 node_modules 文件夹变为如下结构：

node_modules
|_ A
|  |_ node_modules
|      |_ B
|_C
|  |_ node_modules
|      |_ B
|_D
   |_ node_modules
       |_ B
1
2
3
4
5
6
7
8
9
10

如果安装的 B 版本都是相同的，这将起作用，但是，如果不是，我们就会遇到潜在的问题。 当然我们还忽略了这样一个事实，即实际上，我们将模块 B 复制了三次，这是毫无意义的。

这里的重点是，如果开发人员将 B 声明为 A、C 和 D 的 peer dependency 依赖项，则我们选择的包管理器会做两件事之一。它要么只是忽略这种依赖关系（就像 Yarn 默认情况下所做的那样），让开发人员来自行作出抉择。

要么像 NPM 一样：

1. 检查 B 是否已经安装
2. 如果是，结束当前的检测，进行下一个包的处理
   则忽略它
3. 如果不是，包管理器会试图将 B 正确安装在根级别（即在 project/node_module 中）。如果安装失败，会中止并显示对应的错误消息

不能成功安装对等依赖项的原因之一，是存在冲突的版本。 举个例子，A 依赖于 B 的 2.0.0 版本，C 依赖于 B 的7.1.3 版本。 如果 B 正确使用 semver(语义化版本)，则两个版本之间会有很多重大更改，因此 A 可能无法与 C 所需的版本一起使用，反之亦然。 这种情况下，需要开发人员自行作出抉择。

当我们在开发将被其他 consume 重用的代码（例如 plugin 和 package）时，对等依赖项会真正发挥作用。 如果只是开发最终产品级的应用，则无需考虑 Peer Dependency.