coolie 这个单词有点儿意思，中英同音并且同义，义指“苦力”。

现在，coolie 作为前端构建工具，它仍然是苦力（coolie）。 往常需要人为手动做的苦力活、重复活，现在都全部交给 coolie 来做。 因为 coolie 能够做的更好、更精确。

coolie 组成部分

为了便于区分，将 coolie 分为两部分：

• 前端开发使用的模块加载器，称之为coolie.js，在 1.0.0 版本之后，coolie 基于 seajs 进行了一些封装和简化（做了哪些封装和简化）。
• 前端构建使用的构建工具，称之为coolie-cli，相比同类的工具，功能丰富，使用方便，零配置（coolie 优势看这里）。

coolie 简史

萌芽

从2014年8月31日起，开始接触到前端构建，觉得当时使用的 seajs 的 spm， 自动化比较差、版本管理略有不足，虽然有些地方做的很好，比如 seajs 是国产模块加载器先驱，推广了 CMD 规范的， 但还是使我弃之而新建了apb 项目，专门用于构建 seajs 的 AMDJS 生产模块。这样还是有些问题，受限于 seajs 的一些复杂配置的原因， 无法简单化，无法通用化。

起步

从2014年10月21日起，开始新建了一款通用化的前端模块加载器 coolie（遵循 CMD 规范）。 coolie 的使用就和 nodejs 几乎一致，都是通过使用物理相对路径来标识依赖的模块， 这种标识方法在 webstorm 里开发非常的舒畅，因为 webstorm 有对 require 的路径检查。

同日，新建了前端模块构建工具， 为了与前端模块加载器 coolie 保持一种配套关系，也命名为 coolie。在当时，该工具的定义只是一款 纯粹的模块构建工具，是一款模块打包工具，在这个层面上，有很多工具与之类似，如 webpack、spm、r.js 等。 但这些工具，都没有 coolie 来的简单（coolie 的强大之处本书后文会描述到）。

成长

在开发 coolie 的过程中，coolie 的也不免俗遭受到了质疑和不肯定，当然也有鼓励和帮助， 感谢批评和帮助我的人（本书末尾章节会有一个列表来展示他们）。 coolie 起初做的仅仅是按照入口模块将一堆依赖模块打包成一个生产模块那么简单（coolie 的模块构建思路非常特别， 目前市场上绝对独一无二，webpack 在模块打包上也有些特别，两者都是的打包方式同样精彩， 本书后文会说到），而这些事件随便下载个插件，配合 grunt/gulp 就可以实现，这是最大的质疑声音。 其他更好（？）的工具都可以实现打包，为什么要用你的？还要用你的模块加载器？凭什么？

如今

至今，coolie 已经完成了从模块打包工具到前端构建的通用解决方案的过渡过程，coolie 已经发布 1.0 版本， 也是撰写本书（官方使用指南、文档）的一个主要原因，我想将 coolie 介绍给你，因为他可能是最好的前端开发构建工具了。

其实，coolie 不仅仅是模块打包，模块打包只是 coolie 所做的事情当中很少的一部分。 coolie 深入整个工程，分析到每一个被用到、被依赖到的地方，将他们都纳入管理范围。

现在，coolie 已经在企业级产品中得到了充分的检验，满载美誉。为传统的前端开发解决了：

• 需要上线前手动修改版本号的烦恼
• 每次上线前自动递增版本号造成资源浪费的烦恼
• 图片等静态资源修改了需要手动重命名
• 图片、样式等静态资源不知道在什么地方被用到了，不敢删除
• 到底是先上 CDN，还是先发布程序
• 模块依赖繁杂，找不到模块入口了
• 模块入口找不到，脚本直接写在页面上了
• 引用的脚本没有在上线之前压缩
• 将各种样式写在一起，修改一处多处受影响了
• 等等

如果，你也遇到了上述问题，那么 coolie 或许可以帮到你，不妨继续往下再看看。

coolie 地址

• coolie.js（前端模块加载器）：https://github.com/cooliejs/coolie.js
• coolie-cli（前端开发构建工具）：https://github.com/cooliejs/coolie-cli