摘要:源码分析四模块上一篇我们看到,通过对命令行传入的参数和配置文件里的配置项做了转换包装,然后传递给的模块去编译。这一篇我们来看看做了些什么事。在上面的分析中,我们看到最核心的其实就是实例,接下来我们就看下它的类的内部逻辑。
webpack 源码分析(四)——complier模块
上一篇我们看到,webpack-cli 通过 `yargs 对命令行传入的参数和配置文件里的配置项做了转换包装,然后传递给 webpack 的 compiler 模块去编译。
这一篇我们来看看 compiler 做了些什么事。
入口首先,我们来看看 webpack 是在什么地方引入 Compiler 这个模块的,在 webpack/lib/webpack.js 中我们发现,这个文件第一行就引入了它,并在下面的主要逻辑中使用了它:
const Compiler = require("./Compiler"); …… /* * options:这就是由 webpack-cli 转换包装后的配置项 * callback:第二篇分析时,发现 `webpack-cli` 只是传入了 options对象来获取 `compiler` 对象,并没有传入回调 */ const webpack = (options, callback) => { // 验证配置项的格式 // webpackOptionsSchema 是一个json格式的描述文件,它描述了webpack可接受的所有配置项及其格式 // options 是用户定义的webpack.config.*.js中导出的所有配置项 // validateSchema 使用 ajv 包,根据 webpackOptionsSchema 中定义的数据类型和描述来校验 options 中的各项配置项,最后返回一个错误对象,其中包含所有错误的配置项及说明 const webpackOptionsValidationErrors = validateSchema( webpackOptionsSchema, options ); // 如果存在配置项错误,则抛出所有错误 if (webpackOptionsValidationErrors.length) { throw new WebpackOptionsValidationError(webpackOptionsValidationErrors); } //判断配置项是否数组,如果是数组则使用MultiCompiler进行编译,否则使用Compiler模块进行编译,一般情况下,我们的 options 都是对象不是数组 let compiler; if (Array.isArray(options)) { compiler = new MultiCompiler(options.map(options => webpack(options))); } else if (typeof options === "object") { //使用默认配置项处理输入配置项 // WebpackOptionsDefaulter 继承自 OptionsDefaulter 类 // 在这个类里有两个对象: // * this.defaults : 用来存放配置项的值 // * this.config : 用来存放配置项的值的类型 // process 方法的处理逻辑: // * 如果defaults对象中存在,但在config对象中不存在,并且在options中也不存在,就从 defaults对象中复制一份到options中 // * 如果在config对象中存在并且值为 “call”,则说明它的值是一个方法调用,就直接调用,并将options作为参数传入 // * 如果在config对象中存在且值为 “make”,并且在 options中没有,则说明它是一个方法,就直接调用它,并将options作为参数传入,拿到返回值,赋值给options中对应的项 // * 如果在config对象中存在切值为 “append”,则取出options中对应的值,如果它不是数组,就把它重置为数组,并且把defaults对象中的值复制到数组中,最后将这个数组作为值赋值给options相应的项 options = new WebpackOptionsDefaulter().process(options); // new 一个compiler实例,参数为当前执行node命令的目录路径 // Compiler类继承自我们上一篇讲过的Tapable类,在构造函数中,初始化了各种类型的钩子实例 // compiler 类的内部逻辑,后面详解++++++++++++++++++++++ compiler = new Compiler(options.context); // WebpackOptionsDefaulter类处理后返回的options 复制给 compiler compiler.options = options; // 使用NodeEnviromentPlugin 类给compiler添加文件输入输出的能力 // NodeEnviromentPlugin的内部逻辑,后面详解++++++++++++++++++++++++++ new NodeEnvironmentPlugin().apply(compiler); // 如果配置项中有插件配置并且插件配置为数组 // 遍历插件数组,如果插件是一个函数,则使用complier来调用它,,并且将compier作为参数出入 // 否则,使用 WebpackPluginInstance 的 apply 方法来返回一个 void 值(相当于undefined) if (options.plugins && Array.isArray(options.plugins)) { for (const plugin of options.plugins) { if (typeof plugin === "function") { plugin.call(compiler, compiler); } else { plugin.apply(compiler); } } } // 触发 environment 同步钩子,这里的 call() 是我们讲过的Tapable钩子事件的触发方法 // environment 准备好之后,执行插件 compiler.hooks.environment.call(); // 触发 afterEnvironment 同步钩子 // environment 安装完成之后,执行插件 compiler.hooks.afterEnvironment.call(); // 使用 WebpackOptionsApply 类处理选项,返回处理过的选项对象 // WebpackOptionsApply 的处理逻辑,后面详解++++++++++++++ compiler.options = new WebpackOptionsApply().process(options, compiler); } else { //如果配置既不是数组类型也不是对象类型,抛出错误 throw new Error("Invalid argument: options"); } // 如果传入了回到函数 if (callback) { // 如果回调不是函数,抛出参数类型错误 if (typeof callback !== "function") { throw new Error("Invalid argument: callback"); } // 如果是监听模式,或者(配置是数组且数组中的项中有监听选项为true),则初始化监听配置,最后返回compiler实例的监听方法 // 实例的监听方法会返回一个 Watching类的实例,它本质上是一个观察者 if ( options.watch === true || (Array.isArray(options) && options.some(o => o.watch)) ) { const watchOptions = Array.isArray(options) ? options.map(o => o.watchOptions || {}) : options.watchOptions || {}; return compiler.watch(watchOptions, callback); } // 使用compiler的run方法运行回调 compiler.run(callback); } //返回compiler实例 return compiler; };
通过以上源码分析,我们得知,在 webpack() 中,实际上总共做了三件事:
对参数进行校验和规范化处理;
new 一个编译器实例并且初始化各种tapable钩子,并且在环境准备好和安装完成后执行响应的钩子
初始化监听。
在上面的分析中,我们看到最核心的其实就是compiler实例,接下来我们就看下它的类的内部逻辑。
compiler 分析 主体结构首先,我们来看主要结构:
/*…… *// 各种引入 // Compiler 类继承自Tapable class Compiler extends Tapable { constructor(context) {……}//构造函数执行各种初始化操作 watch(watchOptions, handler) {……}//监听初始化 run(callback) {……}// 运行编译 runAsChild(callback) {...} // 作为子编译进程运行 purgeInputFileSystem() {...} // 净化输入 emitAssets(compilation, callback) {...} // 发布资源 emitRecords(callback) {...} // 发布记录 readRecords(callback) {...} // 读取记录 createChildCompiler( compilation, compilerName, compilerIndex, outputOptions, plugins ) {...} // 创建子编译器 isChild() {return !!this.parentCompilation;} // 是否子汇编 createCompilation() {return new Compilation(this);} // 创建汇编实例 newCompilation(params) {return compilation;} // 根据参数创建新的汇编实例 createNormalModuleFactory() {return normalModuleFactory;} // 创建普通模块的工厂 createContextModuleFactory() {return contextModuleFactory;} // 创建上下文模块的工厂 newCompilationParams() {return params;} // 获取一个新的汇编参数对象 compile(callback) {} // 编译 } module.exports = Compiler; class SizeOnlySource extends Source {} // 定义了一个类,作用是+++++++++++
下一讲,我们将逐个攻破
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/110319.html
摘要:基本配置项基本配置项。的插件架构主要基于实现的,这个就是专注于事件的广播和操作。开启多进程,加快打包速度。 这次我们主要研究的是webpack框架的相关知识,webpack是一个打包构建的前端框架,用于解决前端开发的模块化问题。 应用场景和纵向比较 说到webpack,肯定你还会想到gulp和grunt这些框架,那么webpack是做什么的呢?他和其他的框架有什么区别呢?我们一起来分析...
摘要:不直接使用的原因很简单首先构建一次实在太慢了,特别是有几十个页面存在的情况下,另一个原因是我只是想拿到资源依赖,我根本不想对整个前端进行一次构建,也不想生成任何。这就达到了本文题目中目的,用十分之一的构建时间做一场页面静态资源依赖分析。原文链接 作者:梯田 前言: 所谓【静态资源依赖分析】,指的是可以通过分析页面资源后,可以以 json 数据或者图表的方式拿到页面资源间的依赖关系。 比如 c...
摘要:类定义了方法,用于注册插件,将插件及其回调函数以的形式保存在内部对象中又定义了,等方法来触发插件的回调函数。所以当类继承类后,也同样具有注册插件和触发回调函数的功能。 说起webpack,相信对于前端工程师们而言早已经不是什么新鲜的事物。但是由于webpack有着较为复杂和灵活的配置项,所以给人的第一感觉是难以完全掌握。 这次就跟大家分享一下有关webpack构建过程的相关知识,希望对...
摘要:以为例,编写来帮助我们完成重复的工作编译压缩我只要执行一下就可以检测到文件的变化,然后为你执行一系列的自动化操作,同样的操作也发生在这些的预处理器上。的使用是针对第三方类库使用各种模块化写法以及语法。 showImg(https://segmentfault.com/img/bVbtZYK); 一:前端工程化的发展 很久以前,互联网行业有个职位叫做 软件开发工程师 在那个时代,大家可能...
摘要:需要得到最后一个产生的处理结果。这个处理结果应该是或者被转换为一个,代表了模块的源码。另外还可以传递一个可选的结果格式为对象。在异步模式中,必须调用,来指示等待异步结果,它会返回回调函数,随后必须返回并且调用该回调函数。 准备工作 安装 Node.js, 建议安装LTS长期支持版本 mkdir webpack and cd webpack and npm init -y npm ...
阅读 715·2023-04-25 19:40
阅读 3374·2023-04-25 17:41
阅读 2976·2021-11-11 11:01
阅读 2523·2019-08-30 15:55
阅读 3200·2019-08-30 15:44
阅读 1335·2019-08-29 14:07
阅读 459·2019-08-29 11:23
阅读 1293·2019-08-27 10:54