TLDR:用于向消费代码公开（并预期由消费代码使用）的依赖项，而不是未公开的“私有”依赖项，它只是一个实现细节。

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

但在下列情况下就会出现问题:

• 您的项目和您正在使用的某个模块都依赖于另一个模块。/li>

假设您正在构建，并且使用了和。假设也依赖于，但依赖于不同的版本，比如。只要那2个版本不满足就没有问题。在表面下面使用这一事实只是一个实现细节。我们将捆绑了两次，但是当我们得到稳定的软件时，这是一个很小的代价。

但是现在，如果以某种方式公开了它对的依赖关系，该怎么办。例如，它接受的实例。当我们使用库的版本创建一个并将其传递给时会发生什么？所有的地狱都会崩溃！像这样简单的东西会突然返回，因为实际上是另一个的实例，即版本。

他们告诉npm

我需要这个包，但我需要的版本是项目的一部分，而不是我的模块私有的一些版本。

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

• 当您正在生成要由其他项目使用的库时，以及/li>

常见的场景是用于较大框架的插件。想想Gulp，Grunt，Babel，Mocha等。如果您编写了一个Gulp插件，您希望该插件与用户的项目正在使用的Gulp一起工作，而不是与您自己的私有版本Gulp一起工作。

我建议你先把这篇文章再读一遍。这有点令人困惑，但是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来定义对等依赖关系。您应该在github..上为grunt-steroids包打开一个问题。

用最简单的示例进行了解释:

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


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

在myPackage中运行npm安装将引发错误，因为它试图安装React版本和，后者仅与React版本兼容。

未安装对等依赖项。