一、前言

Webpack 一直都是有些人的心魔，不清楚原理是什么，不知道怎么去配置，只会基本的 API 使用。它就像一个黑盒，让部分开发者对它望而生畏。

而本节最大的作用，就是帮大家一点一点的消灭心魔。

大家之所以认为 Webpack 复杂，很大程度上是因为它依附着一套庞大的生态系统。其实 Webpack 的核心流程远没有我们想象中那么复杂，甚至只需百来行代码就能完整复刻出来。

因此在学习过程中，我们应注重学习它本身的设计思想，不管是它的 Plugin 系统还是 Loader 系统，都是建立于这套核心思想之上。所谓万变不离其宗，一通百通。

在本文中，我将会从 Webpack 的整体流程出发，通篇采用结论先行、自顶向下的方式进行讲解。在涉及到原理性的知识时，尽量采用图文的方式辅以理解，注重实现思路，注重设计思想。

二、基本使用

初始化项目：

安装完依赖后，根据以下目录结构来添加对应的目录和文件：

webpack.config.js

src/index.js（本文不讨论CommonJS 和 ES Module之间的引用关系，以CommonJS为准）

src/name.js

src/age.js

文件依赖关系：

Webpack 本质上是一个函数，它接受一个配置信息作为参数，执行后返回一个 compiler 对象，调用 compiler 对象中的 run 方法就会启动编译。run 方法接受一个回调，可以用来查看编译过程中的错误信息或编译信息。

debugger.js

执行打包命令：

得到产出文件 dist/main.js（先暂停三十秒读一读下面代码，命名经优化）：

运行该文件，得到结果：

三、核心思想

我们先来分析一下源代码和构建产物之间的关系：

从图中可以看出，入口文件（src/index.js）被包裹在最后的立即执行函数中，而它所依赖的模块（src/name.js、src/age.js）则被放进了 modules 对象中（modules 用于存放入口文件的依赖模块，key 值为依赖模块路径，value 值为依赖模块源代码）。

require 函数是 web 环境下 加载模块的方法（ require 原本是 node环境 中内置的方法，浏览器并不认识 require，所以这里需要手动实现一下），它接受模块的路径为参数，返回模块导出的内容。

要想弄清楚 Webpack 原理，那么核心问题就变成了：如何将左边的源代码转换成 dist/main.js 文件？

核心思想：

• 第一步：首先，根据配置信息（webpack.config.js）找到入口文件（src/index.js）

• 第二步：找到入口文件所依赖的模块，并收集关键信息：比如路径、源代码、它所依赖的模块等：

  


• 
  

• 第三步：根据上一步得到的信息，生成最终输出到硬盘中的文件（dist）：包括 modules 对象、require 模版代码、入口执行文件等

在这过程中，由于浏览器并不认识除 html、js、css 以外的文件格式，所以我们还需要对源文件进行转换 —— **Loader 系统**。

Loader 系统 本质上就是接收资源文件，并对其进行转换，最终输出转换后的文件：

除此之外，打包过程中也有一些特定的时机需要处理，比如：

• 在打包前需要校验用户传过来的参数，判断格式是否符合要求

• 在打包过程中，需要知道哪些模块可以忽略编译，直接引用 cdn 链接

• 在编译完成后，需要将输出的内容插入到 html 文件中

• 在输出到硬盘前，需要先清空 dist 文件夹

• ......

这个时候需要一个可插拔的设计，方便给社区提供可扩展的接口 —— **Plugin 系统**。

Plugin 系统 本质上就是一种事件流的机制，到了固定的时间节点就广播特定的事件，用户可以在事件内执行特定的逻辑，类似于生命周期：

这些设计也都是根据使用场景来的，只有理清需求后我们才能更好的理解它的设计思想。

四、架构设计

在理清楚核心思想后，剩下的就是对其进行一步步拆解。

上面提到，我们需要建立一套事件流的机制来管控整个打包过程，大致可以分为三个阶段：

• 打包开始前的准备工作

