停不下来的前端，自动化流程

Mod.js并不是简单的任务运行器，其内置集成了Web前端开发常用的工具集，覆盖了80%的前端使用场景，而另外的20%则可通过Mod.js的插件机制来扩展。

相遇

Mod.js可通过NPM来安装最新的版本， 在你来到[Node.js]的编程世界时已同时附带了NPM，当前Mod.js最新版本0. 4.x要求Node.js要求>= 0.8.0：

$npm install modjs -g

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

相识

Mod.js通过Modfile.js文件驱动任务执行，可以手动创建一个Modfile.js文件，也可以通过模版初始化一个Modfile.js文件：

$modinit modfile

Modfile.js是一个Plain Node Module, 通过 Runner

对象来描述任务的具体执行过程：

// 暴露Runner对象module.exports = {}

如是异步配置，则可通过回调模式传递Runner对象：

module.exports = function(options, done){ setTimeout( function(){ // 回调Runner对象varrunner = {}; done(runner); }, 1000)}

借此一瞥通常Runner

对象的全貌：

module.exports={version:">=0.4.3",plugins:{pngcompressor:"mod-png-compressor",compress:"grunt-contrib-compress"},tasks:{asset:"asset",online:"online_dist",offline:"offline_dist",offlinePackage:"{{offline}}/package.zip",rm:{online:{dest:"{{online}}"},offline:{dest:"{{offline}}"}},replace:{src:'./js/**/*.js',search:"@VERSION",replace:require('./package.json').version},build:{options:{src:["*.html"]},online:{dest:"{{online}}",rev:true},offline:{dest:"{{offline}}",rev:false}},cp:{options:{src:["./img/**"]},online:{dest:"{{online}}/img/",rev:true},offline:{dest:"{{offline}}/img/",rev:false}},pngcompressor:{src:"./img/**/*.png"},compress:{dist:{options:{archive:'{{offlinePackage}}'},//includesfilesinpathfiles:[{expand:true,cwd:'{{online}}/',src:['*.html'],dest:'qq.com/web'},{expand:true,cwd:'{{online}}/img',src:['**'],dest:'cdn.qq.com/img'}]}}},targets:{default:["rm","pngcompressor","replace","build","cp"],offline:["default","compress:dist"]}}

Mod.js的配置项追究极简易懂，即使不懂Java语法也能看懂配置与修改配置。

相知

在执行mod命令时，Mod.js会在当前目录下查找是否存在Modfile.js文件。当找到Modfile.js文件时，Mod.js将读取Modfile.js里的配置信息，如识别到有配置Mod.js插件，会自动安装没有安装过的插件，插件不仅可以是发布到NPM的包，也可以是存在本地的自定义任务。

Mod.js加载插件的方式是通过Node的require机制，然后执行暴露的exports.run，这与Mod.js内置任务的完全一样的机制。

在命令行下，通常执行mod时是需指定Modfile.js中某一特定目标，但当存在命名为default的目标或配置中只有一个独立目标时，此时目标的指定是可选的，Mod.js会自动识别唯一的存在或default的目标：

targets: { dist: [ "rm", "cp"]} 等价于 moddist $mod

配置有default目标的场景：

targets: { default: [ "rm", "cp"], other: [ "compress"]} 等价于 moddefault$ mod

深入任务

任务是具体执行的类别，从配置示例开始阐述：

tasks: { min: { src: "./js/*.js"}}

以上配置了一个文件压缩的min

类别任务，src

描述需要压缩的文件：js

目录的所有js文件。src

支持unix glob

语法来描述输入文件集，其匹配规则如下：

匹配符：

示例：

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.jsa{b, c{d,e}} x{y,z}.js => abxy.js abxz.js acdxy.js acdxz.js acexy.js acexz.js

如任务没有配置dest，默认在输入文件同级目录下输出.min后缀的文件：

uglifyjs Minifying ./js/unminify .js-> js/unminify .min.jsuglifyjs Original size: 1, 393. Minified size: 449. Savings: 944( 210.24%)

内置的min

任务支持三种文件类别的压缩，Java、CSS与HTML，是对uglifyjs、cleancss与htmlminfier任务的代理。min通过识别文件后缀进行具体任务的分发。所以min任务的src选项需指定具体的后缀。通常每个不同类别的任务都支持src与dest，且Mod.js会结合实际项目中常见的场景，dest往往都是可选的，如上min任务默认的dest是在当前目录下输出待.min后缀的文件，同时后缀名是支持通常suffix选项配置的。

不可或缺的插件机制

Mod.js支持2种生态的插件：Mod.js 与 Grunt。插件的配置同样是在Runner对象下：

plugins:{ // Mod.js NPM 插件sprite:"mod-stylus", // Mod.js 本地插件mytask:"./tasks/mytask"// Grunt NPM 插件compress:"grunt-contrib-compress"}

服务化

了解完如何实施Mod.js进行自动化时，仅是停留在工具的层面，如何将其进一步的提升？了解一个事实，服务优于工具。如何将其封装成服务，用户无需安装Mod.js，无需执行命令，只需做一次事情：提交代码，中间的过程无需关注，最终把持续构建的结果反馈给用户。这是下一步需要去完善的，建立接入机制，让工具以服务的形式完全融入流程中。

作者 | 元彦

原文 | http://www.alloyteam.com/2014/03/frontend-workflow/

声明 | 文章著作权归作者所有，如有侵权，请联系小编删除。

作者 | 元彦

原文 | http://www.alloyteam.com/2014/03/frontend-workflow/

声明 | 文章著作权归作者所有，如有侵权，请联系小编删除。返回搜狐，查看更多