再读 Webpack 源码，各个击破：从 Compiler 和 Compilation 说起-技术圈

前言

前端的发展，离不开打包工具的助推。关于打包工具种类繁多，其中 Webpack 作为佼佼者被广泛使用。通过配置选项和 Loader、Plugin，我们可以实现各种功能。那么 Webpack 内部到底是怎么运行，通过本系列的源码学习，希望能给笔者有一个完整的认识。

1、准备工作

1.1、工具及版本说明

首先，在阅读本文之前。我们先约定下本系列文章约定的源码版本，如下：

  webpack 4.46.0

对于 Node 版本，笔者使用的 14 的大版本，当然为了方便调试，建议使用不低于 10 的大版本。另外，我们使用 VSCode 进行调试和代码阅读。

1.2、约定及说明

阅读源码是一个学习的过程，当然也是一个比较痛苦的过程，尤其是 webpack 这种使用 hooks 来完成主流程的库。在主要步骤中会很跳跃，这一定程度上增加了源码阅读的难度，本文会集中在几个关键阶段或部分：compiler 、compilation 、Tapable 和 Hook、Module及其处理器 Loader、Plugin。并对行数过长的方法进行代码删减，保留一些关键代码的方法来让读者对整体执行流程有一个整体认识。然后，再根据自己的需要，按图索骥的对感兴趣的部分进行深入阅读。

2、源码分析

2.1、Webpack 执行入口

首先我们找到程序的入口位置，直接看 webpack 包（这个 node_modules\webpack 目录下）的 package.json 文件，并找到部分内容：

  "main": "lib/webpack.js",
  "web": "lib/webpack.web.js",
  "bin": "./bin/webpack.js",

其他我们都不看，直接关注 main 这个属性，这就是我们在 Node 环境中执行 webpack 的入口。那么，我们得到完整的 webpack 代码路径：

node_modules\webpack\lib\webpack.js

const webpack = (options, callback) => {
    ...
    let compiler;
  // 根据配置类型是数组还是对象，来创建 compiler 对象
    if (Array.isArray(options)) {
        ...
    } else if (typeof options === "object") {
    // 一般情况下，module.export 出来就是单个配置。我们可以主要看这里的代码

    // 首先，通过一个默认选项对象 WebpackOptionsDefaulter 对我们的配置项进行处理
        options = new WebpackOptionsDefaulter().process(options);


    // 创建 compiler 对象，该对象贯穿webpack的整个生命周期
        compiler = new Compiler(options.context);
        compiler.options = options;
        new NodeEnvironmentPlugin({
            infrastructureLogging: options.infrastructureLogging
        }).apply(compiler);
    // 重要！！！执行配置项里所有 plugin 对象的 apply 方法，如果是函数则执行该函数
        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);
                }
            }
        }
    // 执行完成环境配置步骤相关的 hooks
        compiler.hooks.environment.call();
        compiler.hooks.afterEnvironment.call();

    // 重要！！！process 方法将会添加更多的 plugin、初始化 resolver 以及执行 hooks
        compiler.options = new WebpackOptionsApply().process(options, compiler);
    }
    if (callback) {
    if (
            options.watch === true ||
            (Array.isArray(options) && options.some(o => o.watch))
        ) {
            const watchOptions = Array.isArray(options)
                ? options.map(o => o.watchOptions || {})
                : options.watchOptions || {};
      // 运行 compiler，这里会开启监听模式，后面会针对这个进行分析，
            return compiler.watch(watchOptions, callback);
        }
        ...
    // 运行 comiler，进行编译工作
        compiler.run(callback);
    }
    return compiler;
};

exports = module.exports = webpack;

通过以上的代码，主要完成了以下几个工作：

•1、配置项处理•2、创建 compiler 对象•3、执行配置项里 plugins 的 apply 方法•4、执行环境配置相关的 hooks•5、执行 WebpackOptionsApply 的 process 方法，这个方法的代码我在下面讲解•6、执行 compiler 的 run 或 watch 方法，真正的执行编译的任务

2.2、来自 WebpackOptionsApply.process 的加餐

上一节中提到 WebpackOptionsApply 的 process 方法，这个方法很长，大概4、500行（包括注释部分）。我们会针对这个方法进行重点解释。

