npm:依赖关系vs devDependencies与捆绑的依赖关系
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了npm:依赖关系vs devDependencies与捆绑的依赖关系相关的知识,希望对你有一定的参考价值。
使用搜索我已经找到了类似问题的一些很好的答案,但我仍然不确定我是否正确理解它。
从这些答案中我了解到dependencies
需要运行应用程序,而devDependencies
只在开发时需要(如单元测试)。
但是这个怎么样:我的应用程序依赖于jQuery,但在构建步骤期间(在我的devDependencies
的帮助下),所有内容都捆绑在一个文件中。在这种情况下,我应该将jQuery列为dependency
或devDependency
?
为了使我的观点更清楚,请使用以下模块:
define(['jquery'], function($) {
// use jQuery in this module
})
稍后,这个模块将编译成类似qazxsw poi的东西,然后包含这个模块和jQuery依赖项。
由于最终结果是相同的,这里似乎没有明确的规则,但我在这个问题上找到了几个讨论:
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
。
以上是关于npm:依赖关系vs devDependencies与捆绑的依赖关系的主要内容,如果未能解决你的问题,请参考以下文章
Visual Studio 2013 中的 MSM 合并模块:未检测到依赖关系