JavaScript 依赖管理：npm vs. bower vs.volo [关闭]

Posted 2023-02-22

【中文标题】JavaScript 依赖管理：npm vs. bower vs.volo [关闭]

【英文标题】：JavaScript dependency management: npm vs. bower vs. volo [closed]

【发布时间】：2013-02-12 02:16:07

【问题描述】：

你如何比较npm、bower和volo？

这三个都可用于为 UI 项目安装 javascript 依赖项。 我知道npm 更具体。

那么，什么时候用什么？

npm 仍然遥遥无期，但 bower 和 volo 似乎正在解决完全相同的问题，尽管我无法在 npm 和 bower-volo 之间划清界限。

【问题讨论】：

***.com/questions/18641899/…

如果您在这里阅读此问题并希望获得 2015 年的答案，请参阅我的更新答案。

Bower might be merged into npm 很快。

【参考方案1】：

最能描述 npm 和 bower 之间区别的描述是：npm 管理称为包的 JavaScript 模块，而 Bower 管理称为组件的前端组件（即 css、html 和 JavaScript）。 npm 也用于安装 bower。这是一个expansive article on npm and bower（不包括volo），它涉及很多细节。

【讨论】：

这不是一个很好的描述。 npm当然可以用来安装前端组件。

虽然我注意到 npm 上的一些“前端”库被弃用，取而代之的是它们的凉亭同行。以Ember 为例，一年未发布。

@Nate 这个名字就是它开始的地方。 NPM 现在是一个非常通用的包管理系统。我经常使用 npm 安装前端模块。将 NPM 用于 commonjs 模块、amd 和其他任何东西没有区别。您也可以将 npm 用于非 javascript 模块。因此，这根本不是 npm 和 bower 之间的区别。无论您称它们为包还是组件，它们都是相同的，因为它们都是任意文件的集合。

考虑到 bower 没有处理 html、css 和 javascript 的政策，这是一个非常具有误导性的答案。 npm 也没有任何政策，除了 npm 上的几乎所有内容都至少支持 commonjs 和偶尔的其他格式。您可以像使用 bower 一样将 html 和 css 放入 npm 包中。 npm 上有许多仅前端的包，包括包含 css 和 html 的包。

如果你使用browserify，npm 是完美的包管理器。我认为您使用哪个包管理器并不重要，但我个人会坚持每个项目只使用一个。

【参考方案2】：

凉亭

它在前端开发人员中仍然很受欢迎，尽管它的功能很少。每个前端包都在使用它。还有一个initiative to merge bower into npm。

Bower 针对客户端进行了优化，仅支持平面依赖树，即each library must be used only once（因为将同一库的不同版本发送到客户端很昂贵），并且依赖约束必须由用户解决。

您可以期望在 bower 注册表 (bower search <some keyword>) 中找到任何与前端相关的内容——在我看来，这是 bower 相对于其他包管理器的最大优势。

volo

多年来，我仍然没有使用超过 5 分钟。不知道，but from what I can see 确实包含了一些构建工具，对于 Grunt 用户来说是非常熟悉的。

npm

是的，npm 代表节点包管理器。但是现在你可以用它来做任何事情。人们不再只是npm installing 事物并期望它们仅在 Node 环境中工作。比如有很多npm packages for Twitter Bootstrap。

Npm 针对服务器端使用进行了优化，具有嵌套的依赖树。每个依赖项都可以有自己的依赖项，这些依赖项可以有自己的依赖项，依此类推。这消除了依赖版本冲突，因为每个依赖都可以使用它们自己的版本，例如下划线。不过，即将到来的npm version 3 will flatten the dependency tree：

使用 npm@3，您的 node_modules 目录将更加平坦。您的所有依赖项和大多数子依赖项（和（子）+依赖项）将在顶层彼此相邻。只有当存在冲突时，才会安装更深层次的模块。对于 Windows 用户来说，这应该会让事情变得更容易。

我看到使用 npm 的一些优势：

它被所有其他包管理器（组件、bower、volo、JSPM 等）使用； 允许使用构建脚本； 有很多工具可用于自省基于 npm 的包

npm 是 JavaScript 的包管理器。

---

截至 2013 年 2 月，我的看法如下。 请不要再考虑了。

npm

当您使用 Node 项目时，最好坚持使用它，浏览器也可以使用的项目很少......

凉亭

Bower 现在是流行音乐人。他们有很多项目，项目维护者喜欢在凉亭注册表中保持它们的最新状态......

很遗憾，他有时有点马车。

volo

从那以后我已经有超过 5 分钟没有尝试过 volo，但据我所知，它看起来比 bower 更灵活。

volo 的缺点是他们的项目非常过时。

【讨论】：

npm 上有数以千计的模块，它们要么只在浏览器中工作，要么在节点和浏览器中都工作。他们中的许多人甚至有 ci 徽章，可以准确地告诉你他们在哪些浏览器中工作。bower et all 上的大多数东西都可能在 npm 上。

