有时候我们可以从 package.json 文件里发现下面这些定义:
{
//...
"peerDependencies": {
"libraryName": "1.x"
}
}
dependencies
是我们的项目所依赖的包。
devDependencies
是在开发阶段需要的包。 比如说像 Jest 这样的测试框架或像 Babel 或 ESLint 这样的其他实用程序。
在这两种情况下,当我们安装一个包时,npm 会自动安装它的 dependencies
和 devDependencies.
peerDependencies 的工作机制不同。 它们不会
自动安装。
当一个依赖项(dependency
)在包中列为 peerDependency 时,它不会自动被安装。 相反,包含了这个包的应用代码,必须包含它作为其依赖项。
看一个例子。
项目 a 的 package.json,包含了项目 b:
{
//...
"dependencies": {
"b": "1.x"
}
}
项目 b 的 package.json:
{
//...
"peerDependencies": {
"c": "1.x"
}
}
因此,在包 A 中,我们必须添加 c 作为依赖项,否则当您安装包 b 时,npm 会抛出一个警告(并且代码可能会在运行时失败):
a 的 package.json:
{
//...
"dependencies": {
"b": "1.x",
"c": "1.x"
}
}
- 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