npm spm bower三个包管理器，哪个比较好用

Bower

bower 的缺陷比拟清楚，最大的效果就是缺乏一致的构建机制。但有意思的是 Google 的 Polymer 选择了 bower 作为包管理器，由于 Polymer 是树立在两个还没在阅读器里普遍完成的东西上的：HTML Import 和 SPDY。HTML Import 让你可以把 HTML, CSS, JS 写在同一个 HTML 文件里作为一个组件或是模块，然后经过一行代码引入：

<link rel=”import” href=”my-component.html”>

同时，在一个组件里也可以引入其他的组件，也可以直接援用远程效劳器上的组件。某种水平上 HTML import 可以取代如今的组件模块机制。而 SPDY 是下一代的 http 协议，可以让阅读器只用一个效劳器衔接传输多个文件。换句话说即使你页面里有很多个 HTML import 也不会由于屡次央求招致页面加载缓慢。在这两个东西存在的理想状况下，前端项目是完全可以不需求构建进程的。这是 Bower 久远来看的一个意义，但现阶段对大少数开发者而言，构建依然是一个必不可少的步骤。

Component

曾经作为 TJ 脑残粉的我是坚决的 component 运用者，但用了一段时间以后有几个比拟重要的不爽之处：

– 每一个 component 都必需要在 component.json 中手动列出一切文件，每次更改项目结构或是重命名文件都很费事，我还为此写了个 grunt 插件专门自动做这个事情。

– component 只要一个 wiki page 列表，没有一个可搜索的中央数据库，模块的可发现度比拟低。同时，github 仓库的星数是独一的模块质量目的，而 npm 则有下载统计和被依赖数量这些更真实的数据。

– 模块发现度低带来的另一个效果就是不同作者的模块之间很少出现公用的依赖。虽然 Component 的依赖是扁平的，在实践运用他人的模块的时分依然会出现重复（异样的效果不同的完成），这就招致很多人宁可本天然轮子，自己依赖自己，只是把 Component 当个工具而不是平台用。

npm + Browserify

我这里想要指出，npm 其实是一个十分好的前端（对，没错，是前端）包管理方案，最主要的就是依托 Browserify 这个神器。Browserify 最大的意义不是让你能在 npm 上发布前端的静态资源，而是完成前后端的代码共享。npm上有很多包是前后端通用的，比如我要找个现成的算法完成，什么 levenshtein distance 啊，perlin noise 啊，gaussian distribution 啊，A* 寻路啊，npm 上一搜一大把。常用的库如 jquery backbone 之类的，只需你想失掉的基本上都有 npm 版本。需求什么直接 npm install 就可以用在阅读器端的项目里了，Component 和 Bower 在这方面跟 npm 完全没有可比性，spm 就更不提了。开发流程下去说也极端省心，项目用 CommonJS 写，不需求任何配置，给一个入口文件就行！还有一个官方工具 watchify，一行命令跑起，保管文件自动构建，连 grunt gulp 都不需求。

这个方案独一的缺陷，就是 npm 的树状依赖结构能够招致重复的模块和代码量的臃肿，需求跑一次 `npm dedupe` 来尽量压平依赖树。当然，实践状况中前端模块出现依赖同一模块的不兼容版本还是很少见的。