Webpack 源码(一)—— Tapable 和 事件流

2017-01-10 10:03:00来源:segmentfault作者:JSCON简时空人点击

1、Tapable

Tap 的英文单词解释,除了最常用的 点击 手势之外,还有一个意思是 水龙头 —— 在 webpack 中指的是后一种;


Webpack 可以认为是一种基于事件流的编程范例,内部的工作流程都是基于 插件 机制串接起来;


而将这些插件粘合起来的就是webpack自己写的基础类 Tapable 是,plugin方法就是该类暴露出来的;


后面我们将看到核心的对象 Compiler、Compilation 等都是继承于该对象


基于该类规范而其的 Webpack 体系保证了插件的有序性,使得整个系统非常有弹性,扩展性很好;然而有一个致命的缺点就是调试、看源码真是很痛苦,各种跳来跳去;(基于事件流的写法,和程序语言中的 goto 语句很类似)


把这个仓库下载,使用 Webstorm 进行调试,test 目录是很好的教程入口;


Tapable.plugin():相当于把对象归类到名为 name 的对象下,以array的形式;所有的插件都存在私有变量 _plugin 变量中;



接下来我们简单节选几个函数分析一下:


1.1、apply 方法

该方法最普通也是最常用的,看一下它的定义:

Tapable.prototype.apply = function apply() {
for(var i = 0; i < arguments.length; i++) {
arguments[i].apply(this);
}
};

毫无悬念,就是 挨个顺序 执行传入到该函数方法中对象的 apply 方法;通常传入该函数的对象也是 Tapable 插件 对象,因此必然也存在 apply 方法;(Webpack 的插件就是Tapable对象,因此必须要提供apply方法 )


只是更改上下文为当前 this


因此当前这里最大的作用就是传入当前 Tapable 的上下文


1.2、 applyPluginsAsync(name,...other,callback)
// 模拟两个插件
var _plugins = {
"emit":[
function(a,b,cb){
setTimeout(()=>{
console.log('1',a,b);
cb();
},1000);
},
function(a,b,cb){
setTimeout(()=>{
console.log('2',a,b);
cb();
},500)
}
]
}applyPluginsAsync("emit",'aaaa','bbbbb',function(){console.log('end')});// 输出结果:// 1 aaaa bbbbb
// 2 aaaa bbbbb
//end

我们看到,虽然第一个插件是延后 1000ms 执行,第二个则是延后 500ms,但在真正执行的时候,是严格按照顺序执行的;每个插件需要在最后显式调用cb()通知下一个插件的运行;


这里需要注意每个插件的形参的个数都要一致,且最后一个必须是cb()方法,用于唤起下一个插件的运行;cb的第一个参数是err,如果该参数不为空,就直接调用最后callback,中断后续插件的运行;


1.3、 applyPluginsParallel(name,...other,callback)

大部分代码和 applyPluginsAsync 有点儿类似


这个 applyPluginsParallel 主要功能和 最简单的 applyPlugins 方法比较相似,无论如何都会让所有注册的插件运行一遍;


只是相比 applyPlugins 多了一个额外的功能,它最后 提供一个 callback 函数,这个 callback 的函数比较倔强,如果所有的插件x都正常执行,且最后都cb(),则会在最后执行callback里的逻辑;不过,一旦其中某个插件运行出错,就会调用这个callback(err),之后就算插件有错误也不会再调用该callback函数;

var _plugins = {
"emit":[
function(a,b,cb){
setTimeout(()=>{
console.log('1',a,b);
cb(null,'e222','33333');
},1000);
},
function(a,b,cb){
setTimeout(()=>{
console.log('2',a,b);
cb(null,'err');
},500)
}
]
}applyPluginsParallel("emit",'aaaa','bbbbb',function(a,b){console.log('end',a,b)});// 输出结果:// 2 aaaa bbbbb
// 1 aaaa bbbbb
//end undefined undefined

上面的两个插件都是调用了 cb,且第一个参数是 null(表示没有错误),所以最后能输出 callback 函数中的 console 内容;


如果注释两个插件中任何一个 cb() 调用,你会发现最后的 callback 没有执行;


如果让 第二个 cb()的第一个值不是 null,比如 cb('err'),则 callback 之后输出这个错误,之后再也不会调用此 callback:


var _plugins = {
"emit":[
function(a,b,cb){
setTimeout(()=>{
console.log('1',a,b);
cb('e222','33333');
},1000);
},
function(a,b,cb){
setTimeout(()=>{
console.log('2',a,b);
cb('err');
},500)
}
]
}// 输出结果:// 2 aaaa bbbbb
// end err undefined
// 1 aaaa bbbbb
1.4、 applyPluginsWaterfall(name, init, callback)

顾名思义,这个方法相当于是 瀑布式 调用,给第一个插件传入初始对象 init,然后经过第一个插件调用之后会获得一个结果对象,该结果对象会传给下一个插件 作为初始值,直到最后调用完毕,最后一个插件的直接结果传给 callback 作为初始值;


