阅读 webpack 源码简单了解打包过程-阿里云开发者社区

我们先看一下 webpack 官方对 webpack 的定义：

本质上，webpack 是一个现代 JavaScript 应用程序的静态模块打包器(module bundler) 。
当 webpack 处理应用程序时，它会递归地构建一个依赖关系图(dependency graph) ，
其中包含应用程序需要的每个模块，然后将所有这些模块打包成一个或多个 bundle。

webpack 作为一个打包器，相信大部分前端开发者是有使用过的，我也不例外。我所在的项目组是开发 H5 游戏的，随着所使用的引擎（egret）增加了对 webpack 的支持，我们项目也从原来官方的打包方式升级为用 webpack 打包。

之前项目从头开始编译得三十秒左右，后面每次改动后再编译也得十几秒左右。升级为 webpack 之后，除了第一次编译比较久，大概得一分钟左右，后面每次修改代码后只需要两三秒就完成热更新了，和之前的对比起来体验好了很多。

改用 webpack 打包对项目编译速度提升这么大，这也让我好奇它具体的一个执行流程是如何的，接下来便开始本篇文章的正题，通过阅读 webpack 的源码来简单地了解一下打包的过程。

注：webpack 版本为 v5.10.1，webpack-cli 版本为 4.2.0

一入口

当我们使用 webpack-cli 对项目进行打包的时候，实际上调用的就是当前项目中的 node_modules 中的 webpack-cli 中的 /bin/cli.js，我们将 webpack-cli 的代码下载到本地上，打开 cli.js 可以看到它走了 runCLI 的逻辑。

if (packageExists('webpack')) {
    runCLI(rawArgs);
} else {...
}

跳转之后我们可以发现 runCLI 中执行了 const cli = new WebpackCLI() 并调用了 cli.run，然后执行了 createCompiler 创建 compiler 对象，然后就进入到 webpack 的打包流程中了。

createCompiler(options, callback) {
    let compiler;
    try {
        compiler = webpack(options, callback);
    } catch (error) {...
    }
    return compiler;
}

二打包流程的前置知识

在开始打包流程之前，我们需要了解一个叫 Tapable 的库，这个库是 webpack 团队为了 webpack 而写的一个事件库。因为 webpack 本质上是一个分发各种事件的架子，然后通过不同的 plugin 监听这些事件再分别执行对应的操作。

Tapable 用法

定义一个事件：this.hooks.eventName = new SyncHook([arg]);

监听一个事件：this.hooks.eventName.tap(reason, fn);

分发一个事件：this.hooks.eventName.call(arg);

三打包流程

webpack 源码中整个打包流程如下，具体的过程下面进行介绍。

打开 webpack 的源码，进入到 package.json 中我们可以发现 main 指向的是 lib/index.js，那么我们的入口就是 lib/index.js 了。

进入到 index.js 中，将代码折叠起来后我们可以发现最重要的函数应该是 fn 函数。fn 函数的作用是去请求当前目录下 webpack.js。

const fn = lazyFunction(() => require("./webpack"));
module.exports = mergeExports(fn, {...
});

webpack.js

进入到 webpack.js 中，根据上面入口的代码 compiler = webpack(options, callback); 可知，在有无 callback 的判断中，会进入有的判断中，然后执行 create 函数，create 函数中我们的 options 是对象，所以是走 else 的逻辑，执行了 createCompiler 函数。

const webpack = /** @type {WebpackFunctionSingle & WebpackFunctionMulti} */ ((
    options,
    callback
) => {
    const create = () => {
        ...
        if (Array.isArray(options)) {...
        } else {
            /** @type {Compiler} */
            compiler = createCompiler(options);
            watch = options.watch;
            watchOptions = options.watchOptions || {};
        }
        return { compiler, watch, watchOptions };
    };
    if (callback) {
        try {
            const { compiler, watch, watchOptions } = create();
            if (watch) {
                compiler.watch(watchOptions, callback);
            } else {
                compiler.run((err, stats) => {
                    compiler.close(err2 => {
                        callback(err || err2, stats);
                    });
                });
            }
            return compiler;
        } catch (err) {...
        }
    } else {...
    }
});

