乐趣区

关于前端:Nodejs-应用-peer-dependency-的用法

有时候咱们能够从 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"
  }
}

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.
退出移动版