npm: 依赖关系 vs devDependencies 捆绑依赖关系

Question

使用搜索，我已经找到了类似问题的一些很好的答案，但我仍然不确定我是否理解正确。

从这些答案中我了解到dependencies 是运行应用程序所必需的，而devDependencies 仅在开发时才需要（如单元测试）。

但是这样怎么样：我的应用程序依赖于 jQuery，但是在构建步骤期间（在我的 devDependencies 的帮助下），所有内容都捆绑到一个文件中。在这种情况下，我应该将 jQuery 列为dependency 还是devDependency？

为了让我的观点更清楚，采用这样的模块：

define(['jquery'], function($) {
  // use jQuery in this module
})

稍后，这个模块将被编译成类似application.build.js 的东西，然后包含这个模块和 jQuery 依赖项。

Answer 1

由于最终结果是一样的，这里似乎没有一个明确的规则，但我发现了一些关于这个问题的讨论：

如果您正在构建应用程序

https://github.com/webpack/webpack/issues/520

由 [insert build tool/bundler] 构建的浏览器应用程序没有运行时节点依赖项，因此所有前端依赖项都应列为 devDependencies。 dependencies vs devDependencies 命名约定在历史上源于节点作为服务器端包管理器（...）据我所知，在dependencies 下列出前端依赖项是无害的，但这是错误的。

(...) 作为对所有人的一般建议，将所有内容移至devDependencies，直到dependencies 下真正需要它为止。

如果您正在构建库：

https://github.com/inuitcss/inuitcss/issues/225

在许多前端项目中，所有提供给浏览器的代码都经过编译，没有运行时依赖项。这意味着没有dependencies，只有devDependencies——所有依赖项都包含在开发过程中完成的构建中。

也有人会争辩说，开发也需要依赖关系，因此可以列出 dependencies 下的所有内容。

我认为我们有可选的区别这一事实表明了使用它们的合理方式。 （对我来说）dependencies 名称将代表要使用的“最小可行”代码，并作为对某些东西的工作无关紧要的指标。

在我看来，任何成为生产代码一部分的东西都是dependency。

结语

就我个人而言，我更同意最后一句话。 dependencies 告诉我们应用程序代码需要运行什么，devDependencies开发人员需要什么来构建/部署/无论应用程序/库。

但需要注意的是，如果有人 npm installs 您的库在他们自己的应用程序中使用捆绑包作为模块，他们将下载大量他们实际上并不需要的 dependencies。