1.5、 applyPluginsParallelBailResult(name,...other,callback)

这个方法应该是所有方法中最难理解的;


首先它的行为和 applyPluginsParallel 非常相似,首先会 无论如何都会让所有注册的插件运行一遍(根据注册的顺序);


为了让 callback 执行,其前提条件是每个插件都需要调用 cb();


但其中的 callback 只会执行一次(当传给cb的值不是undefined/null 的时候),这一次执行顺序是插件定义顺序有关,而跟每个插件中的 cb() 执行时间无关的;

var _plugins = {
"emit":[
function(a,b,cb){
setTimeout(()=>{
console.log('1',a,b);
cb();
},1000);
},
function(a,b,cb){
setTimeout(()=>{
console.log('2',a,b);
cb();
},500)
},
function(a,b,cb){
setTimeout(()=>{
console.log('3',a,b);
cb();
},1500)
}
]
}applyPluginsParallelBailResult("emit",'aaaa','bbbbb',function(a,b){console.log('end',a,b)});// 运行结果// 2 aaaa bbbbb
// 1 aaaa bbbbb
// 3 aaaa bbbbb
// end undefined undefined

这是最普通的运行情况,我们稍微调整一下(注意三个插件运行的顺序2-1-3),分别给cb传入有效的值:

var _plugins = {
"emit":[
function(a,b,cb){
setTimeout(()=>{
console.log('1',a,b);
cb('1');
},1000);
},
function(a,b,cb){
setTimeout(()=>{
console.log('2',a,b);
cb('2');
},500)
},
function(a,b,cb){
setTimeout(()=>{
console.log('3',a,b);
cb('3');
},1500)
}
]
}
applyPluginsParallelBailResult("emit",'aaaa','bbbbb',function(a,b){console.log('end',a,b)});
// 运行结果// 2 aaaa bbbbb
// 1 aaaa bbbbb
// end 1 undefined
// 3 aaaa bbbbb

可以发现第1个插件 cb('1') 执行了,后续的 cb('2') 和 cb('3') 都给忽略了;


这是因为插件注册顺序是 1-2-3,虽然运行的时候顺序是 2-1-3,但所运行的还是 1 对应的 cb;所以,就算1执行的速度最慢(比如把其setTimeout的值设置成 2000),运行的 cb 仍然是1对应的cb;



其中涉及的魔法是 闭包,传入的i就是和注册顺序绑定了


这样一说明,你会发现 applyPluginsParallel 的 cb 执行时机是和执行时间有关系的,你可以自己验证一下;



1.6、总结

总结一下,Tapable 就相当于是一个 事件管家,它所提供的 plugin 方法类似于 addEventListen 监听事件,apply 方法类似于事件触发函数 trigger;



2、Webpack 中的事件流

既然 Webpack 是基于 Tapable 搭建起来的,那么我们看一下 Webpack 构建一个模块的基本事件流是如何的;


我们在 Webpack 库中的 Tapable.js 中每个方法中新增 console 语句打出日志,就能找出所有关键的事件名字:



打印结果:(这里只列举了简单的事件流程,打包不同的入口文件会有所差异,但 事件出现的先后顺序是固定的 )
































































































































































































































































































































































































































































































































































































