为什么在 npm 中为插件使用对等依赖项？

TL;DR： peerDependencies 用于暴露给消费代码（并预期被消费代码使用）的依赖项，而不是 “私有” 依赖项暴露，并且只是一个实现细节。

对等依赖关系解决的问题

NPM 的模块系统是分层的。更简单场景的一大优势是，当您安装 npm 包时，该包会自带依赖项，因此它可以开箱即用。

但在以下情况下会出现问题：

您的项目和您正在使用的某个模块都依赖于另一个模块。

这三个模块必须相互通信。

在示例中

假设您正在构建 YourCoolProject，并且同时使用 JacksModule 1.0 和 JillsModule 2.0。假设 JacksModule 也依赖于 JillsModule，但依赖于不同的版本，例如 1.0。只要这2个版本不满足，就没有问题。 JacksModule 在表面之下使用 JillsModule 的事实只是一个实现细节。我们将 JillsModule 捆绑了两次，但是当我们获得开箱即用的稳定软件时，这是一个很小的代价。

但是现在如果 JacksModule 以某种方式暴露了它对 JillsModule 的依赖会怎样。例如，它接受 JillsClass 的实例...当我们使用库的版本 2.0 创建 new JillsClass 并将其传递给 jacksFunction 时会发生什么？所有的地狱都会崩溃！ jillsObject instanceof JillsClass 之类的简单事物会突然返回 false，因为 jillsObject 实际上是 另一个 JillsClass 的实例，即 2.0 版本。

对等依赖如何解决这个问题

他们告诉 npm

我需要这个包，但我需要作为项目一部分的版本，而不是我的模块私有的版本。

当 npm 发现你的包被安装到一个没有该依赖项的项目中，或者它的版本不兼容时，它会在安装过程中警告用户。

什么时候应该使用对等依赖项？

当您构建一个供其他项目使用的库时，以及

该库正在使用其他库，并且

您期望/需要用户也可以使用其他库

常见的场景是大型框架的插件。想想 Gulp、Grunt、Babel、Mocha 等。如果您编写 Gulp 插件，您希望该插件与用户项目正在使用的 Gulp 一起工作，而不是与您自己的 Gulp 私有版本一起工作。

---

我建议你先再读一遍这篇文章。这有点令人困惑，但 winston-mail 的示例向您展示了原因：

例如，假设 winston-mail@0.2.3 在其“依赖项”对象中指定了“winston”：“0.5.x”，因为这是对其进行测试的最新版本。作为应用程序开发人员，您想要最新最好的东西，因此您查找 winston 和 winston-mail 的最新版本并将它们作为 { "dependencies": { "winston": "0.6.2 ", "winston-mail": "0.2.3" } } 但是现在，运行 npm install 会导致意外的依赖关系图 ├── winston@0.6.2 └─┬ winston-mail@0.2.3 └── winston @0.5.11

在这种情况下，一个包可能有多个版本，这会导致一些问题。对等依赖项允许 npm 开发人员确保用户具有特定模块（在根文件夹中）。但是你说得对，描述一个特定版本的包会导致使用其他版本的其他包出现问题。正如文章所述，此问题与 npm 开发人员有关

一条建议：与常规依赖不同，对等依赖要求应该宽松。您不应该将您的对等依赖项锁定到特定的补丁版本。

因此，开发人员应遵循 semver 来定义 peerDependencies。您应该在 GitHub 上为 grunt-steroids 包打开一个问题...

---

peerDependencies 用最简单的例子解释：

{
  "name": "myPackage",
  "dependencies": {
    "foo": "^4.0.0",
    "react": "^15.0.0"
  }
}


{
  "name": "foo"
  "peerDependencies": {
    "react": "^16.0.0"
  }
}

在 myPackage 中运行 npm install 将引发错误，因为它正在尝试安装仅与 React ^16.0.0 兼容的 React 版本 ^15.0.0 AND foo。

未安装 peerDependencies。

---