例如，为什么Grunt插件将其对grunt的依赖关系定义为“ 对等依赖关系 ”？

为什么插件不能仅在Grunt -plug / node_modules中将 Grunt作为其依赖项？

对等依赖项在此处进行了描述：https : //nodejs.org/en/blog/npm/peer-dependencies/

但是我真的不明白。

例

目前，我正在使用AppGyver Steroids，它使用Grunt任务将我的源文件构建到/ dist /文件夹中，以便在本地设备上提供服务。我在npm上很新，很咕unt，所以我想完全理解发生了什么。

到目前为止，我得到了：

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

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

好的。在[rootfolder]中运行npm install 可以检测依赖性，并在[rootfolder] / node_modules / grunt-steroids中安装grunt-steroids。

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"
  },

“ 依赖 ”软件包安装在[rootfolder] / node_modules / grunt-steroids / node_modules中，这对我来说很合理。

未安装“ devDependencies ”，我确定这是由npm检测控制的，即我只是在尝试使用grunt-steroids而不是在上面进行开发。

但是然后我们有了“ peerDependencies ”。

这些安装在[rootfolder] / node_modules中，我不明白为什么在[rootfolder] / node_modules / grunt-steroids / node_modules中而不安装在其中，从而避免了与其他grunt插件（或其他）的冲突？

TL; DR：^[1] peerDependencies用于暴露于使用方代码（并预计将由使用方代码使用）的依赖关系，而不是“私有”依赖项，而不是未公开的依赖项，仅是实现细节。

对等依赖性问题解决

NPM的模块系统是分层的。简单方案的一大优势是，当您安装npm软件包时，该软件包会带来自己的依赖关系，因此可以立即使用。

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

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

在例子中

假设您正在构建，YourCoolProject并且同时使用JacksModule 1.0和JillsModule 2.0。让我们假设这JacksModule也取决于JillsModule，但是取决于不同的版本，比如说1.0。只要这两个版本不符合要求，就没有问题。在表面之下JacksModule使用的事实JillsModule仅仅是实现细节。我们捆绑了JillsModule两次，但是当我们获得开箱即用的稳定软件时，这是一个很小的代价。

但是现在如果 JacksModuleJillsModule以某种方式公开其依赖性的话。例如，它接受一个实例JillsClass...当我们创建该库的new JillsClass使用版本2.0并将其传递给时，会发生jacksFunction什么？所有的地狱都会挣脱！诸如此类的简单事情jillsObject instanceof JillsClass会突然返回，false因为jillsObject实际上是另一个 实例JillsClass的2.0版本。

对等依赖性如何解决这个问题

他们告诉npm

我需要这个软件包，但是我需要项目中包含的版本，而不是模块私有的版本。

当npm看到您的软件包正在安装到不具有该依赖项或具有不兼容版本的项目中时，它将在安装过程中向用户发出警告。

什么时候应该使用对等依赖关系？

• 当您构建供其他项目使用的库时，以及
• 该库正在使用其他库，并且
• 您希望/也需要用户与该其他库一起使用

常见方案是适用于大型框架的插件。想想诸如Gulp，Grunt，Babel，Mocha等之类的东西。如果编写Gulp插件，则希望该插件与用户项目所使用的Gulp一起使用，而不是与自己的Gulp私有版本一起使用。

注解

1. 太长; 没看。用于表示人们认为过长的文本的简短摘要。

我建议您先重新阅读该文章。有点令人困惑，但是带有winston-mail的示例向您显示了答案：

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

{
  "dependencies": {  
    "winston": "0.6.2",  
    "winston-mail": "0.2.3"  
  }  
}

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

├── winston@0.6.2  
└─┬ winston-mail@0.2.3                
  └── winston@0.5.11

在这种情况下，可能有一个软件包的多个版本，这会引起一些问题。对等依赖性使npm开发人员可以确保用户具有特定的模块（在根文件夹中）。但是，您的观点是正确的，即描述软件包的一个特定版本会导致使用其他版本的其他软件包出现问题。如文章所述，此问题与npm开发人员有关

建议之一：与常规依赖项不同，对等依赖项要求应宽松。您不应将对等依赖项锁定到特定的补丁程序版本。

因此，开发人员应遵循semver定义peerDependencies。您应该在GitHub上打开grunt-steroids软件包的问题...

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.0AND foo并且仅与React兼容^16.0.0。

没有安装peerDependencies。