重要行为差异摘要：

• dependencies 都安装在两个上：

  • npm install 从包含以下内容的目录中 package.json
  • npm install $package 在任何其他目录上

  • devDependencies 是：

  • 也安装在npm install包含的目录上package.json，除非您通过该--production标志（继续投票给Gayan Charith’s answer）。

  • 没有安装在npm install "$package"任何其他目录上，除非您给它--dev选择。
  • 不能临时安装。

  • peerDependencies：

  • 3.0之前的版本：如果缺少，总是安装；如果不同的依赖项使用多个不兼容的依赖项版本，则会引发错误。

  • 预期从3.0开始（未试用）：如果缺少npm install，则发出警告，您必须手动解决依赖关系。运行时，如果缺少依赖项，则会出现错误（@nextgentech提到）

  • 可传递性（由Ben Hutchison提及）

  • dependencies 是通过传递安装的：如果A需要B，而B需要C，则C将被安装，否则B无法工作，A也将无法工作。

  • devDependencies没有过渡安装。例如，我们不需要测试B就可以测试A，因此可以省去B的测试依赖项。

此处未讨论的相关选项：

• bundledDependencies在以下问题上对此进行了讨论：bundledDependencies相对于NPM中常规依赖项的优势
• optionalDependencies（由艾丹·费尔德曼Aidan Feldman提到）

devDependencies

dependencies只需要运行就devDependencies可以进行开发，例如：单元测试，CoffeeScript到JavaScript的代码转换，缩小，…

如果要开发软件包，请下载该软件包（例如通过git clone），转到包含的根目录package.json并运行：

npm install

由于您拥有实际的源代码，因此很显然要开发它，因此默认情况下，dependencies（当然，必须运行以进行开发）和devDependency依赖项都已安装。

但是，如果您只是希望安装软件包以使用它的最终用户，则可以从任何目录进行操作：

npm install "$package"

在这种情况下，你通常不希望发展的依赖，所以你只能使用包所需要的：dependencies。

如果您确实想在这种情况下安装开发包，则可以将dev配置选项设置为true，可能从命令行将其设置为：

npm install "$package" --dev

false默认情况下，此选项是默认情况，因为这种情况不太常见。

peerDependencies

（在3.0之前测试）

资料来源：https :
//nodejs.org/en/blog/npm/peer-
dependencies/

使用常规依赖项，您可以具有多个版本的依赖项：只需将其安装在node_modules依赖项中即可。

例如，如果dependency1和dependency2都依赖于dependency3在不同版本的项目树的样子：

root/node_modules/
                 |
                 +- dependency1/node_modules/
                 |                          |
                 |                          +- dependency3 v1.0/
                 |
                 |
                 +- dependency2/node_modules/
                                            |
                                            +- dependency3 v2.0/

但是，插件是通常不需要其他软件包的软件包，在此上下文中称为 主机 。代替：

• 主机 需要插件 __
• 插件提供了主机希望找到的标准接口
• 用户只能直接调用主机，因此必须有一个单独的版本。

例如，如果dependency1和dependency2peer依赖dependency3，项目树将如下所示：

root/node_modules/
                 |
                 +- dependency1/
                 |
                 +- dependency2/
                 |
                 +- dependency3 v1.0/

即使您从未dependency3在package.json文件中提及，也会发生这种情况。

我认为这是控制反转设计模式的一个实例。

对等依赖关系的一个典型示例是Grunt，主机及其插件。

例如，在https://github.com/gruntjs/grunt-contrib-
uglify之类的Grunt插件上，您将看到：

• grunt 是一个 peer-dependency
• 唯一的问题require('grunt')是tests/：该程序实际上并未使用它。

然后，当用户使用插件时，他将Gruntfile通过添加grunt.loadNpmTasks('grunt-contrib- uglify')一行来隐式要求插件来自插件，但这grunt是用户将直接调用它。

如果每个插件都需要不同的Grunt版本，则无法使用。

手册

我认为文档很好地回答了这个问题，也许您对节点/其他包管理器还不够熟悉。我可能只了解它，因为我对Ruby捆绑器有所了解。

关键是：

这些东西将在从软件包根目录执行npm link或npm
install时安装，并且可以像任何其他npm配置参数一样进行管理。有关该主题的更多信息，请参见npm-config（7）。

然后在npm-config（7）下找到dev：

Default: false
Type: Boolean

Install dev-dependencies along with packages.