160

你如何比较npm，bower和volo？

这三个都可以用于为UI项目安装JavaScript依赖项。我了解npm是特定于节点的。

那么，什么时候使用什么呢？

npm依然屹立遥远，但bower并volo似乎正好解决同样的问题，虽然我不是能画之间的线路npm和bower-volo。

— 尤加尔·金德尔（Yugal Jindle）
source

stackoverflow.com/questions/18641899/…–

— Stefan

1

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

— gustavohenke

2

Bower可能很快就会合并到npm中。

— Dan Dascalescu 2015年

104

最能描述npm和bower区别的描述是：npm管理称为包的JavaScript模块，而Bower管理称为组件的前端组件（即css，html和JavaScript）。npm也用于安装凉亭。这是有关npm和bower（不涉及volo）的广泛文章，其中涉及很多细节。

— 怪圈
source

88

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

— BT

尽管我注意到npm上的一些“前端”库被废弃了，以支持它们的凉亭。以Ember为例，它一年没有出版。

— briangonzalez 2014年

4

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

— BT

2

考虑到bower没有处理html，css和javascript的政策，这是一个非常令人误解的答案。npm也没有任何政策，只是npm上的几乎所有内容都被编写为至少支持commonjs并偶尔支持其他格式。您可以像在bower中一样将html和css放在npm包中。npm上有许多仅用于前端的软件包，包括包含css和html的软件包。

— 子

3

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

— Eruant 2014年

72

凉亭

尽管它几乎没有功能，但在前端开发人员中仍然很受欢迎。每个前端程序包都在使用它。还有一项将凉亭合并到npm中的计划。

Bower针对客户端进行了优化，并且仅支持平面依赖树，即每个库只能使用一次（因为将同一库的不同版本发送给客户端非常昂贵），并且依赖关系约束必须由用户解决。

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

沃洛

我多年来仍未使用它超过5分钟。不知道，但是从我所看到的它确实包含一些构建工具，Grunt用户非常熟悉。

npm

是的，npm代表节点软件包管理器。但是如今，您可以将其用于所有内容；人们不再npm install只吃东西，并期望它们只能在Node环境中工作。例如，Twitter Bootstrap有许多npm软件包。

Npm通过嵌套的依赖关系树针对服务器端使用进行了优化。每个依赖项可以有自己的依赖项，可以有自己的依此类推。由于每个依赖项可以使用自己的Underscore版本，因此消除了依赖项版本冲突。但是，即将发布的npm版本3将展平依赖树：

使用npm @ 3，您的node_modules目录将变得更加讨人喜欢。您的所有依存关系和大多数子依存关系（和（子）+依存关系）将在顶层彼此相邻。只有在发生冲突时，才可以在更深层次上安装模块。对于Windows用户，这应该使事情变得容易得多。

我在使用npm时看到的一些优点：

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

npm是JavaScript的软件包管理器。

npmjs.com屏幕截图

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

npm

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

凉亭

Bower现在是流行歌手。他们有很多项目在进行中，项目维护者喜欢在Bower Registry中保持最新状态...

可惜他有时有点马车。

沃洛

从那以后，我没有尝试过5分钟以上的volo，但是从我的角度看，它看上去比凉亭更灵活。

Volo的不利之处在于他们的项目已经过时了。

— 古斯塔沃亨克
source

19

npm上有成千上万的模块，它们只能在浏览器中使用，或者在节点和浏览器中都可以使用。他们中的许多人甚至都带有ci徽章，可以准确告诉您使用的浏览器。bower et all上的大多数内容都可能在npm上。

— 2013年

我不理解需要ngBoilerplate之类的项目来使用Bower，而它的安装已经取决于npm了

— lolski 2013年

5

什么是“流行男”？是“流行”的缩写。为“受欢迎”？

— 布莱恩·奥克利

4

在您的屏幕快照中，npm代表核计划手册；）

— Jim Jones，

24

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

事实是，您还可以使用NPM来管理浏览器的javascript和CSS。没有什么可以阻止您这样做。从这个意义上讲，使用NPM对我而言比必须为同一目的管理两个不同的工具更为自然。

看来凉亭有更多可用的软件包，至少对于更流行的软件包而言。但是很快jQuery也将直接在NPM中可用，可能所有其他库都将遵循相同的趋势。

在我看来，因为有一样的工具browserify和webmake在那里，在浏览器的帮助使用节点模块，没有了一个真正的需要凉亭或VOLO，除非他们提供的东西别人为你（一个特定的模块只存在于他们的注册表）。

无论瓦罗和鲍尔都很好，但是从我的角度来看，如果您已经在使用NPM，则最好坚持使用它。

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

— 罗伊·里奥哈斯
source

1

对于相同的问题，拥有竞争解决方案是件好事。知道为什么yeoman项目已经选择时，为什么选择了新的软件包管理器npm？（这是成熟的，着名的和功能丰富的）这个想法使我感到我仍然缺少实际要点。

— Yugal Jindle

1

并非如此，但是正如您所说，重塑轮子很有趣，只是因为您可以做到，有时通过这样做，在尝试解决相同问题的同时也做了一些改进。除了让前端开发人员更容易找到软件包之外，他们不是真的为什么选择选择新软件包。并非所有前端开发人员都有节点经验，我想这是Bower这样项目背后的主要原因。尝试使非节点用户更容易使用，我只是在这里猜测。

— 罗伊·里奥哈斯（Roy riojas）2013年

我想他们想分开麻烦，npm而赞成前端简单。因此用于前端开发。

— Yugal Jindle

15

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

上面的结果是，Bower软件包的维护者和消费者必须更加谨慎地维护其依赖版本号以避免冲突，但这是值得付出的代价。而且我发现NPM模块在发行主要版本，次要版本和修补程序版本时通常都很草率，因此NPM依赖性管理也不是一件容易的事。

— 哪里
source

3

仅当您直接从程序包管理器放置这些文件的文件夹中提供前端代码时，这才是正确的。就我而言，我要么具有构建脚本来处理less / js文件，要么就通过browserify从这些文件创建捆绑包。因此，就我而言，这并不是一个大问题。所分发的代码始终具有正确的版本，即使其他子组件在开发过程中可能有重复项却从未投入生产时也是如此。

— 罗伊·里奥哈斯（Roy riojas）2014年

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

— wheresrhys 2014年

我通常不需要我不控制的模块，因此它们将始终是正确的模块...如果不经意间一个模块试图从填充的模块中请求给定的模块，构建将失败。在我看来，使用凉亭没有任何意义，也没有增加任何好处

— Roy riojas 2014年

因此，只有在可以控制整个依赖关系树的情况下，才能安全地说npm避免在客户端代码中重复模块。对于我从事的绝大多数工作而言，肯定不是这种情况，对于大多数使用依赖项管理器来包含客户端模块的项目而言，可能并非如此。

— wheresrhys 2014年

1

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

— 罗伊·里奥哈斯（Roy riojas）2014年

5

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

jam compile output.js

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

— 布鲁斯·林（Bruce Lim）
source

5

您的愿望已实现：github.com/rlidwka/yapm：P

— alex

1

好吧，我当时在考虑使用浏览器端的依赖管理器，但是我猜这两者都可行：p这就是为什么我不能做启动，我所有的想法都已经想到了。

— Bruce Lim 2014年

@BruceLim是的，每当我们认为自己有一个好主意时，总会有其他人知道它。

— 伊万·胡

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

凉亭

沃洛

npm

npm

凉亭

沃洛