人之所以不快乐，主要是缘于过去和未来：为过去耿耿于怀，为未来惴惴不安

大家好，我是柒八九。

在前期，我们开了一个关于前端工程化的系列文章。已经从

• 概念介绍
  • 何为脚手架
  • SourceMap 的常规概念
  • 在Webpack 中针对SourceMap的配置
• 构建工具
  • 构建解决的问题
  • 包管理工具
  • 模块化常见方式

等角度进行了一些常规概念的介绍和梳理。而今天，我们选择了一个在前端范围内，占很大比重的构建工具--Webpack。

近一年的npm下载量

github对应的stars

可以看到，无论是从npm 下载量和github的star的数量,Webpack都遥遥领先于其他工具(grunt/gulp/rollup/swc)

Webpack 是一个非常强大的构建工具，它可以被认为是当今许多技术中的一个基本组件，前端开发人员使用它来构建他们的应用程序。

好了，话不多说，继续赶路。

::: block-1

你能所学到的知识点

1. Webpack常见概念(entry/output/loader)
2. 从entry对象{a:'./a.js'}如何构建一个模块树
   
   entry=>EntryPlugin=>EntryDependency=>NormalModuleFactory=>模块树
3. ModuleGraph 如何跟踪已建模块直接的关系
4. ModuleGraph是如何被构建的
5. Module/Chunk/ ChunkGroup /EntryPoint具体是啥并它们直接的关系
6. ChunkGraph是如何被构建的
   :::

文章概要

1. Webpack基本概念简讲
2. 打包流程总览
3. entry对象
4. 深入理解 ModuleGraph
5. 构建ModuleGraph
6. Module/Chunk/ ChunkGroup /EntryPoint 是个啥
7. 提交chunk资源

0. Webpack基本概念简讲

本质上，webpack 是一个现代 JavaScript 应用程序的静态<span style="font-weight:800;color:#FFA500;font-size:18px">{模块打包器| module bundler}</span>

当 webpack 处理应用程序时，它会递归地构建一个<span style="font-weight:800;color:#FFA500;font-size:18px">{依赖关系图| dependency graph}</span>，其中包含应用程序需要的每个模块，然后将所有这些模块打包成一个或多个 bundle。

运行方式

在项目中有两种运行 Webpack 的方式：

1. 基于命令行的方式
   
   webpack --config webpack.config.js
2. 基于代码的方式

var webpack = require('webpack') 
var config = require('./webpack.config')
webpack(config, (err, stats) => {})

重要概念

针对Webpack有几个重要的概念需要知晓。

1. 打包流程总览

在此篇文章中，我们只针对NormalModules进行讲解。当然，还有其他类型的模块 如 ExternalModule 和 ConcatenatedModule（当使用require.context()时）这些都不在我们讨论范围内。

先来一个总体流程，润润嗓子。(莫慌，关键的点，后面都会做解释)

2. entry对象

一切都从entry对象开始

我们用一个简单例子来说明它的作用，在这个例子中，entry对象只是一个键值对的集合。

// webpack.config.js
entry: {
    a: './a.js',
    b: './b.js',
    /* ... */
}

webpack 中的模块与文件是一一对应的。

因此，在上面的代码中，a.js会产生一个新的模块，而b.js也会产生。

模块是文件的升级版。
模块，一旦创建和构建，除了源代码，还包含很多有意义的信息，如：

• 使用的加载器
• 它的依赖关系
• 它的出口（如果有的话）
• 它的哈希值

同时entry对象中的每一项都可以被认为是模块树中的根模块。模块树是因为根模块可能需要一些其他的模块，这些模块可能需要其他的模块，等等。所有这些模块树都被储存在 ModuleGraph中。

我们需要提到的下一件事是，webpack是建立在很多插件之上的。人们有很多方法可以加入自定义逻辑。webpack的可扩展性是通过hook实现的。例如，你可以在 ModuleGraph 建立后，当一个新的<span style="font-weight:800;color:#FFA500;font-size:18px">{资源|asset }</span>被生成时，在模块即将被建立前（运行加载器和解析源代码），添加自定义逻辑。大多数时候，hook是根据它们的目的分组的，对于任何定义好的目的，都有一个<span style="font-weight:800;color:#FFA500;font-size:18px">{插件| plugin}</span>。例如，有一个插件负责处理import()函数（负责解析注释和参数）--它被称为 ImportParserPlugin，它所做的就是在 AST 解析过程中遇到import()调用时，添加一个hook。

