前言

webpack是一个强大的打包工具，拥有灵活、丰富的插件机制，网上关于如何使用webpack及webpack原理分析的技术文档层出不穷。最近自己也在学习webpack的过程中，记录并分享一下，希望对你有点帮助。本文主要探讨，webpack的一次构建流程中，主要干了哪些事儿。（咱们只研究研究构建的整体流程哈，细节不看🙈）

已知，Webpack 源码是一个插件的架构，很多功能都是通过诸多的内置插件实现的。Webpack为此专门自己写一个插件系统，叫 Tapable 主要提供了注册和调用插件的功能。一起研究之前，希望你对 tapable 有所了解～

调试

阅读源码最直接的方式是在 chrome 中通过断点在关键代码上进行调试，我们可以用 node-inspector进行此次debugger。

"scripts": {
    "build": "webpack --config webpack.prod.js",
    "debug": "node --inspect-brk ./node_modules/webpack/bin/webpack.js --inline --progress",
},

执行npm run build && npm run debug

// 入口文件
import { helloWorld } from './helloworld.js';
document.write(helloWorld());

// helloworld.js
export function helloWorld() {
    return 'bts';
}

// webpack.prod.js
module.exports = {
    entry: {
        index: './src/index.js',
    },
    output: {
        path: path.resolve(__dirname, 'dist'),
        filename: '[name]_[chunkhash:8].js'
    },
    module: {
        rules: [
            {
                test: /.js$/,
                use: 'babel-loader',
            },
        ]
    },
};

基本架构

先通过一张大图整体梳理一下webpack的主体流程，再细节一点的稍后再介绍

流程图中展示了些核心任务点，简要说明下这些任务点做了事儿：

通过 yargs 解析 config 与 shell 中的配置项
webpack 初始化过程，首先会根据第一步的 options 生成 compiler 对象，然后初始化 webpack 的内置插件及 options 配置
run 代表编译的开始，会构建 compilation 对象，用于存储这一次编译过程的所有数据
make 执行真正的编译构建过程，从入口文件开始，构建模块，直到所有模块创建结束
seal 生成 chunks，对 chunks 进行一系列的优化操作，并生成要输出的代码
seal 结束后，Compilation 实例的所有工作到此也全部结束，意味着一次构建过程已经结束
emit 被触发之后，webpack 会遍历 compilation.assets, 生成所有文件，然后触发任务点 done，结束构建流程

构建流程

在学习其他技术博客时都有类似上面的主体流程的分析，道理都懂，但不打断点看的细节点，说服不了自己。以下是一些任务点的详细动作，建议有兴趣的小伙伴多打几个debugger

强烈建议在每个重要钩子的回调函数中打debugger，不然可能跳着跳着就走远了

webpack准备阶段

webpack启动入口，webpack-cli/bin/cli.js

const webpack = require("webpack");
    // 使用yargs来解析命令行参数并合并配置文件中的参数(options)，
    // 然后调用lib/webpack.js实例化compile 并返回
let compiler;
try {
	compiler = webpack(options);
} catch (err) {}

// lib/webpack.js
const webpack = (options, callback) => {
    // 首先会检查配置参数是否合法
    
    // 创建Compiler
    let compiler;
    compiler = new Compiler(options.context);
    
    compiler.options = new WebpackOptionsApply().process(options, compiler);
    
    ...
    if (options.watch === true || ..) {
        ...
        return compiler.watch(watchOptions, callback);
    }
	compiler.run(callback);
}

创建Compiler

创建了 compiler 对象，compiler 可以理解为 webpack 编译的调度中心，是一个编译器实例，在 compiler 对象记录了完整的 webpack 环境信息，在 webpack 的每个进程中，compiler 只会生成一次。

class Compiler extends Tapable {
    constructor(context) {
        super();
        this.hooks = {
            beforeCompile: new AsyncSeriesHook(["params"]),
            compile: new SyncHook(["params"]),
            afterCompile: new AsyncSeriesHook(["compilation"]),
            make: new AsyncParallelHook(["compilation"]),
            entryOption: new SyncBailHook(["context", "entry"])
            // 定义了很多不同类型的钩子
        };
        // ...
    }
}

可以看到 Compiler 对象继承自 Tapable，初始化时定义了很多钩子。

初始化默认插件和Options配置

WebpackOptionsApply 类中会根据配置注册对应的插件，其中有个比较重要的插件

new EntryOptionPlugin().apply(compiler);
compiler.hooks.entryOption.call(options.context, options.entry);

EntryOptionPlugin插件中订阅了compiler的entryOption钩子，并依赖SingleEntryPlugin插件

