黎明前的节奏

关于Mod的起航，从身边讲起：

• 发布前人肉剔除调试代码，偶尔还会不小心把alert、console等外发到现网

• 发布时有些已经压缩过JavaScript文件被二次压缩后导致报错

• 发布前需要修改HTML中引用CSS或JavaScript为压缩后的资源地址或修改资源时间戳

这些都是我们在项目中真真实实发生的事情，而Mod的初衷即源于此，用自动化方案解决常见问题。

她是什么?

如何回答这个问题的关键是我们如何来使用Mod。绝大部分童鞋都称 Mod 是一个构建工具：一个用来把源代码编译为可发布代码版本的工具，过程中自动进行预处理，优化，编译等操作。也有童鞋会说 Mod 是一个更复杂的东西：一个流程管理工具，我们可以在Mod构建前后用Mod做更多流水工作，前可以生成项目的脚手架，后可以部署测试环境等等。通常我偏爱的回答更多的是，管他是啥呢，能优雅而简单的解决问题的猫都是好猫。理解Mod能解决什么问题比其是什么更有价值与意义，不是吗？当然，考虑一个项目的完备性，Mod也是其官方解释: JavaScript WorkFlow Tooling For Web，面向Web的流程工具。

特性

• AMD、CMD模块打包 - 集成RequireJS、SeaJS模块加载器

• CSS 模块打包 - CSS @import 模块合并打包

• 压缩合并一体化 - HTML CSS Javascript 压缩合并

• 源码智能化压缩 - 零配置自动识别源码是否被压缩过，避免二次压缩带来的问题

• 图片自动无损压缩 - 零配置自动识别图片，支持 PNG、JPG、GIF 图片压缩

• 源码规范检测 - HTML CSS Javascript 规范性检测

• 源码自定义检测 - 自定义规则检测， 避免 alert 等疏忽

• 工具跨平台支持 - 基于 Nodejs

如何把她装回家？

Mod看起来挺漂亮，那如何把她装回家？Mod 需通过媒婆 NPM 来搞定,在你来到 Node.js 的编程世界时已同时附带 npm。

$ npm install modjs -g

-g 参数表示把Mod安装到全局，如此mod命令将会在system path内，方便在任何一个目录运行Mod。

Mod 0.2.x 的 Node.js 版本要求 >= 0.6.0.

她是如何工作的？

在执行mod命令时，Mod会在当前目录下查找是否存在Modfile文件。当找到Modfile文件时，Mod将读取Modfile里的配置信息，如识别到有配置Mod插件，会自动安装没有安装过的插件，插件不仅可以是发布到NPM的包，也可以是存在本地的自定义任务。Mod加载插件的方式是通过Node的require机制，然后执行暴露的exports.run，是与Mod内置任务的完全一样的机制。

通常在命令行下，在我们执行mod时是需指定Modfile中的某一目标（targets中配置项），但在只配置有一个目标项目时，目标的指定是可选的，Mod会识别唯一存在的目标并运行。如：

$ mod dist

可简化为：

$ mod

少年，开始吧

Mod的关键驱动器是Modfile文件，可以手动创建一个Modfile文件，也可以通过模版初始化一个Modfile文件：

$ mod iNit modfile

神呀，一个名叫Modfile的文件出现在当前目录啦，拯救的前奏开始啦。

Modfile

Modfile 是一个Plain Node Module, 通过暴露我们称为 Runner 的对象来进行设置：

