npm、spm、bower 这三个包管理器的异同

npm属于node模块的管理器。而spm和bower是前端模块管理。这两者大的区别有两点：

1.NPM针对node模块，原生支持commonJS，而前端模块除非该管理器自己定了，否则规范是无法统一的。即便规定了commonJS，那么必定会有配套工具打包来实现实际的运转。
2.处理依赖的方式不同。NPM针对的node模块，它的依赖是树状的。项目中用到的A,B,C三个模块，他们可以分别依赖不同版本的lodash，而互不影响。但是前端模块除非做了很好的模块隔离（如实现了commonJS，并能很好地进行打包，即便如此，前端环境的特殊性也无法忍受相同模块的不同版本并存。比如页面中引入两个版本的jQuery，代码数据传输X2），否则一般的依赖都是扁平的。

一、Bower

twitter推出包管理工具。其特点是对包结构没有强制规范，也因此bower本身并不提供一套构建工具，它充当的基本上是一个静态资源的共享平台。

bower本身不存储模块文件本身（NPM以及SPM则会将模块作者的文件打包保存在自己的服务器中），也不保存模块的版本信息。模块的发布者通过注册（register）的方式，将模块的可访问的公开的git地址记录在bower的数据库中。而所有的版本都是通过模块发布者自己控制代码库的tag来决定。

bower在安装流程基本上可以简单认为是将注册的git地址中的特定tag clone一份到你本地的bower_components 目录中。

看起来bower本身提供的功能，以及实现都比价简单，但是它确实使用最广的前端模块管理工具。它在github上的项目有1w+的star。之所以bower能这么流行，得益于它宽松的规范能很好地直接应用在很多已经存在的项目中，所有人都能通过简单地添加一个bower.json以及补充相关信息，不需要修改代码和目录结构，就马上开始使用注册发布自己的模块。

二、component

（好吧，发现官网打不开了，我可是翻墙了....）

TJ大神的项目，它比bower提供了更多规范和配套工具：

它使用commonJS规范
它和bower一样，不储存模块代码，而是通过 github账号名/模块名 的方式作为一个模块的标识符，是的，这句话的意思就是它的模块都是在github上，进一步的意思是，你在github上新建一个public的仓库的过程就是发布一个新模块的过程，另外模块down到本地后，也会带上用户名作为文件夹。对于有强迫症的人来说，这个有点抓狂，虽然这样可以解决前端模块重名的问题（比如，slide，tooltip这类几乎每个合格的前端开发都自己早过一次轮子的组件，太常见了）
它在配置文件中，罗列出必要的静态文件资源，因此在下载的过程中，是先抓去这个配置文件，然后再通过github的raw接口去抓取列出的文件。在传输效率上比bower的方式高效。且down下来的文件目录也会比较简洁。
既然1提到了它使用commonJS，那么自然它也提供了配套的打包工具component/builder，打包工具包含的内容这里不细讲（要讲可以额外再列一个如“有哪些好的前端构建工具推荐？”这样的问题），主要有两个特点：

基于commonJS规范
面向ES6（是的，你可以在componet中使用ES6的语法，而打包工具会帮你做好兼容，这也是component希望扮演的角色："Component is currently a stopgap for ES6 modules and Web Components" )

附上
Compare component with other solutions

三、spm3

作为Sea.js - A Module Loader for the Web的生态圈的包管理工具，围绕seajs而构建的，不仅包含模块的发布，传输共享，还包含一系列的构建工具。

为什么放到最后来讲，因为如果仔细看SPM3（注意是3）的功能，它基本上是对bower，compoent和npm以及其他一些有名的包管理工具优点的吸收。这里就说说我认为SPM3的优势：

SPM从3.X开始全面迎向CommonJS，逐步放弃CMD。CMD最有名的实现者是谁？SeaJS！是的，这里是想说，一方面对于CommonJS支持，能很好地扩大SPM的社区（比如Component的模块都能轻松地迁移过来），另一方面你会看到SPM3在打包上提供了Standalone
模式，不再依赖SeaJS
和NPM的发布一样爽快的前端模块管理平台。上面提到的bower和component本身都是不托管用户的模块代码的，模块的使用就是通过开发者自己维护仓库和版本（打tag）。这样的问题在于，对于一个模块的实际版本是否稳定是难以保证的（我可以重复地去打相同的tag）而且代码掌握在别人手里稳定性难以保证（component使用github还是可靠，但是bower这种不限定git源的，就难说了）。在SPM中你可以使用如

$ spm publish

这样的方式发布代码了。
提供了一套完善的构建流程和工具，包含：

打包
调试
测试集成
文档生成

支付宝团队维护（支付宝自己在使用SPM，所以这个工具必定是经过实战考验的），中文文档。这些对于国内用户来说都是很重要的。

----------------- 总结 --------------------

bower

优点：约束松散，使用简单--> 可用模块众多
缺点：没有提供构建工具（当前应该能从社区中找到针对bower的构建工具），且直接在bower上安装模块稳定性难以保证（源的稳定性，以及国内网速的稳定性）。

不过如果是公司级别内部使用的话，结合公司本身的git仓库，并创建一个私有的bower server，并定制一套规范和打包工具，也是可行的。（好吧，这是我之前考虑过的在我厂内部实施的方案）

component

优点：基于commonJS，有比较完善的构建工具，面向ES6，且能解决命名冲突问题
缺点：基于github，目录包含用户名...（我个人无法忍）

spm

优点：托管模块代码，国内网络传输的稳定性（这个和bower以及component比起来就是很重要的优势），完善的构建流程，中文文档
缺点：模块数量（目前是400多，和component以及bower的4位数比起来还是有差距）

转载出处：http://www.zhihu.com/question/24414899