module.exports = class EntryOptionPlugin {
	apply(compiler) {
		compiler.hooks.entryOption.tap("EntryOptionPlugin", (context, entry) => {
			return new SingleEntryPlugin(context, item, name);
		});
	}
};

SingleEntryPlugin 插件中订阅了 compiler 的 make 钩子，并在回调中等待执行 addEntry，但此时 make 钩子还并没有被触发哦

apply(compiler) {
    compiler.plugin("compilation", (compilation, params) => {
        const normalModuleFactory = params.normalModuleFactory;
        // 这里记录了 SingleEntryDependency 对应的工厂对象是 NormalModuleFactory
        compilation.dependencyFactories.set(SingleEntryDependency, normalModuleFactory);
    });
    compiler.hooks.make.tapAsync(
        "SingleEntryPlugin",
        (compilation, callback) => {
        	const { entry, name, context } = this;
        
        	// 创建单入口依赖 
        	const dep = SingleEntryPlugin.createDependency(entry, name);
        	// 正式进入构建阶段
        	compilation.addEntry(context, dep, name, callback);
        }
    );
}

run

初始化 compiler 后，根据 options 的 watch 判断是否启动了 watch，如果启动 watch 了就调用 compiler.watch 来监控构建文件，否则启动 compiler.run 来构建文件，compiler.run 就是我们此次编译的入口方法，代表着要开始编译了。

构建编译阶段

调用 compiler.run 方法来启动构建

run(callback) {
    const onCompiled = (err, compilation) => {
    	this.hooks.done.callAsync(stats, err => {
    		return finalCallback(null, stats);
    	});
    };
    
    // 执行订阅了compiler.beforeRun钩子插件的回调
    this.hooks.beforeRun.callAsync(this, err => {
        // 执行订阅了compiler.run钩子插件的回调
    	this.hooks.run.callAsync(this, err => {
    		this.compile(onCompiled);
    	});
    });
}

compiler.compile 开始真正执行我们的构建流程，核心代码如下

compile(callback) {
    // 实例化核心工厂对象
    const params = this.newCompilationParams();
    // 执行订阅了compiler.beforeCompile钩子插件的回调
    this.hooks.beforeCompile.callAsync(params, err => {
        // 执行订阅了compiler.compile钩子插件的回调
        this.hooks.compile.call(params);
        // 创建此次编译的Compilation对象
        const compilation = this.newCompilation(params);
        
        // 执行订阅了compiler.make钩子插件的回调
        this.hooks.make.callAsync(compilation, err => {
            
            compilation.finish(err => {
                compilation.seal(err => {
                    this.hooks.afterCompile.callAsync(compilation, err => {
                		return callback(null, compilation);
                	});
                })
            })
        })
    })
}

在compile阶段，Compiler 对象会开始实例化两个核心的工厂对象，分别是 NormalModuleFactory 和 ContextModuleFactory。工厂对象顾名思义就是用来创建实例的，它们后续用来创建 module 实例的，包括 NormalModule 以及 ContextModule 实例。

Compilation

创建此次编译的 Compilation 对象，核心代码如下：

newCompilation(params) {
    // 实例化Compilation对象
    const compilation = new Compilation(this);
    this.hooks.thisCompilation.call(compilation, params);
    // 调用this.hooks.compilation通知感兴趣的插件
    this.hooks.compilation.call(compilation, params);
    return compilation;
}

Compilation 对象是后续构建流程中最核心最重要的对象，它包含了一次构建过程中所有的数据。也就是说一次构建过程对应一个 Compilation 实例。在创建 Compilation 实例时会触发钩子 compilaiion 和 thisCompilation。

在Compilation对象中：

modules 记录了所有解析后的模块

chunks 记录了所有chunk

assets记录了所有要生成的文件

上面这三个属性已经包含了 Compilation 对象中大部分的信息，但目前也只是有个大致的概念，特别是 modules 中每个模块实例到底是什么东西，并不太清楚。先不纠结，毕竟此时 Compilation 对象刚刚生成。

make

当 Compilation 实例创建完成之后，webpack 的准备阶段已经完成，下一步将开始 modules 的生成阶段。

this.hooks.make.callAsync() 执行订阅了 make 钩子的插件的回调函数。回到上文，在初始化默认插件过程中（WebpackOptionsApply类），SingleEntryPlugin 插件中订阅了 compiler 的 make 钩子，并在回调中等待执行 compilation.addEntry 方法。

生成modules

compilation.addEntry 方法会触发第一批 module 的解析，即我们在 entry 中配置的入口文件 index.js。在深入 modules 的构建流程之前，我们先对模块实例 module 的概念有个了解。