类型名字事件名
[C]applyPluginsBailResultentry-option
[A]applyPluginsafter-plugins
[A]applyPluginsafter-resolvers
[A]applyPluginsenvironment
[A]applyPluginsafter-environment
[D]applyPluginsAsyncSeriesrun
[A]applyPluginsnormal-module-factory
[A]applyPluginscontext-module-factory
[A]applyPluginscompile
[A]applyPluginsthis-compilation
[A]applyPluginscompilation
[F]applyPluginsParallelmake
[E]applyPluginsAsyncWaterfallbefore-resolve
[B]applyPluginsWaterfallfactory
[B]applyPluginsWaterfallresolver
[A]applyPluginsresolve
[A]applyPluginsresolve-step
[G]applyPluginsParallelBailResultfile
[G]applyPluginsParallelBailResultdirectory
[A]applyPluginsresolve-step
[G]applyPluginsParallelBailResultresult
[E]applyPluginsAsyncWaterfallafter-resolve
[C]applyPluginsBailResultcreate-module
[B]applyPluginsWaterfallmodule
[A]applyPluginsbuild-module
[A]applyPluginsnormal-module-loader
[C]applyPluginsBailResultprogram
[C]applyPluginsBailResultstatement
[C]applyPluginsBailResultevaluate CallExpression
[C]applyPluginsBailResultvar data
[C]applyPluginsBailResultevaluate Identifier
[C]applyPluginsBailResultevaluate Identifier require
[C]applyPluginsBailResultcall require
[C]applyPluginsBailResultevaluate Literal
[C]applyPluginsBailResultcall require:amd:array
[C]applyPluginsBailResultevaluate Literal
[C]applyPluginsBailResultcall require:commonjs:item
[C]applyPluginsBailResultstatement
[C]applyPluginsBailResultevaluate MemberExpression
[C]applyPluginsBailResultevaluate Identifier console.log
[C]applyPluginsBailResultcall console.log
[C]applyPluginsBailResultexpression console.log
[C]applyPluginsBailResultexpression console
[A]applyPluginssucceed-module
[E]applyPluginsAsyncWaterfallbefore-resolve
[B]applyPluginsWaterfallfactory
[A]applyPluginsbuild-module
[A]applyPluginssucceed-module
[A]applyPluginsseal
[A]applyPluginsoptimize
[A]applyPluginsoptimize-modules
[A]applyPluginsafter-optimize-modules
[A]applyPluginsoptimize-chunks
[A]applyPluginsafter-optimize-chunks
[D]applyPluginsAsyncSeriesoptimize-tree
[A]applyPluginsafter-optimize-tree
[C]applyPluginsBailResultshould-record
[A]applyPluginsrevive-modules
[A]applyPluginsoptimize-module-order
[A]applyPluginsbefore-module-ids
[A]applyPluginsoptimize-module-ids
[A]applyPluginsafter-optimize-module-ids
[A]applyPluginsrecord-modules
[A]applyPluginsrevive-chunks
[A]applyPluginsoptimize-chunk-order
[A]applyPluginsbefore-chunk-ids
[A]applyPluginsoptimize-chunk-ids
[A]applyPluginsafter-optimize-chunk-ids
[A]applyPluginsrecord-chunks
[A]applyPluginsbefore-hash
[A]applyPluginshash
[A]applyPluginshash
[A]applyPluginshash
[A]applyPluginshash
[A]applyPluginshash-for-chunk
[A]applyPluginschunk-hash
[A]applyPluginsafter-hash
[A]applyPluginsbefore-chunk-assets
[B]applyPluginsWaterfallglobal-hash-paths
[C]applyPluginsBailResultglobal-hash
[B]applyPluginsWaterfallbootstrap
[B]applyPluginsWaterfalllocal-vars
[B]applyPluginsWaterfallrequire
[B]applyPluginsWaterfallmodule-obj
[B]applyPluginsWaterfallmodule-require
[B]applyPluginsWaterfallrequire-extensions
[B]applyPluginsWaterfallasset-path
[B]applyPluginsWaterfallstartup
[B]applyPluginsWaterfallmodule-require
[B]applyPluginsWaterfallrender
[B]applyPluginsWaterfallmodule
[B]applyPluginsWaterfallrender
[B]applyPluginsWaterfallpackage
[B]applyPluginsWaterfallmodule
[B]applyPluginsWaterfallrender
[B]applyPluginsWaterfallpackage
[B]applyPluginsWaterfallmodules
[B]applyPluginsWaterfallrender-with-entry
[B]applyPluginsWaterfallasset-path
[B]applyPluginsWaterfallasset-path
[A]applyPluginschunk-asset
[A]applyPluginsadditional-chunk-assets
[A]applyPluginsrecord
[D]applyPluginsAsyncSeriesadditional-assets
[D]applyPluginsAsyncSeriesoptimize-chunk-assets
[A]applyPluginsafter-optimize-chunk-assets
[D]applyPluginsAsyncSeriesoptimize-assets
[A]applyPluginsafter-optimize-assets
[D]applyPluginsAsyncSeriesafter-compile
[C]applyPluginsBailResultshould-emit
[D]applyPluginsAsyncSeriesemit
[B]applyPluginsWaterfallasset-path
[D]applyPluginsAsyncSeriesafter-emit
[A]applyPluginsdone

内容较多,依据源码内容的编排,可以将上述进行分层;大粒度的事件流如下:



而其中 make、 seal 和 emit 阶段比较核心(包含了很多小粒度的事件),后续会继续展开讲解;


这里罗列一下关键的事件节点:

entry-option:初始化options


run:开始编译


make:从entry开始递归的分析依赖,对每个依赖模块进行build


before-resolve - after-resolve: 对其中一个模块位置进行解析


build-module :开始构建 (build) 这个module,这里将使用文件对应的loader加载


normal-module-loader:对用loader加载完成的module(是一段js代码)进行编译,用 acorn 编译,生成ast抽象语法树。


program: 开始对ast进行遍历,当遇到require等一些调用表达式时,触发 call require 事件的handler执行,收集依赖,并。如:AMDRequireDependenciesBlockParserPlugin等


seal: 所有依赖build完成,下面将开始对chunk进行优化,比如合并,抽取公共模块,加hash


optimize-chunk-assets:压缩代码,插件 UglifyJsPlugin 就放在这个阶段


bootstrap: 生成启动代码


emit: 把各个chunk输出到结果文件

3、参考文章

本系列的源码阅读,以下几篇文章给了很多启发和思路,其中 webpack 源码解析 和 细说 webpack 之流程篇 尤为突出,推荐阅读;

webpack 源码解析


细说 webpack 之流程篇


WebPack学习:WebPack内置Plugin


如何写一个webpack插件


plugins官方文档:


最新文章

123

最新摄影

微信扫一扫

第七城市微信公众平台