process(options, compiler) {
    let ExternalsPlugin;
  // 上来是一大堆的属性配置，主要是一些输入、输出的路径
    compiler.outputPath = options.output.path;
  ……
  // 最终打包出的代码运行的目标环境，做一些插件创建和 apply 方法执行
    if (typeof options.target === "string") {
        let JsonpTemplatePlugin;
        let FetchCompileWasmTemplatePlugin;
        ……
        switch (options.target) {
            case "web":
        // 针对web浏览器目标环境的处理
                break;
            case "node":
            ...
            default:
                throw new Error("Unsupported target '" + options.target + "'.");
        }
    }
    ……
  // 如果是打包成一个库的配置处理
    if (options.output.library || options.output.libraryTarget !== "var") {
        const LibraryTemplatePlugin = require("./LibraryTemplatePlugin");
        new LibraryTemplatePlugin(
            options.output.library,
            options.output.libraryTarget,
            ……
        ).apply(compiler);
    }
  // 对于引入的依赖包在打包中进行去除，希望通过cdn方式或其他方式的处理
    if (options.externals) {
        ExternalsPlugin = require("./ExternalsPlugin");
        new ExternalsPlugin(
            options.output.libraryTarget,
            options.externals
        ).apply(compiler);
    }
  ……
  // sourcemap 的处理
    if (
        options.devtool &&
        (options.devtool.includes("sourcemap") ||
            options.devtool.includes("source-map"))
    ) {
    // sourcemap 参数处理
        const hidden = options.devtool.includes("hidden");
        const inline = options.devtool.includes("inline");
        ……
    // 插件处理
        const Plugin = evalWrapped
            ? EvalSourceMapDevToolPlugin
            : SourceMapDevToolPlugin;
        new Plugin({
            filename: inline ? null : options.output.sourceMapFilename,
            moduleFilenameTemplate: options.output.devtoolModuleFilenameTemplate,
            ……
        }).apply(compiler);
    } else if (options.devtool && options.devtool.includes("eval")) {
        ……
    }
    // compiler.hooks.entryOption 的执行
    compiler.hooks.entryOption.call(options.context, options.entry);

  // 严格模式的插件，这个我们在下面可以看一下它的源码部分
    new UseStrictPlugin().apply(compiler);
  ……
    // 在 optimization 中开启 sideEffects 的处理
    if (options.optimization.sideEffects) {
        const SideEffectsFlagPlugin = require("./optimize/SideEffectsFlagPlugin");
        new SideEffectsFlagPlugin().apply(compiler);
    }
  ……
    // 代码做 split
    if (options.optimization.splitChunks) {
        const SplitChunksPlugin = require("./optimize/SplitChunksPlugin");
        new SplitChunksPlugin(options.optimization.splitChunks).apply(compiler);
    }
    ……// 省略的这部分都和 module 和 chunk 相关
  // 压缩配置
    if (options.optimization.minimize) {
        for (const minimizer of options.optimization.minimizer) {
            if (typeof minimizer === "function") {
                minimizer.call(compiler, compiler);
            } else {
                minimizer.apply(compiler);
            }
        }
    }
    if (options.performance) {
        const SizeLimitsPlugin = require("./performance/SizeLimitsPlugin");
        new SizeLimitsPlugin(options.performance).apply(compiler);
    }
    ……
  // compiler.hooks.afterPlugins 调用
    compiler.hooks.afterPlugins.call(compiler);
    if (!compiler.inputFileSystem) {
        throw new Error("No input filesystem provided");
    }

  // compiler.resolverFactory.hooks 上挂一些钩子
    compiler.resolverFactory.hooks.resolveOptions
        .for("normal")
        .tap("WebpackOptionsApply", resolveOptions => {
            return Object.assign(
                {
                    fileSystem: compiler.inputFileSystem
                },
                cachedCleverMerge(options.resolve, resolveOptions)
            );
        });
    ……
  // compiler.hooks.afterResolvers 调用
    compiler.hooks.afterResolvers.call(compiler);
    return options;
}

ok，可以看到在进入到 compiler.run 之前，在这里又做了大量的工作。这里主要的工作集中在根据我们对于 webpack 的配置项进行插件的添加和 apply 方法的执行。我们在上面的代码讲解里有一个严格模式的插件，我们简单看下它的源码：

apply(compiler) {
    compiler.hooks.compilation.tap(
        "UseStrictPlugin",
        (compilation, { normalModuleFactory }) => {
            const handler = parser => {
                parser.hooks.program.tap("UseStrictPlugin", ast => {
                    const firstNode = ast.body[0];
                    ……// 一些处理代码 
                });
            };
            normalModuleFactory.hooks.parser
                .for("javascript/auto")
                .tap("UseStrictPlugin", handler);
            ……
        }
    );
}