有几个插件负责处理entry对象。有一个 EntryOptionPlugin，它实际上是接收entry对象，并为对象中的每个项目创建一个 EntryPlugin对象。entry对象的每个项目都会产生一棵模块树（所有这些树都是相互分离的）。基本上，EntryPlugin 开始创建一个模块树，每个模块都会在同一个地方（ModuleGraph）添加信息。

EntryPlugin 也是创建 EntryDependency 的地方。

基于上图，让我们简单地实现自定义的EntryOptionsPlugin。

class CustomEntryOptionPlugin {
  // 这是创建插件的标准方法(实现apply方法)
  // 就是一个简单的函数
  apply(compiler) {
    compiler.hooks.entryOption.tap('CustomEntryOptionPlugin', entryObject => {

      // 对于`entryObject`中的每个项，我们为其创建一个模块树。
      // 记住，每个模块树都是独立的
      
               // `entryObject`可以是这样的。`{ a: './a.js' }`
      for (const name in entryObject) {
        const fileName = entryObject[name];
        // 当打包过程开始时，准备为这个entryObject创建一个模块树。
        new EntryOption({ name, fileName }).apply(compiler);
      };
    });
  }
};

代码解析：

• hook 为我们提供了介入打包过程的可能性。
• 在entryOptionhook的帮助下，我们添加了一个逻辑。
• 此时基本上意味着打包过程的开始。
• entryObject参数将保存来自配置文件的entry对象。
• 配置文件中的entry对象，将用它来设置创建模块树。

EntryOption插件的定义

// `EntryOption`类将处理模块树的创建。
class EntryOption {
  constructor (options) {
    this.options = options;
  };

  // 这仍然是一个插件，所以我们要遵守标准(实现apply)
  apply(compiler) {
    
    compiler.hooks.start('EntryOption', ({ createModuleTree }) => {
      // 基于这个插件的配置，创建新的模块树。
      
      createModuleTree(new EntryDependency(this.options));
    });
  };
};

代码解析：

• start钩子标志着打包过程的开始。 它将在调用hooks.entryOption之后被调用。
• options包含entry名称（本质上就是块的名称）和文件名。
• EntryDependency封装了这些选项，同时也提供了创建模块的方法。
• 在调用createModuleTree后，文件的源代码将被找到。
• 然后，一个模块实例将被创建，然后webpack将得到它的AST，并且将在打包过程中进一步使用

上面代码中，我们提到了EntryDependency，我们来一步了解一下。

当涉及到创建新模块时，这一切都归结为一个抽象过程。简单地说，一个<span style="font-weight:800;color:#FFA500;font-size:18px">{依赖关系|dependency }</span>只是一个实际模块实例的初步入口。例如，在 webpack 的观点中，甚至entry对象的项也是依赖关系，它们表明了创建模块实例的最低限度：它的路径（例如./a.js, ./b.js）。如果没有依赖关系，模块的创建就无法开始，因为依赖关系除其他重要信息外，还包含模块的请求，即可以找到模块源代码的文件的路径（例如"./a.js"）。

依赖关系还表明如何构建该模块，它通过<span style="font-weight:800;color:#FFA500;font-size:18px">{模块工厂|ModuleFactory}</span>来实现。模块工厂知道如何从一个原始状态（例如源代码是一个简单的字符串）开始，然后到达具体的实体文件，然后被webpack利用。EntryDependency 实际上是 ModuleDependency 的一种类型，意味着它肯定会持有模块的请求，它所指向的模块工厂是 NormalModuleFactory。那么，NormalModuleFactory 就知道要做什么，以便从一个路径中创建对webpack有意义的东西。

另一种思考方式是，模块起初只是一个简单的路径（要么在entry对象中，要么是import语句的一部分），然后它变成了一个依赖关系，最后变成了一个模块。