• 打包过程中（也就是编译阶段）

• 打包结束后（包含打包成功和打包失败）

这其中又以编译阶段最为复杂，另外还考虑到一个场景：watch mode[1]（当文件变化时，将重新进行编译），因此这里最好将编译阶段（也就是下文中的compilation）单独解耦出来。

在 Webpack 源码中，compiler 就像是一个大管家，它就代表上面说的三个阶段，在它上面挂载着各种生命周期函数，而 compilation 就像专管伙食的厨师，专门负责编译相关的工作，也就是打包过程中这个阶段。画个图帮助大家理解：

大致架构定下后，那现在应该如何实现这套事件流呢？

这时候就需要借助 Tapable 了！它是一个类似于 Node.js 中的 EventEmitter 的库，但更专注于自定义事件的触发和处理。通过 Tapable 我们可以注册自定义事件，然后在适当的时机去执行自定义事件。

类比到 Vue 和 React 框架中的生命周期函数，它们就是到了固定的时间节点就执行对应的生命周期，tapable 做的事情就和这个差不多，我们可以通过它先注册一系列的生命周期函数，然后在合适的时间点执行。

example 🌰：

运行上面这段代码，得到结果：

在 Webpack 中，就是通过 tapable 在 comiler 和 compilation 上像这样挂载着一系列生命周期 Hook，它就像是一座桥梁，贯穿着整个构建过程：

五、具体实现

整个实现过程大致分为以下步骤：

• （1）搭建结构，读取配置参数

• （2）用配置参数对象初始化 Compiler 对象

• （3）挂载配置文件中的插件

• （4）执行 Compiler 对象的 run 方法开始执行编译

• （5）根据配置文件中的 entry 配置项找到所有的入口

• （6）从入口文件出发，调用配置的 loader 规则，对各模块进行编译

• （7）找出此模块所依赖的模块，再对依赖模块进行编译

• （8）等所有模块都编译完成后，根据模块之间的依赖关系，组装代码块 chunk

• （9）把各个代码块 chunk 转换成一个一个文件加入到输出列表

• （10）确定好输出内容之后，根据配置的输出路径和文件名，将文件内容写入到文件系统

5.1、搭建结构，读取配置参数

根据 Webpack 的用法可以看出， Webpack 本质上是一个函数，它接受一个配置信息作为参数，执行后返回一个 compiler 对象，调用 compiler 对象中的 run 方法就会启动编译。run 方法接受一个回调，可以用来查看编译过程中的错误信息或编译信息。

修改 debugger.js 中 webpack 的引用：

搭建结构：

运行流程图：

5.4、执行Compiler对象的run方法开始执行编译

重点来了！

在正式开始编译前，我们需要先调用 Compiler 中的 run 钩子，表示开始启动编译了；在编译结束后，需要调用 done 钩子，表示编译完成。

上面架构设计中提到过，编译这个阶段需要单独解耦出来，通过 Compilation 来完成，定义Compilation 大致结构：

运行流程图（点击可放大）：

5.5、根据配置文件中的entry配置项找到所有的入口

接下来就正式开始编译了，逻辑均在 Compilation 中。

在编译前我们首先需要知道入口文件，而 入口的配置方式[2] 有多种，可以配置成字符串，也可以配置成一个对象，这一步骤就是为了统一配置信息的格式，然后找出所有的入口（考虑多入口打包的场景）。

运行流程图（点击可放大）：

5.6、从入口文件出发，调用配置的loader规则，对各模块进行编译

Loader 本质上就是一个函数，接收资源文件或者上一个 Loader 产生的结果作为入参，最终输出转换后的结果。

写两个自定义 Loader 配置到 webpack.config.js 中：

webpack.config.js

这一步骤将从入口文件出发，然后查找出对应的 Loader 对源代码进行翻译和替换。

主要有三个要点：

• （6.1）把入口文件的绝对路径添加到依赖数组（this.fileDependencies）中，记录此次编译依赖的模块