这里它主要通过钩子方法，可以在对代码生成一颗抽象语法树 ast 之后，拿到 ast，并做一些工作。这个地方其实给了我们一些启示，能够针对 ast 进行一些操作，当然还可以使用 Babel 作为可选方案。

2.3、贯穿始终的 Compiler

Compiler 和 Compilation 是两个在 webpack 的 plugin 中常用的两个对象。二者也包含了很多的 hooks，这些 hooks 代表了 webpack 在执行过程的不同阶段。其中，通过前面的代码我们看到了 Compiler 的创建过程，它包含了很多的配置项 options，里面又包含了 Loader 和 Plugin 信息。其生命周期一直到 webpack 结束，几乎等同于 webpack 实例本身。

而 Compilation 到此为止，我们还没有看到。它其实只是一次编程过程，包含了 Module、编译后的输出等，同时他也拥有 Compiler 对象实例。

在上面对于 webpack 执行入口的源码分析中，我们看到了 compiler.watch 或 compiler.run 才真正执行起来。我们一般在开发阶段中会使用到 webpack-dev-server ，它这里 Watch 模式默认开启。本文要讲以 compiler.watch 方法作为入口继续源码的分析。

源码位置 node_modules\webpack\lib\Compiler.js

watch(watchOptions, handler) {
    if (this.running) return handler(new ConcurrentCompilationError());
    this.running = true;
    this.watchMode = true;
    ……
    return new Watching(this, watchOptions, handler);
}

前面的一些设置代码，我们可以忽略，直接看最后创建并返回了一个 Watching 对象。

class Watching {
    constructor(compiler, watchOptions, handler) {
        ……
        this.compiler = compiler;
        this.running = true;
    // 这里调用了 compiler.readRecords 方法，该方法比较简单，最后会执行回调方法
        this.compiler.readRecords(err => {
            if (err) return this._done(err);
      // 最后还是来到 _go 方法
            this._go();
        });
    }

    _go() {
        ……
    // 执行 compiler.hooks.watchRun
        this.compiler.hooks.watchRun.callAsync(this.compiler, err => {
            const onCompiled = (err, compilation) => {
        // 实际上最终执行的是 compiler.hooks.emit
                this.compiler.emitAssets(compilation, err => {
                    // 
                    this.compiler.emitRecords(err => {
                        ……
            // 执行
                        return this._done(null, compilation);
                    });
                });
            };
      // 在执行 compiler.hooks.watchRun 后，真正进入编译阶段，并传入 onCompiled 这个回调函数
            this.compiler.compile(onCompiled);
        });
    }

  _done(err, compilation) {
        this.running = false;
        if (err) {
      // 出错之后，执行 compiler.hooks.failed
            this.compiler.hooks.failed.call(err);
            return;
        }
    // 编译正常完成，执行 compiler.hooks.done
        this.compiler.hooks.done.callAsync(stats, () => {
            if (!this.closed) {
        // 监听，暂时略过
                this.watch(
                ……
                );
            }
            ……
        });
    }
}

ok，到这里可能有点混乱了，我们来理一理流程主线：

**Compiler.watch() ---->> Watching._go() ---->> Compiler.hooks.watchRun ---->> Compiler.compile(onCompiled) ---->> onCompiled ---->> 执行 Compiler.hooks.emit 和 Watching._done() ---->> Compiler.hooks.done (通过Watching._done执行到)**。

这个主线里，我们重点要记住 Compiler.hooks.emit 和 Compiler.hooks.done。前者是即将进行 output，这是我们最后能够修改模块内容的机会，后者则是完成编译文件输出。另外，在这个主线里，我们看到缺了 Compiler.compile(onCompiled) 这一部分的内容。接下来，我们继续 Compiler 的源码部分

node_modules\webpack\lib\Compiler.js

class Compiler extends Tapable {
    createCompilation() {
        return new Compilation(this);
    }

    newCompilation(params) {
        const compilation = this.createCompilation();
        ……
    // 执行两个 hooks，至此，compilation 才真正被创建
        this.hooks.thisCompilation.call(compilation, params);
        this.hooks.compilation.call(compilation, params);
        return compilation;
    }

    createNormalModuleFactory() {
        const normalModuleFactory = new NormalModuleFactory(……);
    // 调用 hooks.normalModuleFactory
        this.hooks.normalModuleFactory.call(normalModuleFactory);
        return normalModuleFactory;
    }

