-
WebpackOptionsApply
定义在lib/WebpackOptionsApply.js
文件,内部根据entry
配置决定注入entry
相关的插件,包括:DllEntryPlugin
、DynamicEntryPlugin
、EntryPlugin
、PrefetchPlugin
、ProgressPlugin
、ContainerPlugin
-
Entry
相关插件,如lib/EntryPlugin.js
的EntryPlugin
监听compiler.make
钩子 -
lib/compiler.js
的compile
函数内调用this.hooks.make.callAsync
-
触发
EntryPlugin
的make
回调,在回调中执行compilation.addEntry
函数 -
compilation.addEntry
函数内部经过一坨与主流程无关的hook
之后,再调用handleModuleCreate
函数,正式开始构建内容
这个过程需要在 webpack 初始化的时候预埋下各种插件,经历 4 个文件,7次跳转才开始进入主题,前戏太足了,如果读者对 webpack 的概念、架构、组件没有足够了解时,源码阅读过程会很痛苦。
关于这个问题,我在文章最后总结了一些技巧和建议,有兴趣的可以滑到附录阅读模块。
构建阶段
基本流程
你有没有思考过这样的问题:
-
Webpack 编译过程会将源码解析为 AST 吗?webpack 与 babel 分别实现了什么?
-
Webpack 编译过程中,如何识别资源对其他资源的依赖?
-
相对于 grunt、gulp 等流式构建工具,为什么 webpack 会被认为是新一代的构建工具?
这些问题,基本上在构建阶段都能看出一些端倪。构建阶段从 entry
开始递归解析资源与资源的依赖,在 compilation
对象内逐步构建出 module
集合以及 module
之间的依赖关系,核心流程:
解释一下,构建阶段从入口文件开始:
-
调用
handleModuleCreate
,根据文件类型构建module
子类 -
调用 loader-runner 仓库的
runLoaders
转译module
内容,通常是从各类资源类型转译为 JavaScript 文本 -
调用 acorn 将 JS 文本解析为AST
-
遍历 AST,触发各种钩子
-
- 在
HarmonyExportDependencyParserPlugin
插件监听exportImportSpecifier
钩子,解读 JS 文本对应的资源依赖
- 在
-
调用
module
对象的addDependency
将依赖对象加入到module
依赖列表中 -
AST 遍历完毕后,调用
module.handleParseResult
处理模块依赖 -
对于
module
新增的依赖,调用handleModuleCreate
,控制流回到第一步 -
所有依赖都解析完毕后,构建阶段结束
这个过程中数据流 module => ast => dependences => module
,先转 AST 再从 AST 找依赖。这就要求 loaders
处理完的最后结果必须是可以被 acorn 处理的标准 JavaScript 语法,比如说对于图片,需要从图像二进制转换成类似于 export default "data:image/png;base64,xxx"
这类 base64 格式或者 export default "http://xxx"
这类 url 格式。
compilation
按这个流程递归处理,逐步解析出每个模块的内容以及 module
依赖关系,后续就可以根据这些内容打包输出。
示例:层级递进
假如有如下图所示的文件依赖树:
其中 index.js
为 entry
文件,依赖于 a/b 文件;a 依赖于 c/d 文件。初始化编译环境之后,EntryPlugin
根据 entry
配置找到 index.js
文件,调用 compilation.addEntry
函数触发构建流程,构建完毕后内部会生成这样的数据结构:
此时得到 module[index.js]
的内容以及对应的依赖对象 dependence[a.js]
、dependence[b.js]
。OK,这就得到下一步的线索:a.js、b.js,根据上面流程图的逻辑继续调用 module[index.js]
的 handleParseResult
函数,继续处理 a.js、b.js 文件,递归上述流程,进一步得到 a、b 模块:
从 a.js 模块中又解析到 c.js/d.js 依赖,于是再再继续调用 module[a.js]
的 handleParseResult
,再再递归上述流程:
到这里解析完所有模块后,发现没有更多新的依赖,就可以继续推进,进入下一步。
总结
回顾章节开始时提到的问题:
-
Webpack 编译过程会将源码解析为 AST 吗?webpack 与 babel 分别实现了什么?
-
- 构建阶段会读取源码,解析为 AST 集合。
-
Webpack 读出 AST 之后仅遍历 AST 集合;babel 则对源码做等价转换
-
Webpack 编译过程中,如何识别资源对其他资源的依赖?
-
- Webpack 遍历 AST 集合过程中,识别
require/ import
之类的导入语句,确定模块对其他资源的依赖关系
- Webpack 遍历 AST 集合过程中,识别
-
相对于 grant、gulp 等流式构建工具,为什么 webpack 会被认为是新一代的构建工具?
-
- Grant、Gulp 仅执行开发者预定义的任务流;而 webpack 则深入处理资源的内容,功能上更强大
生成阶段
基本流程
构建阶段围绕 module
展开,生成阶段则围绕 chunks
展开。经过构建阶段之后,webpack 得到足够的模块内容与模块关系信息,接下来开始生成最终资源了。代码层面,就是开始执行 compilation.seal
函数:
// 取自 webpack/lib/compiler.js
compile(callback) {
const params = this.newCompilationParams();
this.hooks.beforeCompile.callAsync(params, err => {
// …
const compilation = this.newCompilation(params);
this.hooks.make.callAsync(compilation, err => {
// …
this.hooks.finishMake.callAsync(compilation, err => {
// …
process.nextTick(() => {
compilation.finish(err => {
compilation.seal(err => {…});
});
});
});
});
});
}
seal
原意密封、上锁,我个人理解在 webpack 语境下接近于 “将模块装进蜜罐” 。seal
函数主要完成从 module
到 chunks
的转化,核心流程:
简单梳理一下:
-
构建本次编译的
ChunkGraph
对象; -
遍历
compilation.modules
集合,将module
按entry/动态引入
的规则分配给不同的Chunk
对象; -
compilation.modules
集合遍历完毕后,得到完整的chunks
集合对象,调用createXxxAssets
方法 -
createXxxAssets
遍历module/chunk
,调用compilation.emitAssets
方法将assets
信息记录到compilation.assets
对象中 -
触发
seal
回调,控制流回到compiler
对象
这一步的关键逻辑是将 module
按规则组织成 chunks
,webpack 内置的 chunk
封装规则比较简单:
-
entry
及 entry 触达到的模块,组合成一个chunk
-
使用动态引入语句引入的模块,各自组合成一个
chunk
chunk
是输出的基本单位,默认情况下这些 chunks
与最终输出的资源一一对应,那按上面的规则大致上可以推导出一个 entry
会对应打包出一个资源,而通过动态引入语句引入的模块,也对应会打包出相应的资源,我们来看个示例。
示例:多入口打包
假如有这样的配置:
const path = require(“path”);
module.exports = {
mode: “development”,
context: path.join(__dirname),
entry: {
a: “./src/index-a.js”,
b: “./src/index-b.js”,
},
output: {
filename: “[name].js”,
path: path.join(__dirname, “./dist”),
},
devtool: false,
target: “web”,
plugins: [],
};
实例配置中有两个入口,对应的文件结构:
index-a
依赖于c,且动态引入了 e;index-b
依赖于 c/d 。根据上面说的规则:
-
entry
及entry触达到的模块,组合成一个 chunk -
使用动态引入语句引入的模块,各自组合成一个 chunk
生成的 chunks
结构为:
也就是根据依赖关系,chunk[a]
包含了 index-a/c
两个模块;chunk[b]
包含了 c/index-b/d
三个模块;chunk[e-hash]
为动态引入 e
对应的 chunk。
不知道大家注意到没有,chunk[a]
与 chunk[b]
同时包含了 c,这个问题放到具体业务场景可能就是,一个多页面应用,所有页面都依赖于相同的基础库,那么这些所有页面对应的 entry
都会包含有基础库代码,这岂不浪费?为了解决这个问题,webpack 提供了一些插件如 CommonsChunkPlugin
、SplitChunksPlugin
,在基本规则之外进一步优化 chunks
结构。
SplitChunksPlugin
的作用
SplitChunksPlugin
是 webpack 架构高扩展的一个绝好的示例,我们上面说了 webpack 主流程里面是按 entry / 动态引入
两种情况组织 chunks
的,这必然会引发一些不必要的重复打包,webpack 通过插件的形式解决这个问题。
回顾 compilation.seal
函数的代码,大致上可以梳理成这么4个步骤:
-
遍历
compilation.modules
,记录下模块与chunk
关系 -
触发各种模块优化钩子,这一步优化的主要是模块依赖关系
-
遍历
module
构建 chunk 集合 -
触发各种优化钩子
上面 1-3 都是预处理 + chunks 默认规则的实现,不在我们讨论范围,这里重点关注第4个步骤触发的 optimizeChunks
钩子,这个时候已经跑完主流程的逻辑,得到 chunks
集合,SplitChunksPlugin
正是使用这个钩子,分析 chunks
集合的内容,按配置规则增加一些通用的 chunk :
module.exports = class SplitChunksPlugin {
constructor(options = {}) {
// …
}
_getCacheGroup(cacheGroupSource) {
// …
}
apply(compiler) {
// …
compiler.hooks.thisCompilation.tap(“SplitChunksPlugin”, (compilation) => {
// …
compilation.hooks.optimizeChunks.tap(
{
name: “SplitChunksPlugin”,
stage: STAGE_ADVANCED,
},
(chunks) => {
// …
}
);
});
}
};
理解了吗?webpack 插件架构的高扩展性,使得整个编译的主流程是可以固化下来的,分支逻辑和细节需求“外包”出去由第三方实现,这套规则架设起了庞大的 webpack 生态,关于插件架构的更多细节,下面 plugin
部分有详细介绍,这里先跳过。
写入文件系统
经过构建阶段后,compilation
会获知资源模块的内容与依赖关系,也就知道“输入”是什么;而经过 seal
阶段处理后, compilation
则获知资源输出的图谱,也就是知道怎么“输出”:哪些模块跟那些模块“绑定”在一起输出到哪里。seal
后大致的数据结构:
compilation = {
// …
modules: [
/* … */
],
chunks: [
{
id: “entry name”,
files: [“output file name”],
hash: “xxx”,
runtime: “xxx”,
entryPoint: {xxx}
// …
},
// …
],
};
seal
结束之后,紧接着调用 compiler.emitAssets
函数,函数内部调用 compiler.outputFileSystem.writeFile
方法将 assets
集合写入文件系统,实现逻辑比较曲折,但是与主流程没有太多关系,所以这里就不展开讲了。
资源形态流转
OK,上面已经把逻辑层面的构造主流程梳理完了,这里结合资源形态流转的角度重新考察整个过程,加深理解:
-
compiler.make
阶段: -
entry
文件以dependence
对象形式加入compilation
的依赖列表,dependence
对象记录有entry
的类型、路径等信息
-
根据
dependence
调用对应的工厂函数创建module
对象,之后读入module
对应的文件内容,调用loader-runner
对内容做转化,转化结果若有其它依赖则继续读入依赖资源,重复此过程直到所有依赖均被转化为module
-
compilation.seal
阶段: -
- 遍历
module
集合,根据entry
配置及引入资源的方式,将module
分配到不同的chunk
- 遍历
-
遍历
chunk
集合,调用compilation.emitAsset
方法标记chunk
的输出规则,即转化为assets
集合 -
compiler.emitAssets
阶段: -
- 将
assets
写入文件系统
- 将
Plugin 解析
=========
网上不少资料将 webpack 的插件架构归类为“事件/订阅”模式,我认为这种归纳有失偏颇。订阅模式是一种松耦合架构,发布器只是在特定时机发布事件消息,订阅者并不或者很少与事件直接发生交互,举例来说,我们平常在使用 HTML 事件的时候很多时候只是在这个时机触发业务逻辑,很少调用上下文操作。而 webpack 的钩子体系是一种强耦合架构,它在特定时机触发钩子时会附带上足够的上下文信息,插件定义的钩子回调中,能也只能与这些上下文背后的数据结构、接口交互产生 side effect,进而影响到编译状态和后续流程。
学习插件架构,需要理解三个关键问题:
-
WHAT: 什么是插件
-
WHEN: 什么时间点会有什么钩子被触发
-
HOW: 在钩子回调中,如何影响编译状态
What: 什么是插件
从形态上看,插件通常是一个带有 apply
函数的类:
class SomePlugin {
apply(compiler) {
}
}
apply
函数运行时会得到参数 compiler
,以此为起点可以调用 hook
对象注册各种钩子回调,例如:compiler.hooks.make.tapAsync
,这里面 make
是钩子名称,tapAsync
定义了钩子的调用方式,webpack 的插件架构基于这种模式构建而成,插件开发者可以使用这种模式在钩子回调中,插入特定代码。webpack 各种内置对象都带有 hooks
属性,比如 compilation
对象:
class SomePlugin {
apply(compiler) {
compiler.hooks.thisCompilation.tap(‘SomePlugin’, (compilation) => {
compilation.hooks.optimizeChunkAssets.tapAsync(‘SomePlugin’, ()=>{});
})
}
}
钩子的核心逻辑定义在 Tapable 仓库,内部定义了如下类型的钩子:
const {
SyncHook,
SyncBailHook,
SyncWaterfallHook,
SyncLoopHook,
AsyncParallelHook,
AsyncParallelBailHook,
AsyncSeriesHook,
AsyncSeriesBailHook,
AsyncSeriesWaterfallHook
} = require(“tapable”);
不同类型的钩子根据其并行度、熔断方式、同步异步,调用方式会略有不同,插件开发者需要根据这些的特性,编写不同的交互逻辑,这部分内容也特别多,回头展开聊聊。
When: 什么时候会触发钩子
了解 webpack 插件的基本形态之后,接下来需要弄清楚一个问题:webpack 会在什么时间节点触发什么钩子?这一块我认为是知识量最大的一部分,毕竟源码里面有237个钩子,但官网只介绍了不到100个,且官网对每个钩子的说明都太简短,就我个人而言看完并没有太大收获,所以有必要展开聊一下这个话题。先看几个例子:
-
compiler.hooks.compilation
: -
- 时机:启动编译创建出 compilation 对象后触发
-
参数:当前编译的 compilation 对象
-
示例:很多插件基于此事件获取 compilation 实例
-
compiler.hooks.make
: -
- 时机:正式开始编译时触发
-
参数:同样是当前编译的
compilation
对象 -
示例:webpack 内置的
EntryPlugin
基于此钩子实现entry
模块的初始化 -
compilation.hooks.optimizeChunks
: -
- 时机:
seal
函数中,chunk
集合构建完毕后触发
- 时机:
-
参数:
chunks
集合与chunkGroups
集合 -
示例:
SplitChunksPlugin
插件基于此钩子实现chunk
拆分优化 -
compiler.hooks.done
: -
- 时机:编译完成后触发
-
参数:
stats
对象,包含编译过程中的各类统计信息 -
示例:
webpack-bundle-analyzer
插件基于此钩子实现打包分析
这是我总结的钩子的三个学习要素:触发时机、传递参数、示例代码。
触发时机
触发时机与 webpack 工作过程紧密相关,大体上从启动到结束,compiler
对象逐次触发如下钩子:
而 compilation
对象逐次触发:
所以,理解清楚前面说的 webpack 工作的主流程,基本上就可以捋清楚“什么时候会触发什么钩子”。
参数
传递参数与具体的钩子强相关,官网对这方面没有做出进一步解释,我的做法是直接在源码里面搜索调用语句,例如对于 compilation.hooks.optimizeTree
,可以在 webpack 源码中搜索 hooks.optimizeTree.call
关键字,就可以找到调用代码:
// lib/compilation.js#2297
this.hooks.optimizeTree.callAsync(this.chunks, this.modules, err => {
});
结合代码所在的上下文,可以判断出此时传递的是经过优化的 chunks
及 modules
集合。
找到示例
Webpack 的钩子复杂程度不一,我认为最好的学习方法还是带着目的去查询其他插件中如何使用这些钩子。例如,在 compilation.seal
函数内部有 optimizeModules
和 afterOptimizeModules
这一对看起来很对偶的钩子,optimizeModules
从字面上可以理解为用于优化已经编译出的 modules
,那 afterOptimizeModules
呢?
从 webpack 源码中唯一搜索到的用途是 ProgressPlugin
,大体上逻辑如下:
compilation.hooks.afterOptimizeModules.intercept({
name: “ProgressPlugin”,
call() {
handler(percentage, “sealing”, title);
},
done() {
progressReporters.set(compiler, undefined);
handler(percentage, “sealing”, title);
},
result() {
handler(percentage, “sealing”, title);
},
error() {
handler(percentage, “sealing”, title);
},
tap(tap) {
// p is percentage from 0 to 1
// args is any number of messages in a hierarchical matter
progressReporters.set(compilation.compiler, (p, …args) => {
handler(percentage, “sealing”, title, tap.name, …args);
});
handler(percentage, “sealing”, title, tap.name);
}
});
基本上可以猜测出,afterOptimizeModules
的设计初衷就是用于通知优化行为的结束。
apply
虽然是一个函数,但是从设计上就只有输入,webpack 不 care 输出,所以在插件中只能通过调用类型实体的各种方法来或者更改实体的配置信息,变更编译行为。例如:
-
compilation.addModule :添加模块,可以在原有的 module 构建规则之外,添加自定义模块
-
compilation.emitAsset:直译是“提交资产”,功能可以理解将内容写入到特定路径
到这里,插件的工作机理和写法已经有一个很粗浅的介绍了,回头单拎出来细讲吧。
How: 如何影响编译状态
解决上述两个问题之后,我们就能理解“如何将特定逻辑插入 webpack 编译过程”,接下来才是重点 —— 如何影响编译状态?强调一下,webpack 的插件体系与平常所见的 订阅/发布 模式差别很大,是一种非常强耦合的设计,hooks 回调由 webpack 决定何时,以何种方式执行;而在 hooks 回调内部可以通过修改状态、调用上下文 api 等方式对 webpack 产生 side effect。
比如,EntryPlugin
插件:
class EntryPlugin {
apply(compiler) {
compiler.hooks.compilation.tap(
“EntryPlugin”,
(compilation, { normalModuleFactory }) => {
compilation.dependencyFactories.set(
EntryDependency,
normalModuleFactory
);
}
);
compiler.hooks.make.tapAsync(“EntryPlugin”, (compilation, callback) => {
const { entry, options, context } = this;
const dep = EntryPlugin.createDependency(entry, options);
compilation.addEntry(context, dep, options, (err) => {
callback(err);
});
});
}
}
上述代码片段调用了两个影响 compilation
对象状态的接口:
-
compilation.dependencyFactories.set
-
compilation.addEntry
操作的具体含义可以先忽略,这里要理解的重点是,webpack 会将上下文信息以参数或 this
(compiler 对象) 形式传递给钩子回调,在回调中可以调用上下文对象的方法或者直接修改上下文对象属性的方式,对原定的流程产生 side effect。所以想纯熟地编写插件,除了要理解调用时机,还需要了解我们可以用哪一些api,例如:
-
compilation.addModule
:添加模块,可以在原有的module
构建规则之外,添加自定义模块 -
compilation.emitAsset
:直译是“提交资产”,功能可以理解将内容写入到特定路径 -
compilation.addEntry
:添加入口,功能上与直接定义entry
配置相同 -
module.addError
:添加编译错误信息 -
…
最后
前端CSS面试题文档,JavaScript面试题文档,Vue面试题文档,大厂面试题文档
normalModuleFactory
);
}
);
compiler.hooks.make.tapAsync(“EntryPlugin”, (compilation, callback) => {
const { entry, options, context } = this;
const dep = EntryPlugin.createDependency(entry, options);
compilation.addEntry(context, dep, options, (err) => {
callback(err);
});
});
}
}
上述代码片段调用了两个影响 compilation
对象状态的接口:
-
compilation.dependencyFactories.set
-
compilation.addEntry
操作的具体含义可以先忽略,这里要理解的重点是,webpack 会将上下文信息以参数或 this
(compiler 对象) 形式传递给钩子回调,在回调中可以调用上下文对象的方法或者直接修改上下文对象属性的方式,对原定的流程产生 side effect。所以想纯熟地编写插件,除了要理解调用时机,还需要了解我们可以用哪一些api,例如:
-
compilation.addModule
:添加模块,可以在原有的module
构建规则之外,添加自定义模块 -
compilation.emitAsset
:直译是“提交资产”,功能可以理解将内容写入到特定路径 -
compilation.addEntry
:添加入口,功能上与直接定义entry
配置相同 -
module.addError
:添加编译错误信息 -
…
最后
前端CSS面试题文档,JavaScript面试题文档,Vue面试题文档,大厂面试题文档
[外链图片转存中…(img-I948yISz-1727195531060)]
[外链图片转存中…(img-8xmehfFi-1727195531061)]