因此，EntryDependency 在一开始创建模块树的根模块时就被使用。
对于其余的模块，还有其他类型的依赖关系。例如，如果你使用import语句，比如从./a.js导入 defaultFn，那么就会有一个 HarmonyImportSideEffectDependency，./a.js持有模块的请求，也映射到 NormalModuleFactory。因此，将有一个新的模块用于'a.js'文件。

快速回顾一下我们在本节中所学到的内容：

• 对于entry对象中的每一项，都会有一个 EntryPlugin 实例，其中创建了一个 EntryDependency。
• 这个 EntryDependency 保存了模块的请求（即文件的路径），并且通过映射到一个模块工厂，即 NormalModuleFactory，提供了一种使该请求有用的方法。
• <span style="font-weight:800;color:#FFA500;font-size:18px">{模块工厂|ModuleFactory}</span>知道如何从一个文件路径中创建对webpack有用的实体。
• <span style="font-weight:800;color:#FFA500;font-size:18px">{依赖关系|dependency }</span>对创建一个模块至关重要，因为它拥有重要的信息，比如模块的请求和如何处理该请求。依赖关系有几种类型，并不是所有的依赖关系都对创建一个新模块有用。
• 从每个 EntryPlugin 实例，在新创建的 EntryDependency 的帮助下，将创建一个模块树。模块树是建立在模块和它们的依赖关系之上的，这些模块也可以有依赖关系。

3. 深入理解 ModuleGraph

ModuleGraph 是一种跟踪已建模块的方法。

它在很大程度上依赖于<span style="font-weight:800;color:#FFA500;font-size:18px">{依赖关系|dependency }</span>，因为它们提供了连接两个不同模块的方法。

比如说。

// a.js
import defaultBFn from '.b.js/';

// b.js
export default function () { console.log('我是大帅 B!'); }

这里我们有两个文件，所以有两个模块。文件a需要文件b的一些东西，所以在a中存在一个依赖关系，这个依赖关系是通过导入语句建立的。就 ModuleGraph 而言，依赖关系定义了一种连接两个模块的方式。上面的片段可以被可视化为:

ModuleGraph 的节点被称为 ModuleGraphModule，它只是一个装饰过的NormalModule实例。ModuleGraph 在一个map对象的帮助下跟踪这些装饰过的模块，它有这样的签名：Map<Module, ModuleGraphModule>。

例如，如果只有 NormalModule 实例，那么你对它们就没有什么可做的，它们不知道如何相互交流。ModuleGraph 赋予这些原始模块能通过上述map的帮助将它们相互连接起来的能力，该map为每个NormalModule分配了一个ModuleGraphModule。我们将把属于ModuleGraph的模块也称为模块，因为NormalModule和ModuleGraphModule区别在于只包括一些额外的无关紧要属性。

对于一个属于 ModuleGraph 的节点来说，有几件事情是明确的：传入的连接和传出的连接。连接是 ModuleGraph 的另一个小实体，它拥有有意义的信息，如：起源模块、目标模块和连接上述两个模块的依赖关系。具体来说，基于上图，一个新的连接已经被创建。

//这是以上面的图和代码为基础的形成的连接关系
Connection: {
    originModule: A, // 起源模块
    destinationModule: B, // 目标模块
    dependency: ImportDependency // 依赖关系
}

而上述连接对象将被添加到A.outgoingConnections集和和B.incomingConnections集和中。

所有从entry中创建的模块树都将向同一个单一的地方，即向ModuleGraph输出有意义的信息。这是因为所有这些模块树最终都将与空模块（ModuleGraph的根模块）相连。与空模块的连接是通过 EntryDependency 和从entry文件中创建的模块建立的。

空模块与每个模块树的根模块有一个连接，该模块由entry对象中的一个项目生成。图中的每条边都代表2个模块之间的连接，每个连接都有关于源节点、目标节点和依赖关系的信息。

4. 构建ModuleGraph

ModuleGraph 从一个空模块开始，其直系子孙是模块树的根模块，这些模块是由entry对象项构建的