module.exports = { // Runner config here }

只此一步，非常简单。我们来一瞥 Modfile Runner的全貌：

module.exports = { // 配置安装插件对应的名称，不配置则按约定名称关系查找，如 Reload 对应 mod-reload 模块 plugins: { "reload" : "mod-reloadx", "ghpages-deploy" : "mod-ghpages-deploy" } ,tasks: { "rm" : { "target": "./dist" }, "min" : { "img": { "source": "./img/*.png", "dest": "./dist/img" }, "css": { "source": "./dist/css/*.css", "dest": "./dist/css" }, "html": { "source": "*.html", "dest": "./dist/" }, "js": { "source": "./dist/js/*.js", "dest": "./dist/js" } }, "cat": { "source":["./dist/js/a.js","./dist/js/b.js"], "dest": "./dist/js/ab.js" } }, targets: { dist: "rm min cat" } };

啊哟，不错哦~清晰易懂，产品MM说这她也能看懂呢~ Mod 的配置项追究极简易懂，区别于Grunt的配置内容大部分只有前端开发工程师才能看明白，而Mod不限与此，追求即使不懂JavaScript语法也能看懂配置与修改配置。

插件配置

module.exports = { plugins: { // Plugin task sprite: "mod-sprite", // Custom task mytask: "./tasks/mytask" } }

任务配置

module.exports = { tasks: { Pkg: { name: "foo" }, min: { source: 'src/{{pkg.name}}.js', dest: 'build/{{pkg.name}}.min.js' } } };

目标配置

module.exports = { targets: { dev: "cat min:js" dist: "sprite min", } };

文件匹配规则

匹配符：

• "*" 匹配0个或多个字符

• "?" 匹配单个字符

• "！" 匹配除此之外的字符

• "[]" 匹配指定范围内的字符，如：[0-9]匹配数字0-9 [a-z]配置字母a-z

• "{x,y}" 匹配指定组中某项，如 a{d,c,b}e 匹配 ade ACE abe

示例：

c/ab.min.js =>  c/ab.min.js
*.js =>  a.js b.js c.js
c/a*.js =>  c/a.js  c/ab.js c/ab.min.js
c/[a-z].js =>  c/a.js c/b.js c/c.js
c/[!abe].js =>  c/c.js c/d.js
c/a?.js =>  c/ab.js c/ac.js
c/ab???.js =>  c/abdef.js c/abccc.js
c/[bdz].js =>  c/b.js c/d.js c/z.js {a,b,c}.js =>  a.js b.js c.js
a{b,c{d,e}}x{y,z}.js => abxy.js abxz.js  acdxy.js acdxz.js acexy.js acexz.js

版本升级

笔者在写这篇文章的时候，Mod已在0.2.x的尾巴，一只脚迈入了0.3.x的大门，觉得还是有必要搞个章节提下 Mod 在版本升级中能力上的加减法。在早期的 Mod 0.1.x 版本，Mod 以前端模块化为核心，提供了模块的下载安装，模块的依赖管理，模块的更新，模块的构建发布等对模块的系列操作。而到 Mod 0.2.x 版本的时候，从能力范围上 0.2 版本是 0.1 版本的功能子集，我们对Mod的能力做了减法，把除了模块的构建发布之外的能力全进行了阉割，把在无数个夜晚中coding的代码进行废弃无疑是痛苦与不忍的，但还是这样做了，原因主要有两点：

• 基于社区的前端包管理工具，短期内都很难成长为主流或趋于主流。这其中的最关键的问题，是不同库依赖同一库的不同版本时，在前端的场景下无法忽视同一库存在多个版本的问题。不完美解决方案之一，存在多版本问题时把解决的方式交由用户决定，由用户来选择保留哪一个版本或都保留；不完美解决方案之二，移除版本的概念，比如依赖jQuery就表示永远是依赖最新的版本，当出现问题时同样只能手动来解决；

• Twitter Bower 也在探索前端包管理方案的路上，并且更专注于基于社区的前端包管理。同时 Mod 的插件化扩展能力决定，当我们有包管理需求时，可以通过把 Bower 封装为插件来扩展 Mod 的能力；

从 Mod 0.1.x 到 Mod 0.2.x 的过渡中也几乎重构了绝大部分实现。 Mod 0.2.x 的核心完全以任务为导向，似乎与Grunt重叠了对吗？我们看Grunt的介绍是一个任务的运行器，又见任务。是的，很相似，更严格的说，概念上是几乎一致的。但那不重要，我们关注的是能解决什么问题与如何解决问题。如前端圈内有众多的类库，现在的 Grunt 更像是 YUI 给人的感觉，强大但并不轻量与简单，而 Mod 更像 jQuery，面向使用者追求简约清爽。在延伸就偏题了（此处已删除N个吐槽Grunt的文字），继续谈版本升级。

经过 0.1.x 到 0.2.x 的减法，Mod 已完全专注于Workflow中的问题。 从目前的0.2.x 到即将发布的0.3.x，在能力上也都得到了大量的加强，同时也提供了更详细的文档。

用户体验

作为一个工具也有用户体验吗？回答是肯定的。举个栗子，在 Mod 命令行的操作模式下，当我们输入Mod无法识别的命令 mini 时，Mod会提示用户可能想输入的是min，大家感受下这种细节：

$  mod mini
Error: The 'mini' is not a valid command!
Did you mean one of these?
  min
Try the following command for more help:
  mod -h
  mod help  mod help [command]

与Grunt的区别在哪？

1. Mod for web，Grunt for everyThing，Mod比Grunt更专注于Web

2. Mod提供了更简约的配置，更提供了零配置构建模式

3. Mod提供了更简单的插件开发过程，如果学习Grunt插件开发至少需要3个小时的话，而Mod至多只需30分钟

4. Mod不仅面向英文社区，而且更友好的面向中文社区

Mod 是来自腾讯的开源项目，目前由腾讯的前端工程师在维护与使用，也诚邀有梦想的您可以加入我们一起共同筑造。