    createContextModuleFactory() {
        const contextModuleFactory = new ContextModuleFactory(this.resolverFactory);
    // 调用 hooks.contextModuleFactory
        this.hooks.contextModuleFactory.call(contextModuleFactory);
        return contextModuleFactory;
    }

    newCompilationParams() {
    // 主要是创建两个工厂实例
        const params = {
            normalModuleFactory: this.createNormalModuleFactory(),
            contextModuleFactory: this.createContextModuleFactory(),
            compilationDependencies: new Set()
        };
        return params;
    }

    compile(callback) {
    // 拿到创建 Compilation 的参数
        const params = this.newCompilationParams();
    // 执行 hooks.beforeCompile
        this.hooks.beforeCompile.callAsync(params, err => {
      // 执行 hooks.compile，到这里为止，compilation 还未创建
            this.hooks.compile.call(params);

      // 创建 Compilation 对象
            const compilation = this.newCompilation(params);
      // hooks.make 进入编译阶段
            this.hooks.make.callAsync(compilation, err => {
        // compilation 部分
                compilation.finish(err => {
                    compilation.seal(err => {
            // 执行 hooks.afterCompile，这里已经完成编译的部分
                        this.hooks.afterCompile.callAsync(compilation, err => {
              // 这里就是那个 onCompiled 回调最终被执行
                            return callback(null, compilation);
                        });
                    });
                });
            });
        });
    }
}

完成了上述代码的过程，我们对上面的 compiler.compile() 内部的流程主线可以归纳（侧重 hooks 部分）： compiler.compile() ---->> compiler.hooks.normalModuleFactory 和 compiler.hooks.contextModuleFactory ---->> compiler.hooks.beforeCompile ---->> compiler.hooks.compile ---->> compiler.hooks.thisCompilation ---->> compiler.hooks.compilation ---->> compiler.hooks.make ---->> compilation.finish() ---->> compilation.seal() ---->> compiler.hooks.afterCompile ---->> onCompiled()

hooks 本质上反映的是整个 webpack 运行的不同阶段。在上面这个主线中，我们其实重点关注两个点：

•compiler.hooks.make，从这里开始正式进入编译•compilation.seal() 函数，它的执行标识着封闭编译，不再添加 module

然后我们看到从 compiler.hooks.make 直接到了 compilation.finish() 这一步。中间经历了什么，我们在下一节中进行源码分析。

另外，上述代码中生成了两个工厂对象：ContextModuleFactory 和 NormalModuleFactory 。其中，ContextModuleFactory 用来解析目录，为每个文件生成请求，并依据传递来的 regExp 进行过滤。最后匹配成功的依赖关系将被传入 NormalModuleFactory 。NormalModuleFactory 用来生成各类模块。从入口点开始，它会分解每个请求，解析文件内容以查找进一步的请求，然后通过分解所有请求以及解析新的文件来爬取全部文件。在最后阶段，每个依赖项都会成为一个模块实例。

2.4、大包干的 Compilation

在上一节的最后，我们缺了一大块内部，就是怎么就从 compiler.hooks.make 直接到了 compilation.finish() 这一步？开发过 plugin 的同学应该知道，通过 hooks 我们可以通过 tap 方法去钩住某个执行阶段，compiler.hooks.make 执行就会触发这些 hooks。我们通过调试或在 ./node_modules/webpack 下用关键词搜索 hooks.make.tap 可以发现很多插件。比如：DllEntryPlugin、MultiEntryPlugin、AutomaticPrefetchPlugin、PrefetchPlugin等，我们以 MultiEntryPlugin 为例来看一下它的源码实现：

node_modules\webpack\lib\MultiEntryPlugin.js

class MultiEntryPlugin {
    apply(compiler) {
        compiler.hooks.make.tapAsync(
            "MultiEntryPlugin",
            (compilation, callback) => {
                const { context, entries, name } = this;

        // 生成一个 MultiEntryDependency 依赖对象
                const dep = MultiEntryPlugin.createDependency(entries, name);
        // 调用了 compilation.addEntry 方法
                compilation.addEntry(context, dep, name, callback);
            }
        );
    }
  static createDependency(entries, name) {
        return new MultiEntryDependency(
            entries.map((e, idx) => {
                const dep = new SingleEntryDependency(e);
                return dep;
            }),
            name
        );
    }
}