首批创建的模块

我们从一个简单的entry对象开始。

entry: {
    a: './a.js',
}

正如我们上文说到，在某些时候，我们最终会得到一个 EntryDependency，其请求是./a.js。这个 EntryDependency 提供了一种从该请求创建有意义的东西的方法，因为它映射到一个模块工厂，即 NormalModuleFactory。

这个过程的下一步是 NormalModuleFactory 发挥作用的地方。NormalModuleFactory，如果它成功地完成了它的任务，将创建一个NormalModule。

NormalModule只是一个文件源代码的反序列化版本，它只不过是一个原始字符串。
一个原始的字符串不会带来太多的价值，所以webpack不能用它做什么。一个NormalModule会将源代码存储为一个字符串，但是，与此同时，它也会包含其他有意义的信息和功能，比如：

• 应用于它的加载器
• 构建模块的逻辑
• 生成运行时代码的逻辑
• 它的哈希值等等

换句话说，从 webpack 的角度来看，NormalModule 是一个简单原始文件的有用版本。

为了让 NormalModuleFactory 输出一个 NormalModule，它必须要经过一些步骤。在模块被创建后，还有一些事情要做，比如构建模块和处理其依赖关系（如果有的话）。

NormalModuleFactory 通过调用create()方法开始。然后，解析过程开始。在这里，请求（文件的路径）被解析，以及该类型文件的加载器。

注意，只有加载器的文件路径将被确定，加载器在这一步还没有被调用。

module 的构建过程

在所有必要的文件路径被解决后，NormalModule被创建。然而，在这步，模块的价值不大。很多相关的信息将在模块建立后出现。NormalModule 的构建过程还包括一些其他步骤。

• 首先，loader将在原始源代码上被调用；如果有多个加载器，那么一个加载器的输出可能是另一个加载器的输入（配置文件中提供加载器的顺序很重要）。
• 其次，通过所有加载器运行后得到的字符串将被acorn（JavaScript 解析器）解析，得到给定文件的AST。
• 最后，AST 将被分析；
  • 在这个阶段，当前模块的依赖关系（如其他模块）将被确定，webpack 可以检测其它的功能（如require.context，module.hot）等；
  • AST 分析发生在 JavascriptParser 中, 这个过程的一部分是最重要的，因为打包过程中接下来的很多事情都取决于这个部分。

通过分析AST发现依赖关系

现在AST已经被检查过了，到建立模块树的过程了。下一步是处理在上一步发现的依赖关系。按照上图，index模块有两个依赖关系，也是模块，即math.js和utils.js。但在这些依赖关系成为实际的模块之前，我们只有index模块，为了把它们变成模块，我们需要使用这些依赖关系映射到的ModuleFactory，并重复上面描述的步骤（本节开头的图中的虚线箭头表示重复）。在处理完当前模块的依赖关系后，这些依赖关系也可能有依赖关系，这个过程一直持续到没有更多的依赖关系。这就是模块树的建立过程，当然也要确保父模块和子模块之间的连接被正确设置。

让我们实现一个自定义插件的方法，它将使我们能够遍历 ModuleGraph。下面是描述模块如何相互依赖的图。

入口选项只包括一个值，即a.js。

// webpack.config.js
const config = {
  entry: path.resolve(__dirname, './src/a.js'),
    /* ... */
};

现在让我们看看我们的自定义插件会是什么样子

class UnderstandingModuleGraphPlugin {
  apply(compiler) {
    const className = this.constructor.name;
    
    compiler.hooks.compilation.tap(className, (compilation) => {
      
      compilation.hooks.finishModules.tap(className, (modules) => {
        // 检索 Map
        const {
          moduleGraph: { _moduleMap: moduleMap },
        } = compilation;

        // 以DFS的方式遍历模块图
        const dfs = () => {
          // "模块图 "的根模块是*空模块*。
          const root = null;

          const visited = new Map();

          const traverse = (crtNode) => {
            if (visited.get(crtNode)) {
              return;
            }
            visited.set(crtNode, true);

            console.log(
              crtNode?.resource ? path.basename(crtNode?.resource) : 'ROOT'
            );

            // 获得相关的`ModuleGraphModule`，它只有一些
            //除了`NormalModule'之外的额外属性，我们可以用它来进一步遍历图形。
            const correspondingGraphModule = moduleMap.get(crtNode);

            // 通过指定字段构建`children`信息
            const children = new Set(
              Array.from(
                correspondingGraphModule.outgoingConnections || [],
                (c) => c.module
              )
            );
            for (const c of children) {
              traverse(c);
            }
          };

          // 从root节点开始遍历
          traverse(root);
        };

        dfs();
      });
    });
  }
}

