关于springboot:通过一个具体的例子理解-npm-的-peerDependency

1次阅读

共计 797 个字符，预计需要花费 2 分钟才能阅读完成。

假如咱们有两个 npm module A 和 B，A 是 B 的 plugin.

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

{
  "dependencies": {"B": "1.2.0"}
}

那么咱们在 host 利用里装置 A 后，层级后果如下：

node_modules
|_ A
  |_ node_modules
    |_ B

假如咱们又装置了两个 module C 和 D，则 node_modules 文件夹变为如下构造：

node_modules
|_ A
|  |_ node_modules
|      |_ B
|_C
|  |_ node_modules
|      |_ B
|_D
   |_ node_modules
       |_ B

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

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

要么像 NPM 一样：

查看 B 是否曾经装置
如果是，完结以后的检测，进行下一个包的解决
则疏忽它
如果不是，包管理器会试图将 B 正确装置在根级别（即在 project/node_module 中）。如果装置失败，会停止并显示对应的谬误音讯

不能胜利装置对等依赖项的起因之一，是存在抵触的版本。举个例子，A 依赖于 B 的 2.0.0 版本，C 依赖于 B 的 7.1.3 版本。如果 B 正确应用 semver(语义化版本)，则两个版本之间会有很多重大更改，因而 A 可能无奈与 C 所需的版本一起应用，反之亦然。这种状况下，须要开发人员自行作出抉择。

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

正文完