我想在回答中补充我对这些依赖性解释的看法

依赖项用于直接在代码库中使用，通常会在生产代码中使用，或代码块中使用devDependencies用于构建过程、帮助您管理最终代码的方式的工具、第三方测试模块（例如webpack）

依赖项：项目/包需要在生产环境中工作的包。

devDependencies：您的项目/包在开发时需要工作但在生产中不需要的包（例如：测试包）

peerDependencies：您的项目/包需要与之协同工作（与它们“协同工作”）或作为基础的包，主要用于开发插件/组件以了解您的插件/组件应该与哪个版本的“主”包协同工作（例如：React 16）

在尝试分发npm包时，应避免使用依赖项。相反，您需要考虑将其添加到peerDependencies中。

使现代化

大多数时候，依赖关系只是描述您的生态系统的一堆库。除非你真的在使用某个库的特定版本，否则你应该让用户通过将其添加到peerDependencies中来选择是否安装该库以及选择哪个版本。

直到我读了一篇关于Ciro的博客文章中的这段话，我才明白peerDependencies对我的意义：

[插件]需要的是一种表达插件及其宿主包之间的“依赖关系”的方式。用某种方式来说，“我只在插入到我的主机包的1.2.x版本时工作，所以如果您安装我，请确保它与兼容主机一起使用。”我们称这种关系为对等依赖关系。

插件确实需要主机的特定版本。。。

peerDependencies适用于插件，即需要“主机”库来执行其功能的库，但可能是在主机的最新版本发布之前编写的。

也就是说，如果我为HostLibraryX v3编写PluginX v1并走开，那么无法保证在发布HostLibraryXv4（甚至HostLibraryX-v3.0.1）时PluginX v1会工作。

…但插件不依赖于主机。。。

从插件的角度来看，它只向宿主库添加函数。我并不真的“需要”主机为插件添加依赖项，而且插件通常并不真正依赖于主机。如果你没有主机，插件就不会做任何有害的事情。

这意味着依赖并不是插件的正确概念。

更糟糕的是，如果我的主机被视为一个依赖，我们最终会遇到同一篇博客文章提到的情况（编辑了一点以使用这个答案的虚构主机和插件）：

但是现在，[如果我们将当前版本的HostLibraryX视为PluginX的依赖项，]运行npm安装会导致意外的依赖关系图├── HostLibraryX@4.0.0└─┬ PluginX@1.0.0└── HostLibraryX@3.0.0我将把插件使用不同于主应用程序的[HostLibraryX]API而产生的细微故障留给你想象。

…而且主机显然不依赖于插件。。。

…这就是插件的全部意义。现在，如果主机足够好，能够包含所有插件的依赖信息，这将解决问题，但这也会引入一个巨大的新文化问题：插件管理！

插件的关键在于它们可以匿名配对。在一个完美的世界里，让主人管理它们会很整洁，但我们不会要求图书馆放猫。

如果我们不是等级依赖，也许我们是相互依赖的同龄人。。。

相反，我们有成为同龄人的概念。主机和插件都不在对方的依赖桶中。两者都位于依赖关系图的同一级别。

---

…但这不是一种自动的关系。<<<钱球！！！

如果我是PluginX v1，并且期望有HostLibraryX v3的对等（即，具有对等依赖关系），我会这么说。如果你已经自动升级到最新的HostLibraryX v4（请注意，这是版本4），并且安装了Plugin v1，你需要知道，对吗？

npm无法为我管理这种情况--

“嘿，我看到你在使用PluginX v1！我正在自动将HostLibraryX从v4降级到v3，kk？”

或

“嘿，我看到你在使用PluginX v1。这需要HostLibraryX v3，在上一次更新时，它已被遗忘。为了安全起见，我正在自动卸载插件v1！！1.

不怎么样，npm？！

所以npm没有。它会提醒您这种情况，并让您了解HostLibraryX v4是否适合插件v1。

---

Coda

插件中良好的peerDependency管理将使这一概念在实践中更加直观。从博客文章，再一次。。。

有一条建议：与常规依赖不同，对等依赖的要求应该宽松。您不应将对等依赖项锁定到特定的修补程序版本。如果一个Chai插件同行依赖Chai 1.4.1，而另一个依赖Chai 1.5.0，这真的很烦人，因为作者很懒，没有花时间找出他们所兼容的Chai的实际最低版本。

从属关系项目需要运行的依赖项，如提供从代码调用的函数的库。它们是以过渡方式安装的（如果A依赖于B依赖于C，则在A上安装npm将安装B和C）。示例：lodash：您的项目调用一些lodash函数。

devDependencies您只需要在开发或发布过程中使用的依赖项，例如将代码编译为javascript、测试框架或文档生成器的编译器。它们不是以过渡方式安装的（如果A依赖于B，则dev依赖于C，npm安装在A上将只安装B）。示例：grut：您的项目使用grut来构建自己。

对等依赖关系项目在父项目中挂钩或修改的依赖项，通常是其他库或工具的插件。这只是一个检查，确保父项目（将依赖于您的项目的项目）依赖于您所连接的项目。因此，如果你制作了一个插件C，将功能添加到库B中，那么制作项目a的人需要依赖于B，如果他们依赖于C。未安装它们（除非npm<3），只检查它们。示例：grut：您的项目为grut添加了功能，并且只能用于使用grut的项目。

本文档很好地解释了对等依赖关系：https://nodejs.org/en/blog/npm/peer-dependencies/

此外，随着时间的推移，npm文档得到了改进，现在对不同类型的依赖关系有了更好的解释：https://github.com/npm/cli/blob/latest/docs/content/configuring-npm/package-json.md#devdependencies

依赖项需要运行，devDependencies仅用于开发