对代码最一个简单的解释

• 在现有的webpack hooks中添加逻辑的方式是使用tap方法

  • 函数签名为tap(string, callback)
  • 其中string主要是为了调试的目的，表示自定义逻辑是由哪个来源添加的。
  • callback的参数取决于我们要添加自定义功能的hook

• 在compilation对象上：它包含大部分打包过程状态

  • 模块图(module graph)
  • 创建的chunks
  • 创建的modules
  • 生成的assets
  • 以及更多的信息

• finishModules是在所有模块（包括它们的依赖关系和依赖关系的依赖关系等等)构建完毕后才被被调用

• modules是一个包含所有已建模块的集合

  • 一个NormalModule是由NormalModuleFactory产生的

• 模块map（Map<Module, ModuleGraphModule>）

  • 它包含了我们需要的所有信息，以便遍历图

• 以 DFS的方式遍历模块图

• ModuleGraphModule，它只有一些除了`NormalModule'之外的额外属性

• Connection的字段信息

  • Connection的originModule是箭头开始的地方。
  • Connection的module是箭头的终点。
  • 所以，Connection的module是一个子节点。

• correspondingGraphModule.outgoingConnections是一个Set或者undefined（在节点没有子节点的情况下）。
  • 使用new Set是因为一个模块可以通过多个连接引用同一个模块。
  • 例如，一个import foo from 'file.js'将导致2个连接：
    • 一个是简单的导入
    • 一个用于`foo'默认指定器

根据模块的层次结构，得到如下的输出。

a.js
b.js
b1.js
c.js
c1.js
d.js
d1.js

5. Module/Chunk/ ChunkGroup /EntryPoint 是个啥

Module

前文其实已经解释过了，这里再做一次总结哇。

模块是一个文件的升级版。

一个模块，一旦创建和构建，除了源代码，还包含很多有意义的信息，如：

• 使用的加载器
• 它的依赖关系
• 它的出口（如果有的话）
• 它的哈希值

Chunk

一个Chunk封装了一个或多个模块

一般情况下，entry文件（一个entry文件=entry对象的一个项目）的数量与所产生的Chunk的数量成正比。

• 因为entry对象可能只有一个项目，而结果块的数量可能大于1。的确，对于每一个entry项目，在dist目录中都会有一个相应的chunk
  

但也可能是隐式创建其他的chunk，例如在使用import()函数时。但不管它是如何被创建的，每个chunk在dist目录下都会有一个对应的文件。

ChunkGroup

一个ChunkGroup包含一个或多个chunks

一个 ChunkGroup 可以是另一个 ChunkGroup 的父或子。

• 例如，当使用动态导入时，每使用一个import()函数，就会有一个ChunkGroup被创建，它的父级是一个现有的 ChunkGroup，即包括使用import()函数的文件（即模块）的那个。

EntryPoint

EntryPoint是ChunkGroup的一种类型，它是为entry对象中的每一个项目创建的。

构建 ChunkGraph

从整体的流程图上看，ModuleGraph 只是打包过程中的一个必要部分。为了使代码分割等功能成为可能，它必须被利用起来。

在打包过程的这一点上，对于entry对象中的每个项目，都会有一个 EntryPoint。 因为它是 ChunkGroup 的一种类型，它至少会包含一个chunk。所以，如果entry对象有3个项目，就会有3个 EntryPoint实例，每个实例都有一个chunk，也叫Entrypoint chunk，其名称是entry项目key的值。与entry文件相关联的模块被称为entry模块，它们每个都将属于它们的入口块。它们之所以重要是因为它们是 ChunkGraph 构建过程的起点。请注意，一个chunk可以有多个入口模块。

