You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
loadLoader(currentLoaderObject,function(err){varfn=currentLoaderObject.pitch;// 获取 pitch 函数currentLoaderObject.pitchExecuted=true;if(!fn)returniteratePitchingLoaders(options,loaderContext,callback);// 如果这个 loader 没有提供 pitch 函数,那么直接跳过// 开始执行 pitch 函数runSyncOrAsync(fn,loaderContext,[loaderContext.remainingRequest,loaderContext.previousRequest,currentLoaderObject.data={}],function(err){if(err)returncallback(err);varargs=Array.prototype.slice.call(arguments,1);// Determine whether to continue the pitching process based on// argument values (as opposed to argument presence) in order// to support synchronous and asynchronous usages.// 根据是否有参数返回来判断是否向下继续进行 pitch 函数的执行varhasArg=args.some(function(value){returnvalue!==undefined;});if(hasArg){loaderContext.loaderIndex--;iterateNormalLoaders(options,loaderContext,args,callback);}else{iteratePitchingLoaders(options,loaderContext,callback);}});})
functioniteratePitchingLoaders(){
...
if(loaderContext.loaderIndex>=loaderContext.loaders.length)returnprocessResource(options,loaderContext,callback);
...
}functionprocessResource(options,loaderContext,callback){// set loader index to last loaderloaderContext.loaderIndex=loaderContext.loaders.length-1;varresourcePath=loaderContext.resourcePath;if(resourcePath){loaderContext.addDependency(resourcePath);// 添加依赖options.readResource(resourcePath,function(err,buffer){if(err)returncallback(err);options.resourceBuffer=buffer;iterateNormalLoaders(options,loaderContext,[buffer],callback);});}else{iterateNormalLoaders(options,loaderContext,[null],callback);}}
在 processResouce 方法内部调用 node API readResouce 读取 module 对应路径的文本内容,调用 iterateNormalLoaders 方法,开始进入 loader normal 方法的执行阶段。
上篇文章主要讲了 loader 的配置,匹配相关的机制。这篇主要会讲当一个 module 被创建之后,使用 loader 去处理这个 module 内容的流程机制。首先我们来总体的看下整个的流程:
在 module 一开始构建的过程中,首先会创建一个 loaderContext 对象,它和这个 module 是一一对应的关系,而这个 module 所使用的所有 loaders 都会共享这个 loaderContext 对象,每个 loader 执行的时候上下文就是这个 loaderContext 对象,所以可以在我们写的 loader 里面通过 this 来访问。
当 loaderContext 初始化完成后,开始调用 runLoaders 方法,这个时候进入到了 loaders 的执行阶段。runLoaders 方法是由loader-runner这个独立的 NPM 包提供的方法,那我们就一起来看下 runLoaders 方法内部是如何运行的。
首先根据传入的参数完成进一步的处理,同时对于 loaderContext 对象上的属性做进一步的拓展:
这里稍微总结下就是在 runLoaders 方法的初期会对相关参数进行初始化的操作,特别是将 loaderContext 上的部分属性改写为 getter/setter 函数,这样在不同的 loader 执行的阶段可以动态的获取一些参数。
接下来开始调用 iteratePitchingLoaders 方法执行每个 loader 上提供的 pitch 函数。大家写过 loader 的话应该都清楚,每个 loader 可以挂载一个 pitch 函数,每个 loader 提供的 pitch 方法和 loader 实际的执行顺序正好相反。这块的内容在 webpack 文档上也有详细的说明(请戳我)。
这些 pitch 函数并不是用来实际处理 module 的内容的,主要是可以利用 module 的 request,来做一些拦截处理的工作,从而达到在 loader 处理流程当中的一些定制化的处理需要,有关 pitch 函数具体的实战可以参见下一篇文档[Webpack 高手进阶-loader 实战] TODO: 链接
每次执行 pitch 函数前,首先根据 loaderIndex 来获取当前需要执行的 loader (currentLoaderObject),调用 loadLoader 函数来加载这个 loader,loadLoader 内部兼容了 SystemJS,ES Module,CommonJs 这些模块定义,最终会将 loader 提供的 pitch 方法和普通方法赋值到 currentLoaderObject 上:
当 loader 加载完后,开始执行 loadLoader 的回调:
这里出现了一个 runSyncOrAsync 方法,放到后文去讲,开始执行 pitch 函数,当 pitch 函数执行完后,执行传入的回调函数。我们看到回调函数里面会判断接收到的参数的个数,除了第一个 err 参数外,如果还有其他的参数(这些参数是 pitch 函数执行完后传入回调函数的),那么会直接进入 loader 的 normal 方法执行阶段,并且会直接跳过后面的 loader 执行阶段。如果 pitch 函数没有返回值的话,那么进入到下一个 loader 的 pitch 函数的执行阶段。让我们再回到 iteratePitchingLoaders 方法内部,当所有 loader 上面的 pitch 函数都执行完后,即 loaderIndex 索引值 >= loader 数组长度的时候:
在 processResouce 方法内部调用 node API readResouce 读取 module 对应路径的文本内容,调用 iterateNormalLoaders 方法,开始进入 loader normal 方法的执行阶段。
在 iterateNormalLoaders 方法内部就是依照从右到左的顺序(正好与 pitch 方法执行顺序相反)依次执行每个 loader 上的 normal 方法。loader 不管是 pitch 方法还是 normal 方法的执行可为同步的,也可设为异步的。这里说下 normal 方法的,一般如果你写的 loader 里面可能涉及到计算量较大的情况时,可将你的 loader 异步化,在你 loader 方法里面调用
this.async
方法,返回异步的回调函数,当你 loader 内部实际的内容执行完后,可调用这个异步的回调来进入下一个 loader 的执行。除了调用 this.async 来异步化 loader 之外,还有一种方式就是在你的 loader 里面去返回一个 promise,只有当这个 promise 被 resolve 之后,才会调用下一个 loader(具体实现机制见下文):
这里还有一个地方需要注意的就是,上下游 loader 之间的数据传递过程中,如果下游的 loader 接收到的参数为一个,那么可以在上一个 loader 执行结束后,如果是同步就直接 return 出去:
如果是异步就直接调用异步回调传递下去(参见上面 loader 异步化)。如果下游 loader 接收的参数多于一个,那么上一个 loader 执行结束后,如果是同步那么就需要调用 loaderContext 提供的 callback 函数:
如果是异步的还是继续调用异步回调函数传递下去(参见上面 loader 异步化)。具体的执行机制涉及到上文还没讲到的 runSyncOrAsync 方法,它提供了上下游 loader 调用的接口:
以上就是对于 module 在构建过程中 loader 执行流程的源码分析。可能平时在使用 webpack 过程了解相关的 loader 执行规则和策略,再配合这篇对于内部机制的分析,应该会对 webpack loader 的使用有更加深刻的印象。
The text was updated successfully, but these errors were encountered: