对于使用node.js的许多人来说，bower的主要好处是可以管理根本不是JavaScript的依赖项。如果他们使用可编译为javascript的语言，则npm可用于管理其某些依赖项。但是，并非所有依赖项都将是node.js模块。其中一些可编译为javascript的代码可能具有怪异的特定于源语言的修饰，这使得在用户期望源代码时，将它们传递给已编译为javascript的一个不明智的选择。

并非npm软件包中的所有内容都必须是面向用户的javascript，但对于npm库软件包，至少其中一些应该是。

从http://ng-learn.org/2013/11/Bower-vs-npm/找到了这个有用的解释

一方面，创建了npm来安装在node.js环境中使用的模块，或者安装使用node.js构建的开发工具，例如Karma，lint，minifiers等。npm可以将模块本地安装在项目中（默认情况下在node_modules中），也可以全局安装以供多个项目使用。在大型项目中，指定依赖项的方法是创建一个名为package.json的文件，该文件包含依赖项列表。当您运行npm install时，npm会识别该列表，然后npm install会为您下载并安装它们。

另一方面，创建Bower来管理您的前端依赖项。像jQuery，AngularJS，下划线等之类的库。类似于npm，它有一个文件，您可以在其中指定一个名为bower.json的依赖项列表。在这种情况下，通过运行bower install来安装您的前端依赖项，默认情况下，它们将它们安装在一个名为bower_components的文件夹中。

如您所见，尽管它们执行相似的任务，但它们针对的是一组非常不同的库。

Bower维护模块的单一版本，它仅尝试帮助您为您选择正确/最佳的模块。

Javascript依赖管理：npm vs bower vs volo？

NPM对于节点模块更好，因为存在模块系统并且您在本地工作。Bower对浏览器很有用，因为当前只有全局范围，并且您希望对使用的版本有很好的选择。

我的团队从Bower搬到了npm，原因是：

• 程序化使用很痛苦
• Bower的界面不断变化
• 某些功能（如url速记）已完全损坏
• 在同一项目中同时使用Bower和npm会很痛苦
• 使bower.json版本字段与git标签保持同步是很痛苦的
• 源代码控制！=包管理
• CommonJS支持并不简单

有关更多详细信息，请参见“为什么我的团队使用npm而不是bower”。

所有程序包管理器都有许多缺点。您只需要选择可以与之共存的地方即可。

历史

npm开始管理node.js模块（这就是node_modules默认情况下会放入软件包的原因），但是当与Browserify或webpack结合使用时，它也适用于前端。

Bower is created solely for the front-end and is optimized with that in mind.

Size of repo

npm is much, much larger than bower, including general purpose JavaScript (like country-data for country information or sorts for sorting functions that is usable on the front end or the back end).

Bower has a much smaller amount of packages.

Handling of styles etc

Bower includes styles etc.

npm is focused on JavaScript. Styles are either downloaded separately or required by something like npm-sass or sass-npm.

Dependency handling

The biggest difference is that npm does nested dependencies (but is flat by default) while Bower requires a flat dependency tree (puts the burden of dependency resolution on the user).

A nested dependency tree means that your dependencies can have their own dependencies which can have their own, and so on. This allows for two modules to require different versions of the same dependency and still work. Note since npm v3, the dependency tree will by flat by default (saving space) and only nest where needed, e.g., if two dependencies need their own version of Underscore.

Some projects use both is that they use Bower for front-end packages and npm for developer tools like Yeoman, Grunt, Gulp, JSHint, CoffeeScript, etc.

Resources

• Nested Dependencies - Insight into why node_modules works the way it does

此答案是Sindre Sorhus答案的补充。npm和Bower之间的主要区别在于它们对待递归依赖项的方式。请注意，它们可以在单个项目中一起使用。

关于npm常见问题解答：（从2015年9月6日开始，archive.org链接）

在不嵌套依赖关系的情况下，避免依赖关系冲突要困难得多。这是npm工作方式的基础，并且已被证明是一种非常成功的方法。

在Bower主页上：

Bower针对前端进行了优化。Bower使用平面依赖树，每个包仅需要一个版本，从而将页面负载降至最低。

简而言之，npm旨在稳定。Bower旨在最小化资源负载。如果绘制依赖关系结构，则会看到以下内容：

npm：

project root
[node_modules] // default directory for dependencies
 -> dependency A
 -> dependency B
    [node_modules]
    -> dependency A

 -> dependency C
    [node_modules]
    -> dependency B
      [node_modules]
       -> dependency A 
    -> dependency D

如您所见，它以递归方式安装了一些依赖项。依赖项A具有三个已安装的实例！

凉亭：

project root
[bower_components] // default directory for dependencies
 -> dependency A
 -> dependency B // needs A
 -> dependency C // needs B and D
 -> dependency D

在这里，您会看到所有唯一依赖项都处于同一级别。

那么，为什么要使用npm呢？

也许依赖项B需要与依赖项C不同的版本。npm会同时安装这两个版本的依赖项，因此无论如何它都可以工作，但是Bower会给您带来冲突，因为它不喜欢重复（因为在网页上加载相同的资源是效率低下且成本高昂，也会造成一些严重的错误）。您将必须手动选择要安装的版本。这可能会导致其中一个依赖项中断，但是无论如何，这都是您需要修复的问题。

So, the common usage is Bower for the packages that you want to publish on your webpages (e.g. runtime, where you avoid duplication), and use npm for other stuff, like testing, building, optimizing, checking, etc. (e.g. development time, where duplication is of less concern).

Update for npm 3:

npm 3 still does things differently compared to Bower. It will install the dependencies globally, but only for the first version it encounters. The other versions are installed in the tree (the parent module, then node_modules).

• [node_modules]
  • dep A v1.0
  • dep B v1.0
    • dep A v1.0 (uses root version)
  • dep C v1.0
    • dep A v2.0 (this version is different from the root version, so it will be an nested installation)

For more information, I suggest reading the docs of npm 3