node.js npm package.json 文件中的依赖项、devDependencies 和 peerDependencies 之间有什么区别？

What's the difference between dependencies, devDependencies and peerDependencies in npm package.json file?

提问by Vitalii Korsakov

This documentationanswers my question very poorly. I didn't understand those explanations. Can someone say in simpler words? Maybe with examples if it's hard to choose simple words?

该文档非常糟糕地回答了我的问题。我不明白这些解释。有人可以用简单的词来说吗？如果很难选择简单的单词，也许可以举个例子？

EDITalso added peerDependencies, which is closely related and might cause confusion.

编辑还添加了peerDependencies，这是密切相关的，可能会引起混淆。

回答by Gayan Charith

If you do not want to install devDependencies you can use npm install --production

如果您不想安装 devDependencies，您可以使用 npm install --production

回答by Dan Kohn

As an example, mocha would normally be a devDependency, since testing isn't necessary in production, while express would be a dependency.

例如，mocha 通常是一个 devDependency，因为在生产中不需要测试，而 express 是一个依赖项。

回答by qwertzguy

dependencies
Dependencies that your project needs to run, like a library that provides functions that you call from your code.
They are installed transitively (if A depends on B depends on C, npm install on A will install B and C).
Example: lodash: your project calls some lodash functions.

依赖
依赖你的项目需要跑，这样提供的功能，你从你的代码中调用的库。
它们是传递性安装的（如果 A 依赖 B 依赖 C，则 npm install on A 将安装 B 和 C）。
示例：lodash：您的项目调用了一些 lodash 函数。

devDependencies
Dependencies you only need during development or releasing, like compilers that take your code and compile it into javascript, test frameworks or documentation generators.
They are not installed transitively (if A depends on B dev-depends on C, npm install on A will install B only).
Example: grunt: your project uses grunt to build itself.

devDependencies
仅在开发或发布期间需要的依赖项，例如将您的代码编译为 javascript、测试框架或文档生成器的编译器。
它们不是可传递安装的（如果 A 依赖于 B dev-depends on C，则 npm install on A 将仅安装 B）。
示例： grunt：您的项目使用 grunt 构建自身。

peerDependencies
Dependencies that your project hooks into, or modifies, in the parent project, usually a plugin for some other library or tool. It is just intended to be a check, making sure that the parent project (project that will depend on your project) has a dependency on the project you hook into. So if you make a plugin C that adds functionality to library B, then someone making a project A will need to have a dependency on B if they have a dependency on C.
They are not installed (unless npm < 3), they are only checked for.
Example: grunt: your project adds functionality to grunt and can only be used on projects that use grunt.

peerDependencies
您的项目在父项目中挂钩或修改的依赖项，通常是其他库或工具的插件。它只是为了检查，确保父项目（将依赖于您的项目的项目）依赖于您挂钩的项目。因此，如果您制作了一个向库 B 添加功能的插件 C，那么制作项目 A 的人如果依赖于 C，则需要依赖于 B。
它们没有安装（除非 npm < 3），它们只是检查了。
示例：grunt：您的项目为 grunt 添加了功能，并且只能用于使用 grunt 的项目。

This documentation explains peer dependencies really well: https://nodejs.org/en/blog/npm/peer-dependencies/

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

Also, the npm documentation has been improved over time, and now has better explanations of the different types of dependencies: https://github.com/npm/cli/blob/latest/doc/files/package.json.md#devdependencies

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

回答by Mohammed Safeer

To save a package to package.jsonas dev dependencies:

要将包保存到package.json作为开发依赖项：

npm install "$package" --save-dev

When you run npm installit will install both devDependenciesand dependencies. To avoid install devDependenciesrun:

当您运行时npm install，它将同时安装devDependencies和dependencies. 为避免安装devDependencies运行：

npm install --production

回答by Amberlamps

There are some modules and packages only necessary for development, which are not needed in production. Like it says it in the documentation:

有一些模块和包只需要开发，在生产中不需要。就像它在文档中所说的那样：

If someone is planning on downloading and using your module in their program, then they probably don't want or need to download and build the external test or documentation framework that you use. In this case, it's best to list these additional items in a devDependencies hash.

如果有人计划在他们的程序中下载和使用您的模块，那么他们可能不想或不需要下载和构建您使用的外部测试或文档框架。在这种情况下，最好在 devDependencies 哈希中列出这些附加项。

回答by Jyoti Duhan

A simple explanation that made it more clear to me is:

一个让我更清楚的简单解释是：

When you deploy your app, modules in dependencies need to be installed or your app won't work. Modules in devDependencies don't need to be installed on the production server since you're not developing on that machine. link

