Node.js 应用 peer dependency 的用法

有时候我们可以从 package.json 文件里发现下面这些定义：

{
  //...
  "peerDependencies": {
    "libraryName": "1.x"
  }
}
1
2
3
4
5
6

dependencies 是我们的项目所依赖的包。

devDependencies 是在开发阶段需要的包。 比如说像 Jest 这样的测试框架或像 Babel 或 ESLint 这样的其他实用程序。

在这两种情况下，当我们安装一个包时，npm 会自动安装它的 dependencies 和 devDependencies.

peerDependencies 的工作机制不同。 它们不会自动安装。

当一个依赖项(dependency)在包中列为 peerDependency 时，它不会自动被安装。 相反，包含了这个包的应用代码，必须包含它作为其依赖项。

看一个例子。

项目 a 的 package.json，包含了项目 b：

{
  //...
  "dependencies": {
    "b": "1.x"
  }
}
1
2
3
4
5
6

项目 b 的 package.json：

{
  //...
  "peerDependencies": {
    "c": "1.x"
  }
}
1
2
3
4
5
6

因此，在包 A 中，我们必须添加 c 作为依赖项，否则当您安装包 b 时，npm 会抛出一个警告（并且代码可能会在运行时失败）：

a 的 package.json：

{
  //...
  "dependencies": {
    "b": "1.x",
    "c": "1.x"
  }
}
1
2
3
4
5
6
7

peerDependencies的一个问题：

如果我的包依赖于 request 版本 2 和其他库，但其他库依赖于 request 版本 1，则生成的依赖关系图如下所示：

现在 some-other-library 拥有自己的请求 v1 副本，同时不会干扰应用程序本身 request 包的 v2 副本。

总之，对等依赖项几乎与普通依赖项一样，但不是在 A 和 B 之间定义强需求（即您正在开发的项目及其所依赖的项目），它们旨在指定您的代码所需的包，但不并不是直接 require 它。

想象一下，我们正在开发模块 A，它是模块 B 的插件。这意味着 A 将与 B 一起使用，为此，A 需要遵循一定的结构，并且很可能有一个符合以下标准的公共 API，以被 B 的方法中调用。

//in your code...
B.addPlugin(new A())
//....

B.method() //internally using A's code here.
1
2
3
4
5