// webpack.config.js
entry: {
  foo: ['./a.js', './b.js'],
},

在上面的例子中，有一个名为foo（entry的key）的 chunk 将有2个入口模块：一个与a.js文件相关，另一个与b.js文件相关。当然，该chunk将属于根据entry项目创建的 EntryPoint实例。

在详细讨论之前，让我们先列出一个例子，在此基础上讨论构建过程。

entry: {
    foo: [path.join(__dirname, 'src', 'a.js'), path.join(__dirname, 'src', 'a1.js')],
    bar: path.join(__dirname, 'src', 'c.js'),
  },

这个例子将包括前面提到的东西：ChunkGroups 的父子关系、chunks 和 EntryPoints。

ChunkGraph 是以递归的方式建立的。它首先将所有的entry模块添加到一个队列中。然后，当一个entry模块被处理时，意味着其依赖关系（也是模块）将被检查，每个依赖关系也将被添加到队列中。这样一直重复下去，直到队列变空。这个过程的这一部分是模块被访问的地方。然而，这只是第一部分。

ChunkGroups 可以是其他 ChunkGroups 的父/子。这些联系在第二部分得到解决。例如，如前所述，一个动态导入（即import()函数）会产生一个新的子ChunkGroup。在webpack的说法中，import()表达式定义了一个异步的依赖关系块。

现在，让我们先看看从上述配置中创建的ChunkGraph的图表。

从上图中，可以看到有4个 chunk，所以会有4个输出文件。foo chunk将有4个模块，其中2个是entry模块。bar chunk将只有一个entry模块，另一个可以被认为是普通模块。每个import()表达式都会产生一个新的ChunkGroup（其父级是bar EntryPoint）。

产生的文件的内容是根据 ChunkGraph 来决定的，所以这就是为什么它对整个打包过程非常重要。

与 ModuleGraph 类似，属于 ChunkGraph 的节点被称为 ChunkGraphChunk，它只是一个装饰过的chunk，他们之间的关系如下：WeakMap<Chunk, ChunkGraphChunk>。

6. 提交chunk资源

所产生的文件并不是原始文件的副本，因为为了实现其功能，webpack 需要添加一些自定义代码，使一切都按预期工作。

这就引出了一个问题：webpack如何知道要生成什么代码？

这一切都从最基本的部分开始：<span style="font-weight:800;color:#FFA500;font-size:18px">{模块| module}</span>。一个模块可以导出成员，导入其他成员，使用import()导入，使用webpack特定的函数（例如require.resolve）等等。

根据模块的源代码，webpack可以决定生成哪些代码以实现所需的功能。并且在分析AST时发现对应模块的依赖关系。

例如，从./foo 导入 { aFunction } 将导致两个依赖关系（一个是导入语句本身，另一个是指定器，即 aFunction），从中将创建一个模块。

另一个例子是 import() 函数。这将导致一个异步的依赖关系块，其中一个依赖关系是 ImportDependency，它是动态导入所特有的。

这些依赖关系是必不可少的，因为它们带有一些关于应该生成什么代码的提示。例如，ImportDependency 确切地知道要告诉 webpack 一些信息，以便异步地获取导入的模块并使用其导出的成员。这些提示可以被称为运行时请求。

总而言之，一个模块会有它的运行时间要求，这取决于该模块在其源代码中使用的内容。现在，webpack知道了一个chunk的所有需求，它将能够正确地生成运行时代码。

这也被称为渲染过程，渲染过程在很大程度上依赖于 ChunkGraph，因为它包含Chunk组（即 ChunkGroup，EntryPoint），这些组包含Chunks，这些Chunks包含模块，这些模块以一种细化的方式包含有关webpack将生成的运行时代码的信息和提示。

后记

分享是一种态度。

参考资料：

• webpacks-bundling-process
• 效率工程化

全文完，既然看到这里了，如果觉得不错，随手点个赞和“在看”吧。

本文由mdnice多平台发布