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

Question

例如，为什么Grunt插件将其对grunt的依赖定义为"peer dependencies"？

为什么这个插件不能在grunt-plug/node_modules中让Grunt作为它自己的依赖项

同级依赖关系在这里描述：https://nodejs.org/en/blog/npm/peer-dependencies/

但我真的不明白。

示例

我目前正在使用AppGyver类固醇，它使用Grunt任务将我的源文件构建到/dist/文件夹中，以便在本地设备上提供服务。我在npm和grunt方面是个新手，所以我想完全理解发生了什么。

到目前为止，我得到了这样的结论：

rootfolder/package.json告诉npm，它依赖于grunt-steroids npm包进行开发：

  "devDependencies": {
    "grunt-steroids": "0.x"
  },

好吧。在rootfolder/node_modules/grunt-steroids.根文件夹中运行npm install会检测依赖项并在根文件夹中安装grunt steroid

然后Npm读取rootfolder/node_modules/grunt-steroids/package.json，这样它就可以安装grunt-steroids自己的依赖项。

"devDependencies": {
    "grunt-contrib-nodeunit": "0.3.0",
    "grunt": "0.4.4"
  },
"dependencies": {
    "wrench": "1.5.4",
    "chalk": "0.3.0",
    "xml2js": "0.4.1",
    "lodash": "2.4.1"
  },
"peerDependencies": {
    "grunt": "0.4.4",
    "grunt-contrib-copy": "0.5.0",
    "grunt-contrib-clean": "0.5.0",
    "grunt-contrib-concat": "0.4.0",
    "grunt-contrib-coffee": "0.10.1",
    "grunt-contrib-sass": "0.7.3",
    "grunt-extend-config": "0.9.2"
  },

"dependencies“包被安装到rootfolder/node_modules/grunt-steroids/node_modules中，这对我来说是合乎逻辑的。

"devDependencies“没有安装，我确信这是由npm控制的，我只是在尝试使用grunt-steroids，而不是在它上进行开发。

但是我们有了"peerDependencies".

这些都安装在rootfolder/node_modules，中，我不明白为什么在rootfolder/node_modules/grunt-steroids/node_modules中有和没有，这样就避免了与其他grunt插件(或其他插件)的冲突？

Answer 1

TL;DR: peerDependencies用于向消费代码公开(并期望由其使用)的依赖项，而不是未公开的“私有”依赖项，并且只是一个实现细节。

对等依赖关系解决了问题

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

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

• 您的项目和正在使用的某些模块都依赖于另一个模块。
• 这三个模块必须相互通信。

示例中

假设您正在构建YourCoolProject，并且同时使用JacksModule 1.0和JillsModule 2.0。让我们假设JacksModule也依赖于JillsModule，但是依赖于一个不同的版本，比如1.0。只要这两个版本不匹配，就没有问题。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。

Answer 2

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

例如，让我们假设winston-mail@0.2.3在其"dependencies"对象中指定了"winston": "0.5.x"，因为这是对其进行测试的最新版本。作为应用程序开发人员，您想要最新、最好的东西，所以您查找winston和winston-mail的最新版本，并将它们放入您的package.json中

{“依赖”：{ "winston"："0.6.2"，"winston-mail"："0.2.3“}}

但是现在，运行npm install会导致意外的依赖关系图

电子邮件：├──winston@0.6.2└─┬winston@0.2.3└──winston@0.5.11

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

One regular ：对等依赖要求，与常规依赖不同，应该是宽松的。您不应该将您的对等依赖项锁定到特定的修补程序版本。

因此，开发人员应该遵循semver来定义peerDependencies。你应该在GitHub上打开一个问题-类固醇包..。

Answer 3

peerDependencies用最简单的例子来解释：

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


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

在myPackage中运行npm install将抛出一个错误，因为它正在尝试安装React版本^15.0.0和foo，它只与React ^16.0.0兼容。

未安装peerDependencies。