grunt与seajs
grunt是前端流行的自定义任务的脚手架工具,我们可以使用grunt来为我们做一些重复度很高的事情,如压缩,合并,js语法检查等。通过定义grunt的配置文件Gruntfile.js,配置并注册grunt的任务,最终我们可以通过命令行来执行任务。
seajs主要用于模块化,通过define定义一个模块,可以通过require加载模块,exports导出模块。具体的seajs实现可通过本博客的系列博文--Seajs源码解析系列来进一步了解。
在实际生产中,如果紧紧定义一系列seajs模块而并不进行合并压缩的话,加载性能很低,原因大家都懂的,seajs在浏览器端处理依赖模块,并进行异步加载,这个过程中会有多个http请求,大大降低页面的加载速度。所以结合grunt构建工具,我们可以将模块的依赖处理放到服务端进行,并将所有模块合并压缩,完成生产所需的最终文件。
在seajs社区中,已经提供了一款npm模块,即grunt-cmd-transport。我们通过该模块给seajs模块命名,并处理各模块之间的依赖。这项工作听起来很简单,但是在笔者的实践过程中出现的问题却不少,因此本文着重讲解transport任务的相关配置。
grunt的相关文件
grunt相关文件包括了2个,首先是Gruntfile.js,另一个是package.json文件。Gruntfile进行grunt任务的配置及注册,package.json用于向Gruntfile提供参数,并设置依赖的npm模块。
在下面package.json中,定义spm键,设置模块的别名,在Gruntfile中,通过pkg = grunt.file.readJSON()来读取package配置文件,并通过<%= pkg.spm.alias %>获取模块别名。
package.json { "name" : "HelloSeaJS", "version" : "1.0.0", "author" : "yang li", "spm": { "alias": { "jquery": "jquery" } }, "devDependencies" : { "grunt" : "0.4.1", "grunt-cmd-transport": "~0.2.0", "grunt-cmd-concat": "~0.2.0", "grunt-contrib-uglify" : "0.2.0", "grunt-contrib-clean" : "0.4.0" } }
接下来我们进行设置grunt。Gruntfile.js其实就是一个node模块,依然使用闭包将所有的逻辑进行包裹,并提供了grunt参数,通过grunt.initConfig进行任务的配置。
对于seajs模块而言,首先需要处理各模块之间的依赖,我们通过设置transport任务来完成。seajs遵循的是CMD规范,在定义模块时不需要制定模块名和模块的依赖组,只需设置工厂函数即可。其实在未使用grunt进行合并seajs时(即在浏览器端处理模块依赖),seajs设置模块id和uri相同,为绝对路径。在这个过程中有些小技巧,在Seajs源码解析系列中并未提到,现在在这里着重分析下:
<script src="../sea-debug.js"></script> <script> seajs.config({ base: "../gallery/", alias:{ jquery: 'jquery/jquery-1.11.1' } }) seajs.use("../application.js") </script>
对于上述代码,application.js并没有合并seajs模块,我们通过seajs.use创建了一个匿名use模块,通过
var mod = Module.get(uri, isArray(ids) ? ids : [ids])
来实现,并设置依赖。在此处,依赖为[‘../application.js’];然后设置use模块的callback,并调用load函数加载依赖模块。在load函数中,use模块调用resolve函数解析出依赖的绝对路径,即[‘http://localhost:63342/mywork/js/application.js’],并创建一个新的Module表示该模块,这里用appMod表示,并以uri为key保存到modCache中。调用appMod.fetch加载对应的文件并设置回调函数onRequest,在application.js中定义了一个匿名模块define(function(){return {};}),此时模块的配置信息
meta = {
id: id,
uri: Module.resolve(id), // 绝对url
deps: deps,
factory: factory
}
中id=‘undefined’,url=’’,
meta.uri ? Module.save(meta.uri, meta) :
// Save information for "saving" work in the script onload event
anonymousMeta = meta
由于此时meta.uri为空,因此meta信息保存在全局变量anonymousMeta中,用于后续处理。
红色字体强调了在调用fetch时设置的回调onRequest函数,当文件加载完毕,执行onRequest,
function onRequest() {
delete fetchingList[requestUri]
fetchedList[requestUri] = true// Save meta data of anonymous module
if (anonymousMeta) {
Module.save(uri, anonymousMeta)
anonymousMeta = null
}// Call callbacks
var m, mods = callbackList[requestUri]
delete callbackList[requestUri]
while ((m = mods.shift())) m.load()
}
此时anonymousMeta已在模块define时设置,因此将该meta配置文件配置到uri对应的Module对象上,
Module.save = function(uri, meta) {
var mod = Module.get(uri)
// Do NOT override already saved modules
if (mod.status < STATUS.SAVED) {
mod.id = meta.id || uri
mod.dependencies = meta.deps || []
mod.factory = meta.factory
mod.status = STATUS.SAVED
}
}
由于meta.id=undefined,因此最终mod.id=uri。
对于通过define(id,deps,function(){})设置了id的具名模块,是根据id生成uri。在meta中,通过Module.resolve(id)完成,
Module.resolve = function(id, refUri) { if (!id) return "" id = parseAlias(id) id = parsePaths(id) id = parseVars(id) id = normalize(id) var uri = addBase(id, refUri) uri = parseMap(uri) return uri }
通过对id的一系列设置(别名解析,路径修正,变量解析以及添加扩展名,最终添加协议等)生成uri。
transport任务
transport任务是打包seajs模块的难点,上节提到了seajs模块的id和uri之间的关系,它们是由seajs来维护的。但是如果通过grunt对seajs进行打包,则模块之间的关系由transport来维护。通过transport生产的seajs模块,有一个显著的变化,即匿名模块变为了具名模块,并且设置了依赖模块。
下面通过配置项来讲解transport任务:
grunt.initConfig({ pkg: grunt.file.readJSON('package.json'), transport : { options : { path: ['.'], alias: '<%= pkg.spm.alias %>' // 注意在package.json中jquery的alias设置 }, utils: { // 存放引用的模块,设定模块名和依赖,模块的idleading要与在application中引用的路径一致 options: { idleading: '../dist/src/' }, files: [{ expand: true, cwd: 'lib/src', src: '*', filter: 'isFile', dest: '.build/lib/src' }] }, application : { options: { idleading: '../dist/' }, files: [ { expand: true, cwd : 'lib', src : 'application.js', filter : 'isFile', dest : '.build/lib' } ] } } }
在options中,设定了路径为‘.’,即相对于Gruntfile文件的当前路径,alias为package.json中定义的alias;在utils任务中,设置了idleading选项,最终模块的id = idleading + 文件名。值得注意的是idleading路径的设置,这里需要小心设置,它是根据引用最终打包后文件的html的位置决定的。最后,将lib/src下的所有文件设置完id和依赖后放到.build/lib/src下。application任务和utils任务类似,只是单独设置application.js文件的id和依赖。
着重讲解idleading的设置。我们计划将生成的文件(处理完依赖且合并压缩后的文件)放到dist文件夹下面,最终通过view/hello.html引用,
设置transport:util任务的idleading = ‘../dist/src/’,文件经过transport之后,lib/src/name.js文件会被设置并且保存到.build/lib/src中,此时name.js的模块名为’../dist/src/name’,依赖为[]。同理,lib/application.js保存到.build/lib中,并且模块名为’../dist/application’,依赖为[‘./src/util’,’jquery’,’./src/test’,’./src/name’]。然后经过合并压缩之后,生产最终的application.js文件,在view/hello.html中引用(开篇提到)。
在hello.html引用的application文件包含了5个模块,并且每个模块都有id和依赖,因此根据上节具名模块的id与uri的关系,可知道模块id影响到文件的加载。之所以在设置idleading = “../dist/”是根据hello.html的位置决定的。在Module.resolve(id)中,有一步骤为addBase,即有当前相对路径转换为绝对路径,而当前路径是相对于html的位置定义的,具体原因是html引入了seajs,seajs判断当前html的位置,设置为当前路径。这也正是idleading的设置为”../dist/”的原因。
下图可以印证了上文所述:
当然如果html的路径有变化,相应的idleading也要改变:
如果在view/layout/hello.html中引用文件,那么需要改变transport:util的idleading = ‘../../dist/lib/src’,transport:application的idleading = ‘../../dist/lib’,只有保证每个模块的uri正确,才能fetch文件并且执行相应的回调函数。
因此,对于transport任务而言,idleading的设置需要十分注意。
concat、uglify、clean任务
这两个任务很容易定义,而且grunt官网上就是以uglify为例讲解Gruntfile的配置,因此,这两个任务的配置我们有很多资料可以参考。我们使用通配符来匹配文件,使用expand来批量处理,也可以自定义过滤函数。废话不多说,呈上这两个任务的配置:
concat : { options : { separator: '/*-------每个文件的分割-------*/', banner: '/*! <%= pkg.name %> - v<%= pkg.version %> - ' + '<%= grunt.template.today("yyyy-mm-dd") %> */', footer: '/*-------合并文件的footer-------*/' }, utils: { src: ['.build/lib/src/*.js','!.build/lib/src/*-debug.js'], dest: '.build/util.js' }, application : { src: ['.build/lib/application.js','.build/util.js'], dest: 'dist/application.js' } }, uglify : { main : { files : { 'dist/application.min.js' : ['dist/application.js'] //对dist/application.js进行压缩,之后存入dist/application.js文件 } } },
clean : {
build : ['.build'] //清除.build文件
}
最终的Gruntfile文件定义如下:
module.exports = function(grunt){ grunt.initConfig({ pkg: grunt.file.readJSON('package.json'), transport : { options : { alias: '<%= pkg.spm.alias %>' // 注意在package.json中jquery的alias设置 }, utils: { // 存放引用的模块,设定模块名和依赖,模块的idleading要与在application中引用的路径一致 options: { idleading: '../../dist/src/' }, files: [{ expand: true, cwd: 'lib/src', src: '*', filter: 'isFile', dest: '.build/lib/src' }] }, application : { options: { idleading: '../../dist/' }, files: [ { expand: true, cwd : 'lib', src : 'application.js', filter : 'isFile', dest : '.build/lib' } ] } }, concat : { options : { separator: '/*-------每个文件的分割-------*/', banner: '/*! <%= pkg.name %> - v<%= pkg.version %> - ' + '<%= grunt.template.today("yyyy-mm-dd") %> */', footer: '/*-------合并文件的footer-------*/' }, utils: { src: ['.build/lib/src/*.js','!.build/lib/src/*-debug.js'], dest: '.build/util.js' }, application : { src: ['.build/lib/application.js','.build/util.js'], dest: 'dist/application.js' } }, uglify : { main : { files : { 'dist/application.min.js' : ['dist/application.js'] //对dist/application.js进行压缩,之后存入dist/application.js文件 } } }, clean : { build : ['.build'] //清除.build文件 } }); grunt.loadNpmTasks('grunt-cmd-transport'); grunt.loadNpmTasks('grunt-cmd-concat'); grunt.loadNpmTasks('grunt-contrib-uglify'); grunt.loadNpmTasks('grunt-contrib-clean'); // 默认被执行的任务列表。 grunt.registerTask('build',['transport','concat','uglify']) };
总结
通过对seajs的源码分析可以了解模块id与uri的关系,进而方便对grunt的transport调试。其实之所以用grunt对seajs模块进行打包会出现各种各样的问题,归根结底是路径错误。路径错误包括很多,比如模块依赖的路径错误,模块名错误,以及package.json的alias设置错误,最后,需要十分注意html文件的位置,因为seajs定义的cmd依赖于html文件当前位置。