createCompiler 函数这里就开始我们上面那张图的内容了，new Compiler(options.context); 中进行了一系列参数的初始化，有兴趣的可以自己去看一下。然后就开始进行事件的挂载了，事件都是挂载在 Compiler 上的，Compiler 的代码在 compiler.js 中。

可以看到按照 enviroment -> afterEnviroment -> initialize 这个顺序进行事件的分发，然后再在对应的地方进行监听和响应，要了解具体的响应的话可以在代码中直接全局进行搜索 事件名.tap 例如 enviroment.tap。这些不是特别关键的步骤就不进行细看了。

const createCompiler = rawOptions => {
    ...
    compiler.hooks.environment.call();
    compiler.hooks.afterEnvironment.call();
    compiler.hooks.initialize.call();
    return compiler;
};

createCompiler 函数执行完后回到 create 函数中，判断当前有无 watch，再决定执行 compiler.watch 还是 compiler.run。因为这是第一次编译，所以肯定不是处于 watch 状态，就进入到 compiler.run 也即 compiler.js 中了。

compiler.js

compiler.js 中的 run 函数如下所示，执行了函数里面自己定义的 run 箭头函数，又开始了各种事件的分发，同事调用了 readRecords 进行文件的读取，然后调用了 this.compile 并把 onCompiled 做为回调函数传了进去。

run(callback) {
    const onCompiled = (err, compilation) => {...}
    const run = () => {
        this.hooks.beforeRun.callAsync(this, err => {
            ...
            this.hooks.run.callAsync(this, err => {
                ...
                this.readRecords(err => {
                    ...
                    this.compile(onCompiled);
               });
            });
          });
    };

    if (this.idle) {
        ...
    run();
    });
    } else {
        run();
    }
}

compile 函数分发了 beforeCompile 和 compile 事件，然后就执行了 his.newCompilation 函数，创建了一个 compilation 对象，接着继续分发 make 和 finishMake 事件，make 是编译的第一个过程，这个需要留意一下。

然后调用了 compilation.finish 并在其回调里面调用了 compilation.seal，这两个我们后面再看里面的具体逻辑。接着分发了一个 afterCompile 事件表明编译阶段结束了，然后调用了 callback 即上面 run 函数中的 onCompiled 函数。

compile(callback) {
    const params = this.newCompilationParams();
    this.hooks.beforeCompile.callAsync(params, err => {
        ...
        this.hooks.compile.call(params);
        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 => {
                            this.hooks.afterCompile.callAsync(compilation, err => {...
                            });
                        });
                    });
                });
            });
        });
    });
}

onCompiled 函数里面分发了 shouldEmit 事件，然后进入 nextTick 函数中，执行了 this.emitAssets 函数，this.emitAssets 函数里面分发了一个 emit 事件然后读取了要打包的文件并定义了一个输出的文件。

接着执行 this.emitRecords 然后分发 done 事件，表示打包结束。