部署应用程序时，需要安装依赖项中的模块，否则应用程序将无法运行。devDependencies 中的模块不需要安装在生产服务器上，因为您不是在该机器上开发。 关联

回答by S?rbu Nicolae-Cezar

I'd like to add to the answer my view on these dependencies explanations

我想在答案中添加我对这些依赖项解释的看法

• dependenciesare used for direct usage in your codebase, things that usually end up in the production code, or chunks of code
• devDependenciesare used for the build process, tools that help you manage how the end code will end up, third party test modules, (ex. webpack stuff)

• dependencies用于在您的代码库中直接使用，通常最终出现在生产代码中的东西，或代码块
• devDependencies用于构建过程，帮助您管理最终代码如何结束的工具，第三方测试模块，（例如 webpack 的东西）

回答by cherankrish

In short

简而言之

1. Dependencies- npm install <package> --save-prodinstalls packages required by your application in production environment.

2. DevDependencies- npm install <package> --save-devinstalls packages required only for local development and testing

3. Just typing npm installinstalls all packages mentioned in the package.json

1. 依赖项- npm install <package> --save-prod在生产环境中安装应用程序所需的包。

2. DevDependencies- npm install <package> --save-dev安装仅本地开发和测试所需的包

3. 只需键入即可npm install安装 package.json 中提到的所有软件包

so if you are working on your local computer just type npm installand continue :)

因此，如果您在本地计算机上工作，只需键入npm install并继续:)

回答by ruffin

peerDependenciesdidn't quite make sense for me until I read this snippet from a blog poston the topic Ciro mentioned above:

peerDependencies直到我从上面提到的关于Ciro主题的博客文章中阅读了这个片段，才对我来说很有意义：

What [plugins] need is a way of expressing these “dependencies” between plugins and their host package. Some way of saying, “I only work when plugged in to version 1.2.x of my host package, so if you install me, be sure that it's alongside a compatible host.” We call this relationship a peer dependency.

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

The plugin does expecta specific version of the host...

该插件不期望主机的特定版本...

peerDependenciesare for plugins, libraries that require a "host" library to perform their function, but may have been written at a time beforethe latest version of the host was released.

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

That is, if I write PluginX v1for HostLibraryX v3and walk away, there's no guarantee PluginX v1will work when HostLibraryX v4(or even HostLibraryX v3.0.1) is released.

也就是说，如果我PluginX v1为之写作HostLibraryX v3并离开，则无法保证PluginX v1在HostLibraryX v4（甚至HostLibraryX v3.0.1）发布时会起作用。

... but the plugin doesn't dependon the host...

...但插件不依赖于主机...

From the point of view of the plugin, it only addsfunctions to the host library. I don't really "need" the host to add a dependency to a plugin, and plugins often don't literally dependon their host. If you don't have the host, the plugin harmlessly does nothing.

从插件的角度来看，它只是给宿主库增加了功能。我并不真的“需要”主机向插件添加依赖项，而且插件通常并不真正依赖于它们的主机。如果您没有主机，则该插件无害地执行任何操作。

This means dependenciesisn't really the right concept for plugins.

这意味着dependencies插件并不是真正正确的概念。

Even worse, if my host was treated like a dependency, we'd end up in this situation that the same blog post mentions(edited a little to use this answer's made up host & plugin):

更糟糕的是，如果我的主机被视为依赖项，我们最终会遇到同一篇博客文章提到的这种情况（稍微编辑以使用此答案由主机和插件组成）：

But now, [if we treat the contemporary version of HostLibraryX as a dependency for PluginX,] running npm installresults in the unexpected dependency graph of

├── [email protected]
└─┬ [email protected]
  └── [email protected]

I'll leave the subtle failures that come from the plugin using a different [HostLibraryX] API than the main application to your imagination.

但是现在，[如果我们将 HostLibraryX 的当代版本视为 PluginX 的依赖项，] 运行会npm install导致意外的依赖关系图

├── [email protected]
└─┬ [email protected]
  └── [email protected]

我将使用与主应用程序不同的 [HostLibraryX] API 的插件带来的细微故障留给您想象。

... and the host obviously doesn't depend on the plugin...

...而主机显然不依赖于插件...

... that's the whole point of plugins. Now if the host was nice enough to include dependency information for allof its plugins, that'd solve the problem, but that'd also introduce a huge new cultural problem: plugin management!

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

The whole point of plugins is that they can pair up anonymously. In a perfect world, having the host manage 'em all would be neat & tidy, but we're not going to require libraries herd cats.

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

If we're not hierarchically dependent, maybe we're intradependent peers...

如果我们不是等级依赖的，也许我们是内部依赖的同龄人......