我不明白像 ngBoilerplate 这样的项目需要使用 bower，而它已经依赖 npm 进行安装

什么是“流行音乐人”？ “流行”是一个缩写。为“流行”？

在你的截图中，npm 代表核计划手册；）

【参考方案3】：

他们似乎在解决相同的问题，但针对不同的环境/世界。用于 nodejs 和 Volo 的 NPM，用于浏览器的 bower。

事实上，您也可以使用 NPM 来管理浏览器的 javascript 和 css。没有什么能阻止你这样做。从这个意义上说，我觉得使用 NPM 比为同一目的管理两个不同的工具更自然。

似乎 bower 有更多可用的包，至少对于更受欢迎的包来说是这样。但很快jQuery will be also be available in NPM directly 可能所有其他库都会遵循同样的趋势。

在我看来，由于有像 browserify 和 webmake 这样的工具可以帮助在浏览器中使用节点模块，因此不再有bower 或 volo 的真正需求，除非他们为您提供其他东西（仅存在于他们的注册表中的特定模块）。

Volo 和 Bower 都不错，但在我看来，如果你已经在使用 NPM，最好还是坚持下去。

请注意，即使不使用 browserify 或 webmake，您也可以使用 NPM 来管理您的客户端依赖项。在我从事的大多数项目中，安装 npm 模块后，我运行一个脚本将它们部署到我的客户端应用程序使用它们的位置。有时我使用 grunt 将该文件与其他 js 文件连接起来，有时我直接从我的 Web 应用程序的模板文件中引用它。无论如何，这是个人喜好。其他人会发现 Bower 或 Volo 更易于使用，因为它们更自然地融入他们的工作流程。

【讨论】：

对于同一个问题有相互竞争的解决方案是件好事。知道为什么 yeoman 项目在我们已经拥有 npm 时选择提出一个新的包管理器吗？ （它成熟、有名且功能丰富）这个想法让我觉得我仍然没有抓住实际意义。

不是真的，但正如你所说，重新发明***有时很有趣，只是因为你可以，有时通过这样做，在尝试解决相同问题时会做出一些改进。除了让前端开发人员更容易找到包之外，这并不是他们选择制作新包的真正原因。并非所有前端开发人员都有节点经验，我想这是 Bower 等项目背后的主要原因。尽量让非节点用户更容易，我只是在这里猜测。

我猜他们想将npm 的麻烦分开，以支持前端的简单性。因此用于前端开发。

【参考方案4】：

Bower 相对于 NPM 的最大优势在于它的依赖管理强制使用单个版本的组件（而 NPM 通过将不同的副本/版本作为不同模块的子依赖来工作）。这是一件非常好的事情，因为它可以防止您的客户端 javascript 因需要包含不同版本的组件的多个副本而变得臃肿。包含一个模块的多个副本是 NPM 依赖管理工作方式的核心，因此 NPM 完全不适合客户端包管理。

上述的结果是 Bower 包维护者和消费者必须更加注意维护他们的依赖版本号以避免冲突，但这是值得付出的代价。而且我发现 NPM 模块在发布主要、次要和补丁版本时经常马虎，所以 NPM 依赖管理也不是完美的。

【讨论】：

仅当您直接从包管理器放置这些文件的文件夹中提供前端代码时才适用。在我的情况下，我要么有构建脚本来处理 less/js 文件，要么使用 browserify 来从这些文件中创建一个包。所以在我的情况下，这并不是一个大问题。分发的代码总是有正确的版本，即使其他子组件在开发过程中可能有重复，它们永远不会投入生产。

即使您无意中需要（作为子依赖项）同一依赖项的两个不同版本？我认为在这种情况下你错了

我通常不需要我无法控制的模块，所以它们总是正确的......失败。在我的情况下使用凉亭没有任何好处

因此，如果您可以控制整个依赖关系树，则只能说 npm 可以避免在客户端代码中重复模块。我从事的绝大多数事情当然不是这种情况，而且对于大多数使用依赖管理器来包含客户端模块的项目来说可能不是这样。

除非您正在处理混搭，否则您的依赖关系树不会那么复杂，至少对于第三方代码而言。大多数 js 库都导出单个全局，因此使用 browserify-shim 可以确保可以在全局范围内使用它们，因此始终是您可以控制的版本。我的观点是，您可以在不需要另一个包管理器的情况下实现相同的目标。最后可能是偏好问题。总要做出妥协。

【参考方案5】：

我知道这不在问题的范围内，但还有另一种选择。 Jam JS - http://jamjs.org/ 有趣的是它在 jam 中具有 grunt 功能：

jam compile output.js

应该有人再做一个包管理器并将其命名为：yapm :)

【讨论】：

你的愿望已经实现：github.com/rlidwka/yapm:P

好吧，我在考虑浏览器端依赖管理器，但我想这对两者都适用：p 这就是为什么我不能做初创公司，我所有的想法都已经考虑过了。

@BruceLim 是的，每当我们认为我们有一个好主意时，总会有其他人已经得到它。