const onCompiled = (err, compilation) => {
    if (err) return finalCallback(err);
        if (this.hooks.shouldEmit.call(compilation) === false) {...
        }
        process.nextTick(() => {
            this.emitAssets(compilation, err => {
                if (compilation.hooks.needAdditionalPass.call()) {...
            }
            this.emitRecords(err => {
                ...
                this.hooks.done.callAsync(stats, err => {...
                }
            });
        });
    });
};

然后我们回到 compilation.finsih 函数中，它分发了 finishModules 事件对模块进行了一些操作，然后对每个模块都执行了 callback 函数。

finish(callback) {
    const { modules } = this;
    this.hooks.finishModules.callAsync(modules, err => {...
        for (const module of modules) {...
            callback();
        }
    });
}

再看看 compilation.seal 函数，在这里创建了 chunkGraph 对象，这个对象就是用来收集所有模块的关系的，接着就是分发各种事件。

seal(callback) {
    const chunkGraph = new ChunkGraph(this.moduleGraph);
    this.chunkGraph = chunkGraph;

    for (const module of this.modules) {
        ChunkGraph.setChunkGraphForModule(module, chunkGraph);
    }

    this.hooks.seal.call();
    this.hooks.afterOptimizeDependencies.call(this.modules);
    this.hooks.beforeChunks.call();
    for (const [name, { dependencies, includeDependencies, options }] of this.entries) {
        const chunk = this.addChunk(name);
        ...
    }
    buildChunkGraph(this, chunkGraphInit);
    this.hooks.afterChunks.call(this.chunks);
    this.hooks.optimize.call();

小结

到这里打包流程我们就大概的都看了一遍，整个流程比较重要的内容就是上面那张包含事件和函数的图，主要的流程包括 env -> init -> run -> beforeCompile -> compile -> compilation -> make -> finishMake -> afterCompile -> emit -> afterEmit -> done 这些事件。

看完上面的内容你可能还是一脸迷茫，不知道到底 webpack 打包过程中做了哪些内容，下面我们通过回答另外一个问题来加深对源码的理解。

webpack 是如何收集和分析依赖的？

首先我们需要知道 webpack 是在哪个阶段进行依赖的分析和收集的，根据上面的流程，通过排除法可以知道最有可能的就是在 make 到 finishMake 阶段。

翻到上面看下 compile 函数的代码，你会发现 make 和 finishMake 中间并没有做什么操作，根据 Table 库的知识点可知，我们需要找到监听 make 事件的地方即 make.tap。

搜索之后你会发现有九个结果，一个个看了之后我们可以发现 EntryPlugin.js 中的监听函数是最符合我们的预期的，EntryPlugin.createDependency 顾名思义就是创建依赖的地方，然后执行 compilation.addEntry 将依赖添加到编译中。

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.addEntry -> this._addEntryItem -> this.addModuleChain -> this.handleModuleCreation -> this.factorizeModule 的跳转之后，我们可以发现最后就是往 factorizeQueue 中添加了一个任务，到这里就没了。

我们需要了解一下 factorizeQueue 是什么，这里才知道它里面是如何处理的。根据下面的代码我们可以看到它的处理函数即 processor 为 this._factorizeModule。处理函数里面主要就是执行了 factory.create，到这里发现前面又没有路了。那么我们需要找到这个 factory 是什么，这个寻找的过程比较麻烦，这里就省略不讲了，最后寻找的结果是 factory 对应 NormalModuleFactory。

this.factorizeQueue = new AsyncQueue({
    name: "factorize",
    parallelism: options.parallelism || 100,
    processor: this._factorizeModule.bind(this)
});

在 NormalModuleFactory 中找到 create 函数，可以看到 factorize 进行了事件监听，搜索 factorize.tap 可以看到里面进行了一系列事件的监听: reslove -> afterResolve -> createModule，由此可知 factory.create 最终创建了一个 module 对象。

this.factorizeModule 执行完后就到它的回调函数里面，回调函数中调用了 this.addModule 函数，这个函数里面和 this.factorizeModule 了类似，也是往一个队列里面添加了一个任务之类，进入到它的 processor 中，可以知道它的作用就是把 module 添加到 compilation.modules 中，同时会检查 id 防止重复添加。

接着到 this.addModule 的回调函数中，它在里面调用了 this.buildModule，从名称我们可以推测依赖很大可能就是在这个函数里面进行收集的。this.buildModule 中也是和上面类似的操作，它的 processor 就在下面的 _buildModule 函数中。_buildModule 中调用了 module.needBuild，而 module.needBuild 里面调用了 module.build，这个 module 由上面的 NormalModuleFactory 可知它对应的代码应该在 NormalModule.js 中。

在 NormalModule.js 中搜索 build 函数，我们可以注意到在这里有对 source 和 ast 进行初始化。接着我们进入到 doBuild 函数中。

build(options, compilation, resolver, fs, callback) {
    ...
    this._source = null;
    this._ast = null;
    ...
    return this.doBuild(options, compilation, resolver, fs, err => {...})

可以看到 doBuild 函数执行了 runLoaders，顾名思义这个就是执行所有的 loader，读取所有文件的源代码。runLoaders 执行完后回调里面调用了 processResult 函数，在 processResult 里面对 _source 进行了赋值，但是 _ast 此时还是空的，因为之前没有对它进行过处理，它的赋值应该是后面才进行的。

doBuild(options, compilation, resolver, fs, callback) {
    const loaderContext = this.createLoaderContext(...);
    const processResult = (err, result) => {
        ...
        this._source = this.createSource(...);
        this._ast =
            typeof extraInfo === "object" && 
            extraInfo !== null && 
            extraInfo.webpackAST !== undefined ? 
            extraInfo.webpackAST : null;
        ...
    }
    runLoaders({...}, (err, result) => {
        ...
        processResult(err, result.result);
    });

执行完 doBuild 函数我们再回到上面它的回调里面，可以看到在 try 中执行了 parse 的操作，对源码（this._source.source()）进行了解析，这个 parser 是根据源码的不同去调用不同的 parser，例如解析 JavaScript 代码的话就去调用了 JavascriptParser.js 中的 parse 函数。

this.doBuild(options, compilation, resolver, fs, err => {
    ...
    let result;
    try {
        result = this.parser.parse(this._ast || this._source.source(), {...});
    } catch (e) {
        ...
    }
})

JavascriptParser.js 中的 parse 函数中调用了 this.blockPreWalkStatements(ast.body); 函数，这个函数就是进行依赖分析的地方。分析的过程就是将源码的每行代码都进行分析，如果发现当前的代码是引用相关的，就根据 statement.type 分别进行处理。

blockPreWalkStatements(statements) {
    for (let index = 0, len = statements.length; index < len; index++) {
        const statement = statements[index];
        this.blockPreWalkStatement(statement);
    }
}

blockPreWalkStatement(statement) {
    ...
    switch (statement.type) {
        case "ImportDeclaration":
            this.blockPreWalkImportDeclaration(statement);
            break;
        case "ExportAllDeclaration":
            this.blockPreWalkExportAllDeclaration(statement);
            break;
        case "ExportDefaultDeclaration":
            this.blockPreWalkExportDefaultDeclaration(statement);
            break;
        case "ExportNamedDeclaration":
            this.blockPreWalkExportNamedDeclaration(statement);
            break;
        case "VariableDeclaration":
            this.blockPreWalkVariableDeclaration(statement);
            break;
        case "ClassDeclaration":
            this.blockPreWalkClassDeclaration(statement);
            break;
    }
}

到这里我们可以回答上面提出的那个问题了，webpack 是如何收集和分析依赖的？

在 doBuild 中执行 runLoaders 将所有的文件转化为源码，然后在 doBuild 的回调中将源码进行 parse 转化为 AST，然后再根据 AST 对每一行代码进行分析，发现是引用相关的就将其进行处理。

后面的内容我们在这里就不具体分析了，大概描述下就是上面的引用相关会被添加到 module 的 dependencies 或 blocks 中，然后再 seal 阶段 webpack 将 module 转化为 chunk，并且可能会把多个 module 通过 codeGeneration 合并为一个 chunk，seal 结束之后为每个 chunk 创建文件，并写到硬盘上。

阅读 webpack 源码简单了解打包过程

一入口

二打包流程的前置知识

Tapable 用法

三打包流程

webpack.js

compiler.js

小结

webpack 是如何收集和分析依赖的？

热门文章

最新文章

相关课程

相关电子书

相关实验场景

阅读 webpack 源码简单了解打包过程

一 入口

二 打包流程的前置知识

Tapable 用法

三 打包流程

webpack.js

compiler.js

小结

webpack 是如何收集和分析依赖的？

热门文章

最新文章

相关课程

相关电子书

相关实验场景

一入口

二打包流程的前置知识

三打包流程