通过插件在 compiler.hooks.make 上挂的钩子，成功的从 compiler 转译到了 compilation 的执行阶段。compilation.addEntry(context, dep, name, callback) 方法从名字上，我们就可以看出是为编译添加入口，其实这并不难理解。接下来，我们看看 addEntry 方法之后都干了些什么：

node_modules\webpack\lib\Compilation.js

addEntry(context, entry, name, callback) {
    this.hooks.addEntry.call(entry, name);

  // 添加模块链接，其实就是从 entry 入口开始对每个模块 build，然后分析出依赖模型进行 build 的一个过程
    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);
  // dependencyFactories 里有很多类型的工厂对象，通过依赖的具体类型拿到工厂对象，暂时忽略下
    const moduleFactory = this.dependencyFactories.get(Dep);

    this.semaphore.acquire(() => {
    // 通过模块工厂对象创建模块，工厂的 create 方法，我们先放一下，在后面说。
        moduleFactory.create({},
            (err, module) => {
                // 添加模块
                const addModuleResult = this.addModule(module);

                const afterBuild = () => {
                    if (addModuleResult.dependencies) {
            // 处理依赖模块
                        this.processModuleDependencies(module, err => {});
                    }
                };

                if (addModuleResult.build) {
          // 开始构建模块
                    this.buildModule(module, false, null, null, err => {
            // 完成构建之后，继续后面有可能的依赖模块处理
                        afterBuild();
                    });
                }
            }
        );
    });
}

addModule(module, cacheGroup) {
  // 缓存，这里根据模块的标识符进行查找
    const identifier = module.identifier();
  // _modules 里存放的是已经添加的模块信息
    const alreadyAddedModule = this._modules.get(identifier);
    if (alreadyAddedModule) {
        return {
            module: alreadyAddedModule,
            issuer: false,
            build: false,
            dependencies: false
        };
    }
    const cacheName = (cacheGroup || "m") + identifier;
    if (this.cache && this.cache[cacheName]) {
        // 这里面主要是针对缓存部分有更新的处理，需要对模块进行 reBuild 处理
    }
    return {
        module: module,
        issuer: true,
        build: true,
        dependencies: true
    };
}

buildModule(module, optional, origin, dependencies, thisCallback) {
    // 在模块构建开始之前触发，可以用来修改模块。
    this.hooks.buildModule.call(module);

  // 使用模块对象进行构建
    module.build(
        this.options,
        this,
        this.resolverFactory.get("normal", module.resolveOptions),
        this.inputFileSystem,
        error => {
            // 执行成功构建的钩子
            this.hooks.succeedModule.call(module);
            return callback();
        }
    );
}

processModuleDependencies(module, callback) {
    this.addModuleDependencies(
        module,
        sortedDependencies,
        this.bail,
        null,
        true,
        callback
    );
}

addModuleDependencies(
    module,
    dependencies,
    bail,
    cacheGroup,
    recursive,
    callback
) {
    asyncLib.forEach(
        dependencies,
        (item, callback) => {
            semaphore.acquire(() => {
                const factory = item.factory;
                factory.create({},
                    (err, dependentModule) => {
                        const addModuleResult = this.addModule();
                        const afterBuild = () => {
                            if (recursive && addModuleResult.dependencies) {
                                this.processModuleDependencies(dependentModule, callback);
                            }
                        };

                        if (addModuleResult.build) {
                            this.buildModule(
                                err => {
                                    afterBuild();
                                }
                            );
                        }
                    }
                );
            });
        },
        err => {
        }
    );
}

这一块涉及到 compilation 中的几个方法，源码部分很多，笔者删除了大部分。主线捋一捋大致如下：通过 addEntry 找到入口模块然后把模块和依赖模块进行构建，构建过程是先构建当前模块，该过程伴随着缓存的处理和更新，真正的构建是通过具体模块对象的 module.build 方法进行（这个后面系列的文章中分析）。构建完当前模块后对分析出来的依赖模型就行构建，不断重复该过程直至所有的模块构建完毕。在这个过程中伴随着一些 hooks 的执行。

那么回到之前的那个问题，现在我们知道了如何从 compiler.hooks.make 顺滑的走到了 compilation.addEntry ，最终完成模块的构建工作。单个模块完成构建工作后执行了 compilation.hooks.succeedModule 钩子。那么，webpack 如何确定所有的模块以及构建完成最终执行了 compilation.finish() 呢？这个问题，我们放到下一篇文章中去介绍 Tapable 和 Hook。另外，我们在上面的源码分析中留下了一个问题就是模块如何构建，这个在系列三中去解答。