modules

一个依赖对象（Dependency）经过对应的工厂对象（Factory）创建之后，就能够生成对应的模块实例（Module）。

Dependency，可以理解为还未被解析成模块实例的依赖对象。比如配置中的入口模块，或者一个模块依赖的其他模块，都会先生成一个 Dependency 对象。每个 Dependency 都会有对应的工厂对象，比如我们这次debuger的代码，入口文件 index.js 首先生成 SingleEntryDependency，对应的工厂对象是 NormalModuleFactory。(前文说到SingleEntryPlugin插件时有放代码，有疑惑的同学可以往前翻翻看)

// 创建单入口依赖 
const dep = SingleEntryPlugin.createDependency(entry, name);
// 正式进入构建阶段
compilation.addEntry(context, dep, name, callback);

SingleEntryPlugin插件订阅的make事件，将创建的单入口依赖传入compilation.addEntry方法，addEntry主要执行_addModuleChain()

_addModuleChain

_addModuleChain(context, dependency, onModule, callback) {
   ...
   
   // 根据依赖查找对应的工厂函数
   const Dep = /** @type {DepConstructor} */ (dependency.constructor);
   const moduleFactory = this.dependencyFactories.get(Dep);
   
   // 调用工厂函数NormalModuleFactory的create来生成一个空的NormalModule对象
   moduleFactory.create({
       dependencies: [dependency]
       ...
   }, (err, module) => {
       ...
       const afterBuild = () => {
   	    this.processModuleDependencies(module, err => {
       		if (err) return callback(err);
       		callback(null, module);
           });
   	};
       
       this.buildModule(module, false, null, null, err => {
           ...
           afterBuild();
       })
   })
}

_addModuleChain中接收参数dependency传入的入口依赖，使用对应的工厂函数NormalModuleFactory.create方法生成一个空的module对象，回调中会把此module存入compilation.modules对象和dependencies.module对象中，由于是入口文件，也会存入compilation.entries中。随后执行buildModule进入真正的构建module内容的过程。

buildModule

buildModule方法主要执行module.build()，对应的是NormalModule.build()