Instead, we have the concept of being peers. Neither host nor plugin sits in the other's dependency bucket. Both live at the same level of the dependency graph.

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

---

---

... but this is not an automatable relationship. <<< Moneyball!!!

...但这不是一种可自动化的关系。<<<点球大战！！！

If I'm PluginX v1and expecta peer of (that is, have a peerDependency of) HostLibraryX v3, I'll say so. If you've auto-upgraded to the latest HostLibraryX v4(note that's version 4) ANDhave Plugin v1installed, you need to know, right?

如果我PluginX v1和期望的对等（也就是，有一个peerDependency）HostLibraryX v3，我会这么说。如果您已自动升级到最新HostLibraryX v4版本（注意是版本4）并已Plugin v1安装，您需要知道，对吗？

npmcan't manage this situation for me --

npm无法为我处理这种情况——

"Hey, I see you're using PluginX v1! I'm automatically downgrading HostLibraryXfrom v4 to v3, kk?"

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

... or...

... 或者...

"Hey I see you're using PluginX v1. That expects HostLibraryX v3, which you've left in the dust during your last update. To be safe, I'm automatically uninstalling Plugin v1!!1!

“嘿，我看到你正在使用PluginX v1。那是期待HostLibraryX v3，你在上次更新期间把它留在了尘土中。为了安全起见，我会自动卸载Plugin v1!!1！

How about no, npm?!

不怎么样，npm？！

So npm doesn't. It alerts you to the situation, and lets you figure out if HostLibraryX v4is a suitable peer for Plugin v1.

所以 npm 没有。它会提醒您注意这种情况，并让您确定是否HostLibraryX v4适合Plugin v1.

---

---

Coda

结尾

Good peerDependencymanagement in plugins will make this concept work more intuitively in practice. From the blog post, yet again...

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

One piece of advice: peer dependency requirements, unlike those for regular dependencies, should be lenient. You should not lock your peer dependencies down to specific patch versions. It would be really annoying if one Chai plugin peer-depended on Chai 1.4.1, while another depended on Chai 1.5.0, simply because the authors were lazy and didn't spend the time figuring out the actual minimum version of Chai they are compatible with.

一条建议：与常规依赖项不同，对等依赖项要求应该是宽松的。您不应该将您的对等依赖项锁定到特定的补丁版本。如果一个 Chai 插件对等依赖于 Chai 1.4.1，而另一个依赖于 Chai 1.5.0，那将真的很烦人，仅仅是因为作者懒惰，没有花时间弄清楚他们实际使用的 Chai 的最低版本兼容。

回答by Selva Ganapathi

Dependencies vs dev dependencies

依赖与开发依赖

Dev dependencies are modules which are only required during development whereas dependencies are required at runtime. If you are deploying your application, dependencies has to be installed, or else your app simply will not work. Libraries that you call from your code that enables the program to run can be considered as dependencies.

开发依赖项是仅在开发期间需要的模块，而在运行时需要依赖项。如果您正在部署应用程序，则必须安装依赖项，否则您的应用程序将无法运行。您从使程序运行的代码中调用的库可以被视为依赖项。

Eg- React , React - dom

例如-反应，反应-dom

Dev dependency modules need not be installed in the production server since you are not gonna develop in that machine .compilers that covert your code to javascript , test frameworks and document generators can be considered as dev-dependencies since they are only required during development .

开发依赖模块不需要安装在生产服务器中，因为你不会在那台机器上开发。将代码转换为 javascript 的编译器，测试框架和文档生成器可以被视为开发依赖，因为它们只在开发过程中需要。

Eg- ESLint , Babel , webpack

例如- ESLint , Babel , webpack

@FYI,

@供参考，

mod-a
  dev-dependents:
    - mod-b
  dependents:
    - mod-c

mod-d
?  dev-dependents:
    - mod-e
  dependents:
    - mod-a

----

npm install mod-d

installed modules:
  - mod-d
  - mod-a
  - mod-c

----

checkout the mod-d code repository

npm install

installed modules:
  - mod-a
  - mod-c
  - mod-e

If you are publishing to npm, then it is important that you use the correct flag for the correct modules. If it is something that your npm module needs to function, then use the "--save" flag to save the module as a dependency. If it is something that your module doesn't need to function but it is needed for testing, then use the "--save-dev" flag.

如果您要发布到 npm，那么为正确的模块使用正确的标志很重要。如果它是你的 npm 模块需要运行的东西，那么使用“--save”标志将模块保存为依赖项。如果您的模块不需要运行但测试需要它，请使用“--save-dev”标志。

# For dependent modules
?npm install dependent-module --save

?# For dev-dependent modules
np?m install development-module --save-dev