你如何比较npm、bower和volo？

这三者都可以用于为UI项目安装JavaScript依赖项。我知道npm是更具体的节点。

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

npm仍然很遥远，但bower和volo似乎解决了完全相同的问题，尽管我无法在npm和bower-volo之间划一条线。

最能描述NPM和Bower之间区别的描述是：NPM管理称为packages的javascript模块，Bower管理称为components的前端组件(即css、html和javascript)。NPM也用于安装凉亭。这里有一篇关于NPM和Bower(不包括Volo)的扩展文章，它涉及很多细节。

它在前端开发人员中仍然非常流行，尽管它的特性非常少。每个前端包都在使用它。也有一项计划将鲍尔合并为新产品管理公司。

Bower针对客户端进行了优化，只支持扁平的依赖树，即每个库只能使用一次(因为将同一库的不同版本发送给客户端的成本很高)，依赖约束必须由用户解决。

你可以期望在鲍尔登记处(bower search )找到任何与前端相关的东西——在我看来，这是鲍尔与其他套餐经理相比的最大优势。

几年来我还没有用过5分钟。不知道，但从我所看到的，它确实包含了一些构建工具，这对于咕噜的用户来说是非常熟悉的。

是的，NPM代表节点包管理器。但是现在你可以把它用在任何事情上；人们不再仅仅是npm install事物，而是期望它们只在节点环境中工作。例如，Twitter引导程序有许多NPM包。

NPM针对服务器端的使用进行了优化，使用了嵌套的依赖树。每个依赖可以有自己的依赖，也可以有自己的依赖，等等。这消除了依赖项版本冲突，因为每个依赖项都可以使用自己的版本，例如下划线。然而，即将到来的NPM版本3将扁平化依赖树：

With npm@3, your node_modules directory will be a lot flatter. All of your dependencies and most of your subdependencies (and (sub)+dependencies) will be sitting next to each other at the top level. Only when there are conflicts will modules be installed at deeper levels. This should make things a lot easier for Windows users.

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

• 它被所有其他包管理器(component、bower、volo、jspm等)使用；
• 允许使用生成脚本；
• 许多工具可用于反省基于NPM的包

NPM是JavaScript的包管理器。

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

当你处理一个节点项目时，最好坚持使用它，浏览器也可以使用的项目很少……

鲍尔现在是流行音乐人。他们有很多项目在他们的工作范围内，项目维护者喜欢保持他们在鲍尔登记处的最新信息…

他有时有点手推车，真可惜。

从那以后，我已经5分钟没有试过田鼠了，但据我所见，它看起来比鲍尔更灵活。

Volo的一个缺点是他们的项目非常过时。

他们似乎解决了同一个问题，但适用于不同的环境/世界。Nodejs和Volo的NPM，浏览器的Bower。

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

看来鲍尔有更多的套餐，至少对于更受欢迎的套餐。但很快jquery也将直接在npm中提供，并且可能所有其他库都将遵循相同的趋势。

在我看来，由于浏览器中有诸如browserify和webmake这样的工具可以帮助使用节点模块，所以对bower或volo不再有真正的需求，除非它们为您提供了其他东西(某个特定的模块只存在于它们的注册表中)。

Volo和Bower都很好，但从我的角度来看，如果你已经在使用NPM，那么最好还是坚持使用它。

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

与NPM相比，Bower的最大优势在于其依赖性管理强制使用组件的单个版本(而NPM的工作方式是将不同的副本/版本作为不同模块的子依赖性)。这是一件非常好的事情，因为它通过需要在不同版本中包含一个组件的多个副本来防止客户端的javascript变得膨胀。包含一个模块的多个副本是NPM依赖关系管理工作的核心，因此NPM完全不适合客户端包管理。

以上的结果是鲍尔包维护人员和消费者必须更加注意维护他们的依赖版本号以避免冲突，但这是值得付出的代价。我发现NPM模块在发布主要版本、次要版本和补丁版本时常常很马虎，所以NPM依赖性管理也不完全是一张玫瑰床。

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

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