// NormalModule.js
build(options, compilation, resolver, fs, callback) {
    return this.doBuild(options, compilation, resolver, fs, err => {
        ...
        // 一会儿讲
    }
}

先来看看doBuild中做了什么

doBuild(options, compilation, resolver, fs, callback) {
    ...
    runLoaders(
    	{
            resource: this.resource, //   /src/index.js
            loaders: this.loaders, // `babel-loader`
            context: loaderContext,
            readResource: fs.readFile.bind(fs)
    	},
    	(err, result) => {
    	    ...
    	    const source = result.result[0]; 
    	    
    	    this._source = this.createSource(
            	this.binary ? asBuffer(source) : asString(source),
            	resourceBuffer,
            	sourceMap
            );
    	}
    )
}

一句话说，doBuild 调用了相应的 loaders ，把我们的模块转成标准的JS模块。这里，使用babel-loader 来编译 index.js ，source就是 babel-loader 编译后的代码。

// source
"debugger; import { helloWorld } from './helloworld.js';document.write(helloWorld());”

同时，还会生成this._source对象，有name和value两个字段，name就是我们的文件路径，value就是编译后的JS代码。模块源码最终是保存在 _source 属性中，可以通过 _source.source() 来得到。回到刚刚的NormalModule中的build方法

build(options, compilation, resolver, fs, callback) {
    ...
    return this.doBuild(options, compilation, resolver, fs, err => {
        const result = this.parser.parse(
        	this._source.source(),
        	{
        		current: this,
        		module: this,
        		compilation: compilation,
        		options: options
        	},
        	(err, result) => {
        		
        	}
        );
    }
}

经过 doBuild 之后，我们的任何模块都被转成了标准的JS模块。接下来就是调用Parser.parse方法，将JS解析为AST。

// Parser.js
const acorn = require("acorn");
const acornParser = acorn.Parser;
static parse(code, options) {
    ...
    let ast = acornParser.parse(code, parserOptions);
    return ast;
}

生成的AST结果如下：

解析成AST最大作用就是收集模块依赖关系，webpack会遍历AST对象，遇到不同类型的节点执行对应的函数。比如调试代码中出现的import { helloWorld } from './helloworld.js' 或const xxx = require('XXX')的模块引入语句，webpack会记录下这些依赖项，并记录在module.dependencies数组中。到这里，入口module的解析过程就完成了，解析后的module大家有兴趣可以打印出来看下，这里我只截图了module.dependencies数组。

每个 module 解析完成之后，都会触发 Compilation例对象的succeedModule钩子，订阅这个钩子获取到刚解析完的 module 对象。随后，webpack会遍历module.dependencies数组，递归解析它的依赖模块生成module，最终我们会得到项目所依赖的所有 modules。遍历的逻辑在afterBuild() -> processModuleDependencies() -> addModuleDependencies() -> factory.create()。

make阶段到此结束，接下去会触发compilation.seal方法，进入下一个阶段。

生成chunks

compilation.seal 方法主要生成chunks，对chunks进行一系列的优化操作，并生成要输出的代码。webpack 中的 chunk ，可以理解为配置在 entry 中的模块，或者是动态引入的模块。

chunk内部的主要属性是_modules，用来记录包含的所有模块对象。所以要生成一个chunk，就先要找到它包含的所有modules。下面简述一下chunk的生成过程：

先把 entry 中对应的每个 module 都生成一个新的 chunk
遍历module.dependencies，将其依赖的模块也加入到上一步生成的chunk中
若某个module是动态引入的，为其创建一个新的chunk，接着遍历依赖

下图是我们此次demo生成的this.chunks，_modules中有两个模块，分别是入口index模块，与其依赖helloworld模块。

在生成chunk的过程中与过程后，webpack会对chunk和module进行一系列的优化操作，优化操作大都是由不同的插件去完成。可见compilation.seal 方法中，有大量的钩子执行的代码。

this.hooks.optimizeModulesBasic.call(this.modules);
this.hooks.optimizeModules.call(this.modules);
this.hooks.optimizeModulesAdvanced.call(this.modules);

this.hooks.optimizeChunksBasic.call(this.chunks, this.chunkGroups);
this.hooks.optimizeChunks.call(this.chunks, this.chunkGroups);
this.hooks.optimizeChunksAdvanced.call(this.chunks, this.chunkGroups);

...

例如，插件SplitChunksPlugin订阅了compilation的optimizeChunksAdvanced钩子。至此，我们的modules和chunks都生成了，该去生成文件了。

生成文件

首先需要生成最终的代码，主要在compilation.seal 中调用了 compilation.createChunkAssets方法。

for (let i = 0; i < this.chunks.length; i++) {
    const chunk = this.chunks[i];
    const template = chunk.hasRuntime()
        ? this.mainTemplate
        : this.chunkTemplate;
    const manifest = template.getRenderManifest({
        ...
    })
    ...
    for (const fileManifest of manifest) {
        source = fileManifest.render();
    }
    
    ...
    this.emitAsset(file, source, assetInfo);
    
}

createChunkAssets方法会遍历chunks，来渲染每一个chunk生成代码。其实，compilation对象在实例化时，同时还会实例化三个对象，分别是MainTemplate, ChunkTemplate和ModuleTemplate。这三个对象是用来渲染chunk，得到最终代码模板的。它们之间的不同在于，MainTemplate用来渲染入口 chunk，ChunkTemplate用来渲染非入口 chunk，ModuleTemplate用来渲染 chunk 中的模块。

这里， MainTemplate 和 ChunkTemplate 的 render 方法是用来生成不同的"包装代码"的，MainTemplate 对应的入口 chunk 需要带有 webpack 的启动代码，所以会有一些函数的声明和启动。而包装代码中，每个模块的代码是通过 ModuleTemplate 来渲染的，不过同样只是生成”包装代码”来封装真正的模块代码，而真正的模块代码，是通过模块实例的 source 方法来提供。这么说可能不是很好理解，直接看看最终生成文件中的代码，如下：

每个chunk的源码生成之后，会调用 emitAsset 将其存在 compilation.assets 中。当所有的 chunk 都渲染完成之后，assets 就是最终更要生成的文件列表。至此，compilation 的 seal 方法结束，也代表着 compilation 实例的所有工作到此也全部结束，意味着一次构建过程已经结束，接下来只有文件生成的步骤了。

emit

在 Compiler 开始生成文件前，钩子 emit 会被执行，这是我们修改最终文件的最后一个机会，生成的在此之后，我们的文件就不能改动了。

this.hooks.emit.callAsync(compilation, err => {
    if (err) return callback(err);
    outputPath = compilation.getPath(this.outputPath);
    this.outputFileSystem.mkdirp(outputPath, emitFiles);
});

webpack 会直接遍历 compilation.assets 生成所有文件，然后触发钩子done，结束构建流程。

总结

我们将webpack核心的构建流程都过了一遍，希望在阅读完全文之后，对大家了解 webpack原理有所帮助～

本片文章代码都是经过删减更改处理的，都是为了能更好的理解。能力有限，如果有不正确的地方欢迎大家指正，一起交流学习。