接上一篇,因为不理解transport插件所采取的行为,于是自己动手做一个converter插件。
这是我个人的怪癖,实在不是个好习惯,当觉得什么不好的时候,一般情况都变成自己去写一个。其实,如果按照一定的规范去写module,使用transport和concat插件就足够用了。那些这个插件到底有什么用呢?可以当做好奇,也可以当做任性,还可以当做希望丢弃一些自己觉得束缚的东西。
闲话说多了。开始动手吧。
第一步当然是根据grunt创建插件的指引创建一个初始插件。grunt默认使用nodeunit做单元测试,而我出于习惯,改成了grunt-jasmine-node。
第二步就是编写task了。
基于上一篇文章的理论,我在options中加入了一个叫做base的地址。当生成module的标识时,是由该文件相对于base的位置而生成的。这一点和transport插件有区别。另外,我去掉了alias,paths,idleading3个属性,改成了modifiers,为的是更为方便的去参与到生成过程中去。至于uglifyjs的options,我将默认的uglifyjs写进了task中。其实也只是多余的步骤,transport插件本身就支持uglifyjs在做输出时支持的所有选项。只是的确如transport的作者所说,这个options基本没有什么用途。
于是目前的options大概形式为
{
converters : {
".js" : [script.jsConverter]
},
uglifyjs : {
indent_start : 0, // start indentation on every line (only when `beautify`)
indent_level : 4, // indentation level (only when `beautify`)
quote_keys : false, // quote all keys in object literals?
space_colon : true, // add a space after colon signs?
ascii_only : false, // output ASCII-safe? (encodes Unicode characters as ASCII)
inline_script : false, // escape "</script"?
width : 80, // informative maximum line width (for beautified output)
max_line_len : 32000, // maximum line length (for non-beautified output)
ie_proof : true, // output IE-safe code?
beautify : true, // beautify output?
source_map : null, // output a source map
bracketize : false, // use brackets every time?
comments : true, // output comments?
semicolons : true
},
modifiers : {
idModifier : null,
dependencyModifier : null,
requireModifier : null,
asynModifier : null
}
}
至于插件需要做的事,首先就是确定传入的src,这里采用了transport插件一样的规则,如果传入的不是expand模式而且还是个数组则取数组的第一个。然后根据src的扩展名找到对应的converter,然后将options和src传给converter进行转换,最后将转换接过输出到dest中去。
所以converter才是这个插件的关键所在。
seajs有提供一个关于css的解决方案,但是我的思想可能更为传统一点,我还是不愿意将css转换成js的方式去硬塞给seajs加载。我个人更倾向的选择是,module加载自己的css,css按需进行合并,module则从依赖自己的css改变成为依赖合并后的css。这里有一个留下了一个问题,seajs具体是怎么处理与css相关的依赖的。
继续说jsConverter。
有了cmd-util这个库,在做jsConverter时就比较简单了。
因为grunt本身提供了很多很方便的方法。所以我也采取了和transport插件一样的做法。
exports.init = function(grunt){
var jsConverter = function(file,options){
}
return {
jsConverter:jsConverter
}
}
将grunt本身作为参数传个一个init方法。
那么首先当然要读取src文件的内容,第二步这是通过cmd-util的ast库取出meta。
var fileData = grunt.file.read(file.src);
var meta = ast.parseFirst(astCache);
meta是一个object,里面包括id,dependencies,factory,dependenciesNode这些cmd属性。如果meta为undefined,则代表当前module是non-cmd的module,也就是没有使用seajs规范写法的module。这个时候,我们直接返回文件内容就好了。不需要再做转换了。
如果meta中有数据,这个时候才做处理。
规范的seajs module写法是
1.define(function(require,exports,module){})
但是也有特殊的情况会使用到
2.define(id,factory);
3.define(deps,factory);//amd module
4.define(id,deps,factory);
如果meta中有id的属性,则意味着module可能采用的是2或者4的方式,此时,我们在converter过程中需要保留下id的内容。
如果没有id属性,则需要我们生成一个id。依据上一篇文章所说,我们的生成规则,应该是该文件相对于options.base的地址。
于是就有了
function generateId(fileSrc,base){
return unixy( path.relative(base || '',fileSrc).replace(/\.js$/, ''));
}
其中unixy函数时转换“\”变成“/”的辅助函数,path读取出来的地址使用的是"\"做分隔符,而我们url则是使用的“/”
得到转换后的id,
只需要使用
astCache = ast.modify(astCache,{
id : id,
dependencies : meta.dependencies
});
var data = astCache.print_to_string(options.uglifyjs);
即可得到一个转换成功的module。然后将module输出到dest中去,基本功能就大功告成了。
接着,就剩下处理modifier内容部分了。
关于modifier的参数方式,初步设想为3种,
1.modifier为function
这种情况下的modifier会被传入需要改变的对象。如果是idmodifier传入的则是module的id,如果depsmodifier传入的则是每一个dependency;
返回的内容则被当做改变后的值。
2.modifier为object
改变对象与改变后的值的mapping
3.modifer为二维数组。
每一个数组元素都有2个元素,第一个元素为正则表达式,第二个元素为改变后的值。满足该二维数组中的正则表达式的第一个元素,将使用其改变后的值。
ast modifier本身就支持function和object的行为,因此我们只需要做一下关于二维数组的转换就好。
if(grunt.util.kindOf(modifier) === "array"){
fn = function(v){
var modifiers = modifier.filter(function(cond){
if(!cond.length){
return false;
}
var reg = cond[0];
if(grunt.util.kindOf(reg) === "regexp" && reg.test(v)){
return true;
}else if(grunt.util.kindOf(reg) === "string" && reg === v){
return true;
}else{
return false;
}
});
if(modifiers.length===0){
return v;
}else{
return modifiers[0][1] || "";
}
};
}
这样实际是传给了ast.modify一个function的值。
ok,大功告成。
具体代码可以查看https://github.com/chenliangyu/grunt-seajs-converter