npm：依赖关系vs devDependencies与捆绑的依赖关系

Question

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

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

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

为了使我的观点更清楚，请使用以下模块：

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

稍后，这个模块将编译成类似qazxsw poi的东西，然后包含这个模块和jQuery依赖项。

Answer 1

由于最终结果是相同的，这里似乎没有明确的规则，但我在这个问题上找到了几个讨论：

If you're building an application

application.build.js

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

（...）作为每个人的一般建议，将所有内容移动到dependencies，直到devDependencies实际需要它为止。

If you're building a library:

dependencies

在许多前端项目中，所有提供给浏览器的代码都被编译，没有运行时依赖项。这意味着没有https://github.com/inuitcss/inuitcss/issues/225，只有dependencies - 所有依赖项都包含在开发期间完成的构建中。

人们也可以争辩说开发也需要依赖关系，所以可以列出所有的devDependencies。

我认为我们具有可选区别的事实表明了使用它们的合理方式。 （对我来说）dependencies指定代表“使用的最小可行”代码以及作为某些东西不起作用的指标是有意义的。

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

Epilogue

就个人而言，我同意最后一句话。有意义的是dependency告诉我们应用程序代码需要运行什么，以及dependencies开发人员需要构建/部署什么/应用程序/库。

但有一点需要注意的是，如果有人在你的库中使用捆绑包作为模块在他们自己的应用程序中，他们会下载很多他们实际上不需要的devDependencies。