• （6.2）得到入口模块的的 module 对象 （里面放着该模块的路径、依赖模块、源代码等）

• （6.2.1）读取模块内容，获取源代码

• （6.2.2）创建模块对象

• （6.2.3）找到对应的 Loader 对源代码进行翻译和替换

• （6.3）将生成的入口文件 module 对象 push 进 this.modules 中

6.1：把入口文件的绝对路径添加到依赖数组中，记录此次编译依赖的模块

这里因为要获取入口文件的绝对路径，考虑到操作系统的兼容性问题，需要将路径的 \ 都替换成 /：

6.2.1：读取模块内容，获取源代码

6.2.2：创建模块对象

6.2.3：找到对应的 Loader 对源代码进行翻译和替换

6.3：将生成的入口文件 module 对象 push 进 this.modules 中

运行流程图（点击可放大）：

5.7、找出此模块所依赖的模块，再对依赖模块进行编译

该步骤是整体流程中最为复杂的，一遍看不懂没关系，可以先理解思路。

该步骤经过细化可以将其拆分成十个小步骤：

• （7.1）：先把源代码编译成 AST[3]

• （7.2）：在 AST 中查找 require 语句，找出依赖的模块名称和绝对路径

• （7.3）：将依赖模块的绝对路径 push 到 this.fileDependencies 中

• （7.4）：生成依赖模块的模块 id

• （7.5）：修改语法结构，把依赖的模块改为依赖模块 id

• （7.6）：将依赖模块的信息 push 到该模块的 dependencies 属性中

• （7.7）：生成新代码，并把转译后的源代码放到 module._source 属性上

• （7.8）：对依赖模块进行编译（对 module 对象中的 dependencies 进行递归执行 buildModule ）

• （7.9）：对依赖模块编译完成后得到依赖模块的 module 对象，push 到 this.modules 中

• （7.10）：等依赖模块全部编译完成后，返回入口模块的 module 对象

运行流程图（点击可放大）：

5.8、等所有模块都编译完成后，根据模块之间的依赖关系，组装代码块 chunk

现在，我们已经知道了入口模块和它所依赖模块的所有信息，可以去生成对应的代码块了。

一般来说，每个入口文件会对应一个代码块chunk，每个代码块chunk里面会放着本入口模块和它依赖的模块，这里暂时不考虑代码分割。

运行流程图（点击可放大）：

5.9、把各个代码块 chunk 转换成一个一个文件加入到输出列表

这一步需要结合配置文件中的output.filename去生成输出文件的文件名称，同时还需要生成运行时代码：

到了这里，Compilation 的逻辑就走完了。

运行流程图（点击可放大）：

5.10、确定好输出内容之后，根据配置的输出路径和文件名，将文件内容写入到文件系统

该步骤就很简单了，直接按照 Compilation 中的 this.status 对象将文件内容写入到文件系统（这里就是硬盘）。

运行流程图（点击可放大）：

完整流程图

以上就是整个 Webpack 的运行流程图，还是描述的比较清晰的，跟着一步步走看懂肯定没问题！

执行 node ./debugger.js，通过我们手写的 Webpack 进行打包，得到输出文件 dist/main.js：

六、实现 watch 模式

看完上面的实现，有些小伙伴可能有疑问了：Compilation 中的 this.fileDependencies（本次打包涉及到的文件）是用来做什么的？为什么没有地方用到该属性？

这里其实是为了实现 Webpack 的 watch 模式[4]：当文件发生变更时将重新编译。

思路：对 this.fileDependencies 里面的文件进行监听，当文件发生变化时，重新执行 compile 函数。

相信看到这里，你一定也理解了 compile 和 Compilation 的设计，都是为了解耦和复用呀。

七、总结

本文从 Webpack 的基本使用和构建产物出发，从思想和架构两方面深度剖析了 Webpack 的设计理念。最后在代码实现阶段，通过百来行代码手写了 Webpack 的整体流程，尽管它只能对文件进行打包，还缺少很多功能，但麻雀虽小，却也五脏俱全。