npm、bower和spm3的比较

npm

npm属于node模块的管理器
npm针对node模块，原生支持commonJS，而前端模块除非该管理器自己定了，否则规范是无法统一的。即便规定了commonJS，那么必定会有配套工具打包来实现实际的运转。
npm针对的node模块，它的依赖是树状的。项目中用到的A,B,C三个模块，他们可以分别依赖不同版本的lodash，而互不影响。但是前端模块除非做了很好的模块隔离（如实现了commonJS，并能很好地进行打包，即便如此，前端环境的特殊性也无法忍受相同模块的不同版本并存。比如页面中引入两个版本的jQuery，代码数据传输X2），否则一般的依赖都是扁平的。
当然，确实有很多人仅仅将npm作为一个静态资源共享平台，用来发布和共享前端模块，但是这种做法不推荐，因为显然有更好的方案。

bower

bower充当的基本上是一个静态资源的共享平台。

bower本身不存储模块文件本身（npm以及spm则会将模块作者的文件打包保存在自己的服务器中），也不保存模块的版本信息。模块的发布者通过注册（register）的方式，将模块的可访问的公开的git地址记录在bower的数据库中，而所有的版本都是通过模块发布者自己控制代码库的tag来决定。
bower在安装流程基本上可以简单认为是将注册的git地址中的特定tag clone一份到你本地的bower_components 目录中。
看起来bower本身提供的功能，以及实现都比价简单，但是它确实使用最广的前端模块管理工具。它在github上的项目有1w+的star。之所以bower能这么流行，得益于它宽松的规范能很好地直接应用在很多已经存在的项目中，所有人都能通过简单地添加一个bower.json以及补充相关信息，不需要修改代码和目录结构，就马上开始使用注册发布自己的模块。

spm3

作为Sea.js - A Module Loader for the Web的生态圈的包管理工具，围绕seajs而构建的，不仅包含模块的发布，传输共享，还包含一系列的构建工具。
spm3开始全面迎向CommonJS，逐步放弃CMD。CMD最有名的实现者是SeaJS！一方面对于CommonJS支持，能很好地扩大spm的社区（比如Component的模块都能轻松地迁移过来），另一方面你会看到spm3在打包上提供了Standalone 模式，不再依赖SeaJS。
spm3是和npm一样的前端模块管理平台。这样的问题在于，对于一个模块的实际版本是否稳定是难以保证的，而且代码掌握在别人手里稳定性难以保证（component使用github还是可靠，但是bower这种不限定git源的，就难说了）。在spm3中你可以使用如

$ spm publish

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

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