最近粗略阅读了一下Webpack的源码，对其打包的流程有了一定的了解，接下来结合源码，和大家分享一下webpack的打包流程；同时在文章最后，会有一个简易的Webpack的实现，提供大家参考和学习~
Webpack 是一个用于现代 JavaScript 应用程序的静态模块打包工具。它将你项目中所需的每一个模块组合成一个或多个bundles，用于在浏览器使用
PS：本次分享阅读的是webpack4的源码，当前最新的webpack5[1]对比4版本有很多升级和调整，但是大体的流程差别不大，提供给大家学习其主要的流程没太大问题
整体构建流程
我们先来了解一下Webpack整体大致的一个构建流程，Webpack 的运行流程是一个串行的过程，从启动到结束会依次执行以下流程：
概念介绍
在细节地介绍流程前，有一些相关概念需要提前说明一下：
Module
Webpack官网是这么解释module（模块）的：
在模块化编程中，开发者将程序分解为功能离散的 chunk，并称之为 模块。每个模块都拥有小于完整程序的体积，使得验证、调试及测试变得轻而易举。精心编写的 模块 提供了可靠的抽象和封装界限，使得应用程序中每个模块都具备了条理清晰的设计和明确的目的。
通俗来说，module 即每一个资源文件的模块对应，如js / css / 图片等，由NormalModule实例化而来，存在compilations.modules中；它可以理解为是源文件到chunk的一个中间态，便于编译过程中进行各种操作。
Chunk & ChunkGroup
chunk 即每一个输出文件的对应，包括入口文件，异步加载文件，优化切割后的文件等等；它可以包含多个module；存于 compilation.chunks；chunkGroup 可以包含多个 chunk（入口 chunk 或异步模块的 chunk）。entrypoint 就是一个 chunkGroup，里包含入口 chunk。存于 compilation.chunkGroups。
Loader
Webpack 本身只能处理 JavaScript 模块，如果要处理其他类型的文件，就需要使用 loader 进行转换。Loader 是导出为一个函数的 node 模块。该函数在 loader 转换资源的时候调用，它接受源文件作为参数，返回转换的结果。这样，我们就可以通过 require 来加载任何类型的模块或文件，比如 CoffeeScript、 JSX、 LESS 或图片。
module.exports = function (source) {
// ... 对source做处理
return newSource;
};Plugins
即插件，它是可插拔的模块，可以完成更多编译过程中 loader 不能完成的功能。这里我们要先介绍一下Plugin依赖的另外一个库——Tapable[2]，它简单来说就是一个发布-订阅模式的实现。它提供了很多类型的钩子类（如同步、异步、并行、熔断等），他们可以tap（订阅）若干个回调函数，在call（发布）的时候，将订阅的回调函数以对应的方式执行。举个例子🌰：
const tapable = require("tapable");
const { SyncHook } = tapable;
const hook = new SyncHook();
hook.tap("MyHook", () => { console.log("enter MyHook") });
hook.tap("MyHook2", () => { console.log("enter MyHook2") });
hook.call(); // enter MyHook enter MyHook2webpack的Plugin是与上述的Tapable强耦合的，我们可以参照下面一个plugin的简单实现来了解一下：
class MyPlugin {
apply(compiler) {
compiler.hooks.make.tap("MyPlugin", (compilation) => {
// ...
compilation.hooks.optimizeChunkAssets.tap("MyPlugin", (chunks) => {
// ...
}
}
}
}结合上述代码我们可以注意到：
plugin必须在原型上定义一个apply方法，并接受了一个compiler实例作为参数。
apply方法会在初始化插件时被调用，此时我们可以对compiler、compilation上的hooks做订阅，等编译流程执行到了我们监听的时机，就会调用订阅的回调函数，来对编译的过程做一些对应操作。
Webpack 会在特定的时间点（编译周期钩子）发布特定的事件，插件在监听到对应事件后会执行特定的逻辑，并且插件可以调用 Webpack 提供的 API 改变 Webpack 的运行结果
Compiler
Compiler 对象包含了当前运行Webpack的配置，包括entry、output、loaders等配置，这个对象在启动Webpack时被实例化，而且是全局唯一的。Plugin可以通过该对象获取到Webpack的配置信息进行处理、以及监听compiler的hooks从而做进一步的处理。如下：
class Compiler extends Tapable {
constructor(context){
// ...
this.options = {},
this.hooks = {
run: new AsyncSeriesHook(["compiler"]),
compile: new SyncHook(["params"]),
make: new AsyncParallelHook(["compilation"]),
// ...
}
}
}Compilation
Compilation对象代表了一次资源版本构建。每次构建过程都会产生一次 Compilation，比如我们启动 watch 功能的时候，每当检测到一个文件变化，就会重新创建一个新的 Compilation，从而生成一组新的编译资源 一个 Compilation 对象表现了当前的模块资源、编译生成资源、变化的文件、以及被跟踪依赖的状态信息。Compilation 模块会被 Compiler 用来创建新的编译（或新的构建）。compilation 实例能够访问所有的模块和它们的依赖（大部分是循环依赖）。它会对应用程序的依赖图中所有模块进行字面上的编译(literal compilation)。在编译阶段，模块会被加载(loaded)、封存(sealed)、优化(optimized)、分块(chunked)、哈希(hashed)和重新创建(restored)。Compilation 对象也提供了插件需要自定义功能的回调，以供插件做自定义处理时选择使用拓展。简单来说，Compilation的职责就是构建模块和Chunk，并利用插件优化构建过程。
总结来说，以上概念的关系可以通过下面的流程图来更好地get到：每个文件可以被创建为一个module，若干个module可以解析编译组成一个chunk，入口+异步chunk可以组成一个chunkGroup。
构建流程细化
接下来我们结合流程图和代码，了解一下初始化、编译、输出三个大的步骤中的一些细节
初始化
我们使用webpack进行打包代码时，一般会命令行的指令 ./node_modules/bin/webpack ，实际上对应执行的文件是 node_modules/webpack/bin/webpack.js ，它即webpack的入口文件，我们从入口文件开始分析：首先，获取到当前已安装的cli；并将cli作为执行入口，如webpack-cli。
webpack4会判断安装了两种中任意一种即可；在webpack5版本只支持webpack-cli作为cli工具
// bin/webpack.js
#!/usr/bin/env node
const installedClis = CLIs.filter(cli => cli.installed);
// 过滤出安装了的cli
if (installedClis.length === 0) {
// ... 没有安装cli，提示用户安装webpack的cli
} else if (installedClis.length === 1) {
const path = require("path");
const pkgPath = require.resolve(`${installedClis[0].package}/package.json`);
const pkg = require(pkgPath);
// 实际上是require('webpack-cli')，即webpack-cli才是webpack真正执行的入口
require(path.resolve(
path.dirname(pkgPath),
pkg.bin[installedClis[0].binName]
));
} else {
// .. 安装了多个cli会warning，并退出
// * 在webpack5中只支持使用webpack-cli
}我们转到webpack-cli这个包，通过其package.json可以发现执行入口为 ./bin/cli.js ， 我们来了解一下cli.js做了哪些处理：
首先会通过一个NON_COMPILATION_CMD的常量数组判断当前命令是否需要编译，如果不需要，则通过./utils/prompt-command来处理这个命令；
如果需要进入编译流程，则会通过./utils/convert-argv来将webpack.config.js和命令行中的参数合并为options；
接着引入webpack包，并通过上一步得到的options作为参数，初始化出一个全局唯一的compiler实例；
判断编译类型，如果是非watch模式（watch模式的情况不在本文讨论，有兴趣的小伙伴可自行查阅相关资料~），就直接调用compiler.run方法，开始正式的编译阶段。
// webpack-cli/bin/cli.js
// NON_COMPILATION_ARGS指定不需要编译的指令；
// 如init，执行webpack init来初始化一份webpack配置
const NON_COMPILATION_CMD = process.argv.find(arg => {
return NON_COMPILATION_ARGS.find(a => a === arg);
});
// 如果是不需要执行编译的指令，就会require对应的包并执行
if (NON_COMPILATION_CMD) {
//
return require("./utils/prompt-command")(NON_COMPILATION_CMD, ...process.argv);
}
// Yargs通过解析参数来帮助构建脚手架的工具
yargs.parse(process.argv.slice(2), (err, argv, output) => {
let options;
// 解析配置文件和命令行参数得到最终的options（webpack.config & 命令行的参数配置）
// 同时会根据部分参数自动加载对应插件
options = require("./utils/convert-argv")(argv);
// 将得到的options用于实例化compiler，并启动编译
function processOptions(options) {
// 处理options为Promise的情况
if (typeof options.then === "function") {
options.then(processOptions);
return;
}
// ... 对outputOptions进行一些设置
// 通过options实例化全局唯一的compiler对象
const webpack = require("webpack"); // lib/webpack.js
compiler = webpack(options);
// ... 判断插件的启用和tap一些事件
// 最后针对配置是否是watch监听模式，分别执行对应操作
if (firstOptions.watch || options.watch) {
// ... watch
} else {
compiler.run(...)
}
}
processOptions(options);
}))
PS：流程图中向下的箭头表示当前主流程的操作，向右的箭头一般表示当前大步骤的子步骤
那么上一步在调用webpack(options)时做了什么呢，是如何实例化出compiler呢？我们接下来进到其对应的 webpack/lib/webpack.js文件来了解一下：
首先判断options是否是数组，如果是数组的话，会将其每一项当做一个构建目标，并调用MultiCompiler来实例化compiler；
This is useful for bundling a library for multiple targets such as AMD and CommonJS
如果option是通常的对象，首先会通过WebpackOptionsDefaulter类添加大量默认参数给options，得到最终的options；
然后通过上一步得到的options来实例化全局唯一的compiler；
遍历options配置的plugins，调用其apply方法，初始化配置的插件；
最后通过WebpackOptionsApply类，将配置的options转化为插件并启用（如mode为production模式下默认开启的UglifyJSPlugin插件，无需用户配置）；
// webpack/lib/webpack.js
const webpack = (options, callback) => {
let compiler;
// 多个配置的情况: https://webpack.js.org/configuration/configuration-types/#exporting-multiple-configurations
if (Array.isArray(options)) {
compiler = new MultiCompiler(
Array.from(options).map(options => webpack(options))
);
} else if (typeof options === "object") {
// WebpackOptionsDefaulter 对options配置对象添加了大量的默认参数
options = new WebpackOptionsDefaulter().process(options);
// 实例化单个option对应的全局唯一的compiler
compiler = new Compiler(options.context);
compiler.options = options;
// 启用options中配置的默认插件
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);
}
}
}
// WebpackOptionsApply 主要就是将配置的options转化为插件，以及启用一些默认插件
compiler.options = new WebpackOptionsApply().process(options, compiler);
}
return compiler;
};
// 兼容esmodule和commonjs
exports = module.exports = webpack;总的来说，初始化的过程大致为：
初始化options参数；
实例化Compiler对象；
初始化默认的和配置的插件；
调用compiler的run方法开始编译
编译
调用compiler.run之后，正式进入编译阶段；该阶段核心步骤：
进入compile 函数，实例化compilation；
执行关键的make钩子，即开始执行真正的编译，这里会调用loader对代码解析，递归模块的依赖解析等；
结束后进入compilation的seal，这个阶段会创建chunk，并且有非常多用于处理优化的hooks；
我们来了解一下run方法里是如何进行编译的：
首先，经过了beforeRun、run的钩子后，进入compile方法；
在compile中经过beforeCompile、compile钩子后，来到真正执行编译的钩子——make；
// webpack/lib/compiler.js
run() {
const onCompiled = (err, compilation) => {
this.emitAssets(compilation, err => {
this.emitRecords(err => {
this.hooks.done.callAsync(stats, err => {
return finalCallback(null, stats); // stats为计算编译的时间
});
});
});
};
this.hooks.beforeRun.callAsync(this, err => {
this.hooks.run.callAsync(this, err => {
this.readRecords(err => {
this.compile(onCompiled);
});
});
});
}
compile(callback) {
const params = this.newCompilationParams();
this.hooks.beforeCompile.callAsync(params, err => {
this.hooks.compile.call(params);
// 实例化一个compilation对象
const compilation = this.newCompilation(params);
// * make hook，真正开始编译
this.hooks.make.callAsync(compilation, err => {
compilation.finish(err => {
// seal阶段
compilation.seal(err => {
this.hooks.afterCompile.callAsync(compilation, err => {
return callback(null, compilation);
});
});
});
});
});
}
}要知道在make阶段做了什么，我们可以全局搜索一下hooks.make.tapAsync，来查询订阅了make的相关插件，其中包括了SingleEntryPlugin、MultiEntryPlugin、DynamicEntryPlugin等；
我们以SingleEntryPlugin作为例子进行分析：在插件的apply方法中，将入口信息、上下文环境等作为参数，调用addEntry方法，从入口开始编译；
// SingleEntryPlugin.js
apply(compiler) {
// make
compiler.hooks.make.tapAsync(
"SingleEntryPlugin",
(compilation, callback) => {
const { entry, name, context } = this;
const dep = SingleEntryPlugin.createDependency(entry, name);
compilation.addEntry(context, dep, name, callback);
}
);
}在addEntry中，调用了_addModuleChain将整个module链中的所有模块都处理完成，其流程如下：
根据依赖的类型获取对应模块工厂moduleFactory；
调用moduleFactory的create方法，创建模块module；
调用buildModule方法，其核心是使用loaders和parser解析module；
解析完成回到create的回调中，继续分析该模块的依赖项，并递归解析处理其依赖项；
处理结束后，回到make的回调中，执行compilation.finish，准备进入seal阶段
// Compliation.js
addEntry(context, entry, name, callback) {
this.hooks.addEntry.call(entry, name);
this._addModuleChain(
context,
entry,
module => this.entries.push(module),
(err, module) => {
this.hooks.succeedEntry.call(entry, name, module);
return callback(null, module);
}
);
}
_addModuleChain(context, dependency, onModule, callback) {
const Dep = /** @type {DepConstructor} */ (dependency.constructor);
// 根据依赖的类型获取对应的模块工厂，用于创建模块
const moduleFactory = this.dependencyFactories.get(Dep);
// semaphore主要是限制同时处理的模块数量，默认值是100
this.semaphore.acquire(() => {
// * 使用模块工厂创建模块；JS等模块会使用NormalModuleFactory来创建模块对象
moduleFactory.create(
{/* params*/},
(err, module) => {
// 添加到this.modules中
const addModuleResult = this.addModule(module);
onModule(module); // this.entries.push(module);
// module已经build完了，依赖也收集好了，开始处理依赖的module
const afterBuild = () => {
if (addModuleResult.dependencies) {
this.processModuleDependencies(module, err => {
callback(null, module);
});
} else {
return callback(null, module);
}
};
// 如果已经build过的模块，build为false
if (addModuleResult.build) {
/*
调用module.build开始构建模块
调用loader处理源文件，使用acorn生成AST，
将遍历AST,遇到require等依赖时，创建依赖(Dependency)加入依赖数组
*/
this.buildModule(module, false, null, null, err => {
afterBuild();
});
}
);
}
}
buildModule(module, optional, origin, dependencies, thisCallback) {
// 针对多个文件引用同一个依赖的情况，若已build并缓存，就不重复build
let callbackList = this._buildingModules.get(module);
if (callbackList) {
callbackList.push(thisCallback);
return;
}
// set cache map
this._buildingModules.set(module, (callbackList = [thisCallback]));
this.hooks.buildModule.call(module);
// build阶段主要就是调用loaders和parser进行解析
module.build(
// ... params
error => {
module.dependencies.sort(...);
this.hooks.succeedModule.call(module);
return callback();
}
);
}这里我们先深入一下_module_.build方法，了解一下内部的一些核心处理流程。以NormalModule为例：
调用this.doBuild方法，其中主要是调用了runLoaders，执行配置的loader来解析module；
经过loader的解析后，得到可被js继续解析的source，此时将其交给Paser，解析为AST（依赖acron库），并遍历AST，查找Inport、require等语句，即当前模块的依赖项；
在线AST解析：https://astexplorer.net/[3]
上一步结束后，会回到_addModuleChain的afterBuild回调中，并执行processModuleDependencies，递归该模块的依赖项，并对这些依赖项执行之前同样的创建模块、runLoaders、Parser解析的流程，直到解析完所有依赖项。
下面贴了一些相关代码，只保留了一些重点步骤，方便了解和阅读，有兴趣的同学可以对照源码深入了解其各实现细节。
// NormalModule.js
build(options, compilation, resolver, fs, callback) {
// ... 设置this的一些值
return this.doBuild(options, compilation, resolver, fs, err => {
this._cachedSources.clear();
const handleParseResult = result => {
this._initBuildHash(compilation);
return callback();
};
// 将经过loader处理的代码，通过parser处理转为AST，并找出依赖模块，得到最终结果
// 然后返回到Compilation.js的buildModule方法中，调用processModuleDependencies方法递归处理该模块依赖的模块
// 其callback即回到compilation.finish
const result = this.parser.parse(
this._ast || this._source.source(),
// ... params
);
if (result !== undefined) {
handleParseResult(result);
}
});
}
doBuild(options, compilation, resolver, fs, callback) {
const loaderContext = this.createLoaderContext(/*...*/);
runLoaders(
{/* param */},
(err, result) => {
if (result) { 🐞
this.buildInfo.cacheable = result.cacheable;
this.buildInfo.fileDependencies = new Set(result.fileDependencies);
this.buildInfo.contextDependencies = new Set(result.contextDependencies);
}
// loader处理后返回的结果: 0 - result;1 - sourceMap;2 - extra
const source = result.result[0];
const sourceMap = result.result.length >= 1 ? result.result[1] : null;
const extraInfo = result.result.length >= 2 ? result.result[2] : null;
// 将loader的处理结果转化为字符串的source
this._source = this.createSource(
this.binary ? asBuffer(source) : asString(source),
result.resourceBuffer,
sourceMap
);
return callback();
}
);
}// loader-runner
runLoaders(options, callback){
// 设置loaderContext
loaderContext.xxx = xxx;
Object.defineProperty(loaderContext, 'xxx', {...})
// 执行
iteratePitchingLoaders(processOptions, loaderContetxt, function(err, res){
// ...
})
}
iteratePitchingLoaders(options, loaderContext, callback) {
// 加载loader，并执行
loadLoader(currentLoaderObject, function(err)){
// 取到loader函数
var fn = currentLoaderObject.pitch;
// 执行loader来处理文件，并在回调中继续递归执行iteratePitchingLoaders
runSyncOrAsync(fn, loaderContext, args, errCallback);
}
}// Parser.parse
parse(source, initialState) { // source，即源代码的字符串
let ast;
if (typeof source === "object" && source !== null) {
ast = source;
} else {
// 主要就是通过调用acron的parse方法来解析成AST
ast = Parser.parse(source, { sourceType: this.sourceType, onComment: comments });
}
// 触发回调 plugin(HarmonyDetectionParserPlugin 和 UseStrictPlugin) 根据是否有 import/export 和 use strict 增加依赖：HarmonyCompatibilityDependency, HarmonyInitDependency，ConstDependency
if (this.hooks.program.call(ast, comments) === undefined) {
// 检测严格模式
this.detectMode(ast.body);
// 递归遍历语句，处理import、export等导入导出的相关依赖
this.prewalkStatements(ast.body);
// 处理块遍历
this.blockPrewalkStatements(ast.body);
// 用于深入函数内部（方法在 walkFunctionDeclaration 进行递归），然后递归继续查找 ast 上的依赖，异步此处深入会增加依赖 ImportDependenciesBlock;
this.walkStatements(ast.body);
}
}make阶段结束，将会在其回调中调用compilation.seal进入seal阶段，根据编译好的module创建chunk。其主要的逻辑：
根据entry生成chunk图；
生成构建hash；
生成chunk对应的资源，保存在compilation.assets中；
另外seal阶段有很大部分代码是调用性能优化相关的内置插件；
// Compilation.js
seal(callback) {
this.hooks.seal.call();
this.hooks.beforeChunks.call();
// 遍历入口，生成入口的chunk，并将所有module、chunk、chunkGroup之间建立联系
for (const preparedEntrypoint of this._preparedEntrypoints) {
const chunk = this.addChunk(name);
const entrypoint = new Entrypoint(name);
this.chunkGroups.push(entrypoint);
GraphHelpers.connectChunkGroupAndChunk(entrypoint, chunk);
GraphHelpers.connectChunkAndModule(chunk, module);
this.assignDepth(module);
}
// 生成并优化 chunk 依赖图，建立起各模块之前的关系
buildChunkGraph(
this,
/** @type {Entrypoint[]} */ (this.chunkGroups.slice())
);
this.sortModules(this.modules);
this.hooks.optimizeTree.callAsync(this.chunks, this.modules, err => {
this.applyModuleIds();
this.sortItemsWithModuleIds();
this.applyChunkIds();
this.sortItemsWithChunkIds();
// 生成这次构建的Hash，可通过webpack.config的[hash]占位符配置
this.createHash();
this.createModuleAssets();
if (this.hooks.shouldGenerateChunkAssets.call() !== false) {
this.hooks.beforeChunkAssets.call();
// 通过chunk的类型(enrty/动态引入)，使用对应模板生成源码
// 生成后调用emitAsset方法将其保存到assets属性中，即最终要生成的文件列表
this.createChunkAssets();
}
this.summarizeDependencies();
});
}编译阶段简单总结下来就是：
实例化compilation；
执行make hook的回调，递归解析module；
根据编译好的module创建chunk，并生成对应的资源模块，准备输出；
输出
输出部分，主要是在上一步seal阶段的回调中，进到Complier.emitAssets方法，将seal过程中处理好的资源生成具体的文件。
// Compiler.js
emitAssets(compilation, callback) {
const emitFiles = () => {
asyncLib.forEachLimit(
compilation.getAssets(),
15,
({ name: file, source }, callback) => {
// 写入文件
this.outputFileSystem.writeFile(targetPath, content);
}
}
// 递归创建输出目录
this.outputFileSystem.mkdirp(outputPath, emitFiles);
}先使用outputFileSystem.mkdirp 创建文件夹，之后执行回调 emitFiles，在回调里通过 asyncLib.forEachLimit 并行执行对每个 file 资源文件进行路径拼接后，将每个 source 源码写入真实路径的 file。至此整个构建流程就基本结束了~
Webpack的构建流程总结
初始化参数：从配置文件和 Shell 语句中读取与合并参数，得出最终的参数；
开始编译：用上一步得到的参数初始化 Compiler 对象，加载所有配置的插件，执行对象的 run 方法开始执行编译；
确定入口：根据配置中的 entry 找出所有的入口文件；
编译模块：从入口文件出发，调用所有配置的 Loader 对模块进行翻译，再找出该模块依赖的模块，再递归本步骤直到所有入口依赖的文件都经过了本步骤的处理；
完成模块编译：在经过第4步使用 Loader 翻译完所有模块后，得到了每个模块被翻译后的最终内容以及它们之间的依赖关系；
输出资源：根据入口和模块之间的依赖关系，组装成一个个包含多个模块的 Chunk，再把每个 Chunk 转换成一个单独的文件加入到输出列表，这步是可以修改输出内容的最后机会；
输出完成：在确定好输出内容后，根据配置确定输出的路径和文件名，把文件内容写入到文件系统。
如何实现一个简易Webpack
实现要点：
提供一个类似webpack.config.js的编译配置文件（mywebpack.config.js）
实现一个Compiler，用于获取配置(options)、实例化Compilation、运行构建(run)；
实现一个Compilation，用于解析文件(run loader)、分析依赖(parse成ast)、生成chunk(seal)；
支持以tapable为基础的插件化机制；
支持配置loader解析文件；
整体流程和webpack编译流程靠拢，大致为：init->run->make->seal->emit ；
实现代码：https://github.com/tangxiaojun1996/mywebpack
webpack打包生成的文件分析：https://github.com/woai3c/Front-end-articles/issues/7
写在最后
以上带领大家结合源码、以及实现的一个简易webpack，对webpack的整体构建流程做了一个大致的了解；其中每个步骤背后实际基本都涉及到非常多的细节，其源码的代码量也较为庞大，有兴趣的小伙伴可以结合本次分享的构建流程，针对其中某些有兴趣的步骤继续深入源码了解和学习~ 😄
PS：文章底部有贴一些链接，有兴趣的同学可以参考参考
参考文章：https://blog.flqin.com/categories/FE-Build/[4]
https://juejin.cn/team/6943816493473726472/posts[5]
https://www.zhihu.com/people/fe_korey/posts[6]
实现一个插件：https://segmentfault.com/a/1190000021214520[7]
webpack打包流程分析: https://github.com/darrell0904/webpack-doc/blob/master/docs/chapter4/webpack_process.md[8]
seal封装生成文件核心流程：https://github.com/amandakelake/blog/issues/101
实现一个简易的webpack：https://juejin.cn/post/6859538537830858759
参考资料
[1]
webpack5: https://juejin.cn/post/6882663278712094727
[2]Tapable: https://github.com/webpack/tapable
[3]https://astexplorer.net/: https://astexplorer.net/
[4]https://blog.flqin.com/categories/FE-Build/: https://blog.flqin.com/categories/FE-Build/
[5]https://juejin.cn/team/6943816493473726472/posts: https://juejin.cn/team/6943816493473726472/posts
[6]https://www.zhihu.com/people/fe_korey/posts: https://www.zhihu.com/people/fe_korey/posts
[7]https://segmentfault.com/a/1190000021214520: https://segmentfault.com/a/1190000021214520
[8]https://github.com/darrell0904/webpack-doc/blob/master/docs/chapter4/webpack_process.md: https://github.com/darrell0904/webpack-doc/blob/master/docs/chapter4/webpack_process.md
3366
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
