乐趣区

关于前端:Webpack-系列第五篇-彻底理解-Webpack-运行时

jiezi

全文 5000 字，深度分析 Webpack 运行时的内容、构造与生成原理，欢送点赞关注。写作不易，未经作者批准，禁止任何模式转载！！！

背景

在上一篇文章 有点难的 webpack 知识点：Chunk 分包规定详解 中，咱们具体解说了 Webpack 默认的分包规定，以及一部分 seal 阶段的执行逻辑，当初咱们将按 Webpack 的执行流程，持续往下深度剖析实现原理，具体内容包含：

  • Webpack 的构建产物蕴含那些内容？产物如何反对诸如模块化、异步加载、HMR 个性？
  • 何谓运行时？Webpack 构建过程中如何收集运行时依赖？如何将运行时与业务代码合并输入到 bundle？

实际上，本文及后面几篇原理性质的文章，可能并不能马上解决你在业务中可能正在面临的事实问题，但放到更长的工夫维度，这些文章所出现的常识、思维、思辨过程可能可能久远地给到你：

  • 剖析、了解简单开源代码的能力
  • 了解 Webpack 架构及实现细节，下次遇到问题的时候能依据表象迅速定位到本源
  • 了解 Webpack 为 hooks、loader 提供的上下文，可能更通顺地了解其它开源组件，甚至可能自若地实现本人的组件

所以，心愿感兴趣的同学可能保持，我后续还会输入很多对于 Webpack 实现原理的文章！如果你恰好也想晋升本人在 Webpack 方面的常识储备，关注我，咱们一起学习！

关注公众号【Tecvan】，回复【1】，获取 Webpack 常识体系脑图

编译产物剖析

为了失常、正确运行业务我的项目，Webpack 须要将开发者编写的业务代码以及撑持、调配这些业务代码的 运行时 一并打包到产物 (bundle) 中，以修建作类比的话，业务代码相当于砖瓦水泥，是看得见摸得着能间接感知的逻辑；运行时相当于埋葬在砖瓦之下的钢筋地基，通常不会关注但决定了整座修建的性能、品质。

大多数 Webpack 个性都须要特定钢筋地基能力跑起来，比如说：

  • 异步按需加载
  • HMR
  • WASM
  • Module Federation

上面先从最简略的示例开始，逐渐开展理解各个个性下的 Webpack 运行时代码。

根本构造

先从一个最简略的示例开始，对于上面的代码构造：

// a.js
export default 'a module';

// index.js
import name from './a'
console.log(name)

应用如下配置：

module.exports = {
  entry: "./src/index",
  mode: "development",
  devtool: false,
  output: {filename: "[name].js",
    path: path.join(__dirname, "./dist"),
  },
};

配置的内容比较简单，就不开展讲了，间接看编译生成的后果：

尽管看起来很非主流，但仔细剖析还是能拆解出代码脉络的，bundle 整体由一个 IIFE 包裹，外面的内容从上到下顺次为：

  • __webpack_modules__ 对象，蕴含了除入口外的所有模块，示例中即 a.js 模块
  • __webpack_module_cache__ 对象，用于存储被援用过的模块
  • __webpack_require__ 函数，实现模块援用(require) 逻辑
  • __webpack_require__.d，工具函数，实现将模块导出的内容附加的模块对象上
  • __webpack_require__.o，工具函数，判断对象属性用
  • __webpack_require__.r，工具函数，在 ESM 模式下申明 ESM 模块标识
  • 最初的 IIFE，对应 entry 模块即上述示例的 index.js，用于启动整个利用

这几个 __webpack_ 结尾奇奇怪怪的函数能够统称为 Webpack 运行时代码，作用如后面所说的是搭起整个业务我的项目的骨架，就上述简略示例所列举进去的几个函数、对象而言，它们合作构建起一个简略的模块化体系从而实现 ES Module 标准所申明的模块化个性。

上述示例中最终的函数是 __webpack_require__，它实现了模块间援用性能，外围代码：

function __webpack_require__(moduleId) {
    /******/ // 如果模块被援用过
    /******/ var cachedModule = __webpack_module_cache__[moduleId];
    /******/ if (cachedModule !== undefined) {
      /******/ return cachedModule.exports;
      /******/
    }
    /******/ // Create a new module (and put it into the cache)
    /******/ var module = (__webpack_module_cache__[moduleId] = {
      /******/ // no module.id needed
      /******/ // no module.loaded needed
      /******/ exports: {},
      /******/
    });
    /******/
    /******/ // Execute the module function
    /******/ __webpack_modules__[moduleId](
      module,
      module.exports,
      __webpack_require__
    );
    /******/
    /******/ // Return the exports of the module
    /******/ return module.exports;
    /******/
  }

从代码能够揣测出，它的性能：

  • 依据 moduleId 参数找到对应的模块代码，执行并返回后果
  • 如果 moduleId 对应的模块被援用过，则间接返回存储在 __webpack_module_cache__ 缓存对象中的导出内容，防止反复执行

其中，业务模块代码被存储在 bundle 最开始的 __webpack_modules__ 变量中，内容如：

var __webpack_modules__ = {
    "./src/a.js": (
        __unused_webpack_module,
        __webpack_exports__,
        __webpack_require__
      ) => {// ...​},
  };

联合 __webpack_require__ 函数与 __webpack_modules__ 变量就能够正确地援用到代码模块，例如上例生成代码最初面的 IIFE：

(() => {
    /*!**********************!*\
  !*** ./src/index.js ***!
  \**********************/
    /* harmony import */ var _a__WEBPACK_IMPORTED_MODULE_0__ =
      __webpack_require__(/*! ./a */ "./src/a.js");

    console.log(_a__WEBPACK_IMPORTED_MODULE_0__.name);
  })();

这几个函数、对象形成了 Webpack 运行时最根本的能力 —— 模块化，它们的生成规定与原理咱们放到文章第二节《实现原理》再讲，上面咱们持续看看异步模块加载、模块热更新场景下对应的运行时内容。

异步模块加载

咱们来看个简略的异步模块加载示例：

// ./src/a.js
export default "module-a"

// ./src/index.js
import('./a').then(console.log)

Webpack 配置跟上例类似：

module.exports = {
  entry: "./src/index",
  mode: "development",
  devtool: false,
  output: {filename: "[name].js",
    path: path.join(__dirname, "./dist"),
  },
};

生成的代码太长，就不贴了，相比于最开始的根本构造示例所示的模块化性能，应用异步模块加载个性时，会额定减少如下运行时：

  • __webpack_require__.e：逻辑上包裹了一层中间件模式与 promise.all，用于异步加载多个模块
  • __webpack_require__.f：供 __webpack_require__.e 应用的中间件对象，例如应用 Module Federation 个性时就须要在这里注册中间件以批改 e 函数的执行逻辑
  • __webpack_require__.u：用于拼接异步模块名称的函数
  • __webpack_require__.l：基于 JSONP 实现的异步模块加载函数
  • __webpack_require__.p：以后文件的残缺 URL，可用于计算异步模块的理论 URL

倡议读者运行示例比照理论生成代码，感触它们的具体性能。这几个运行时模块构建起 Webpack 异步加载能力，其中最外围的是 __webpack_require__.e 函数，它的代码很简略：

__webpack_require__.f = {};
/******/    // This file contains only the entry chunk.
/******/    // The chunk loading function for additional chunks
/******/    __webpack_require__.e = (chunkId) => {/******/      return Promise.all(Object.keys(__webpack_require__.f).reduce((promises, key) => {/******/        __webpack_require__.f[key](chunkId, promises);
/******/        return promises;
/******/      }, []));
/******/    };

从代码看，只是实现了一套基于 __webpack_require__.f 的中间件模式，以及用 Promise.all 实现并行处理，理论加载工作由 __webpack_require__.f.j 与 __webpack_require__.l 实现，离开来看两个函数：

/******/  __webpack_require__.f.j = (chunkId, promises) => {
/******/        // JSONP chunk loading for javascript
/******/        var installedChunkData = __webpack_require__.o(installedChunks, chunkId) ? installedChunks[chunkId] : undefined;
/******/        if(installedChunkData !== 0) { // 0 means "already installed".
/******/    
/******/          // a Promise means "currently loading".
/******/          if(installedChunkData) {/******/            promises.push(installedChunkData[2]);
/******/          } else {/******/            if(true) { // all chunks have JS
/******/              // ...
/******/              // start chunk loading
/******/              var url = __webpack_require__.p + __webpack_require__.u(chunkId);
/******/              // create error before stack unwound to get useful stacktrace later
/******/              var error = new Error();
/******/              var loadingEnded = ...;
/******/              __webpack_require__.l(url, loadingEnded, "chunk-" + chunkId, chunkId);
/******/            } else installedChunks[chunkId] = 0;
/******/          }
/******/        }
/******/    };

__webpack_require__.f.j 实现了异步 chunk 门路的拼接、缓存、异样解决三个方面的逻辑，而 __webpack_require__.l 函数：

/******/    var inProgress = {};
/******/    // data-webpack is not used as build has no uniqueName
/******/    // loadScript function to load a script via script tag
/******/    __webpack_require__.l = (url, done, key, chunkId) => {/******/      if(inProgress[url]) {inProgress[url].push(done); return; }
/******/      var script, needAttach;
/******/      if(key !== undefined) {/******/        var scripts = document.getElementsByTagName("script");
/******/        /​/ ...
/******/      }
/******/      //​ ...
/******/      inProgress[url] = [done];
/******/      var onScriptComplete = (prev, event) => {
/******/        //​ ...
/******/      }
/******/      ;
/******/      var timeout = setTimeout(onScriptComplete.bind(null, undefined, { type: 'timeout', target: script}), 120000);
/******/      script.onerror = onScriptComplete.bind(null, script.onerror);
/******/      script.onload = onScriptComplete.bind(null, script.onload);
/******/      needAttach && document.head.appendChild(script);
/******/    };

__webpack_require__.l 中通过 script 实现异步 chunk 内容的加载与执行。

e + l + f.j 三个运行时函数撑持起 Webpack 异步模块运行的能力，落到理论用法上只须要调用 e 函数即可实现异步模块加载、运行，例如上例对应生成的 entry 内容：

/*!**********************!*\
  !*** ./src/index.js ***!
  \**********************/
__webpack_require__.e(/*! import() */ "src_a_js").then(__webpack_require__.bind(__webpack_require__, /*! ./a */ "./src/a.js"))

模块热更新

模块热更新 —— HMR 是一个能显著进步开发效率的能力，它可能在模块代码呈现变动的时候，独自编译该模块并将最新的编译后果传送到浏览器，浏览器再用新的模块代码替换掉旧的代码，从而实现模块级别的代码热替换能力。落到最终体验上，开发者启动 Webpack 后，编写、批改代码的过程中不须要手动刷新浏览器页面，所有变更可能实时同步出现到页面中。

实现上，HMR 的实现链路很长也比拟有意思，咱们后续会单开一篇文章探讨，本文次要关注 HMR 个性所带入运行时代码。启动 HMR 能力须要用到一些非凡的配置项：

module.exports = {
  entry: "./src/index",
  mode: "development",
  devtool: false,
  output: {filename: "[name].js",
    path: path.join(__dirname, "./dist"),
  },
  // 简略起见，这里应用 HtmlWebpackPlugin 插件主动生成作为 host 的 html 文件
  plugins: [
    new HtmlWebpackPlugin({title: "Hot Module Replacement",}),
  ],
  // 配置 devServer 属性，启动 HMR
  devServer: {
    contentBase: "./dist",
    hot: true,
    writeToDisk: true,
  },

依照上述配置，应用命令 webpack serve --hot-only 启动 Webpack，就能够在 dist 文件夹找到产物：

相比于后面两个示例，HMR 所产生运行时代码达到 1.5w+ 行，几乎能够用炸裂来形容。次要的运行时内容有：

  • 反对 HMR 所须要用到的 webpack-dev-server、webpack/hot/xxx、querystring 等框架，这一部分占了大部分代码
  • __webpack_require__.l：与异步模块加载一样，基于 JSONP 实现的异步模块加载函数
  • __webpack_require__.e：与异步模块加载一样
  • __webpack_require__.f：与异步模块加载一样
  • __webpack_require__.hmrF：用于拼接热更新模块 url 的函数
  • webpack/runtime/hot：这不是单个对象或函数，而是蕴含了一堆实现模块替换的办法

能够看到，HMR 运行时是下面异步模块加载运行时的超集，而异步模块加载的运行时又是第一个根本示例运行时的超集，层层叠加。在 HMR 中蕴含了：

  • 模块化能力
  • 异步模块加载能力 —— 实现变更模块的异步加载
  • 热替换能力 —— 用拉取到的新模块替换掉旧的模块，并触发热更新事件

内容过多，咱们放到下次专门开一篇文章聊聊 HMR。

实现原理

仔细阅读上述三个示例，置信读者应该曾经隐隐约约捕捉到一些重要规定：

  • 除了业务代码外，bundle 中还必须蕴含 运行时 代码能力失常运行
  • 运行时的具体内容由业务代码，确切地说由业务代码所应用到的个性决定，例如应用到异步加载时须要打包 __webpack_require__.e 函数，那么这外面必然有一个运行时依赖收集的过程
  • 开发者编写的业务代码会被包裹进失当的运行时函数中，实现整体协调

落到 Webpack 源码实现上，运行时的生成逻辑能够划分为两个步骤：

  1. 依赖收集：遍历业务代码模块收集模块的个性依赖，从而确定整个我的项目对 Webpack runtime 的依赖列表
  2. 生成：合并 runtime 的依赖列表，打包到最终输入的 bundle

两个步骤都产生在打包阶段，即 Webpack(v5) 源码的 compilation.seal 函数中：

上图是我总结的 Webpack 常识图谱的一部分，可关注公众号【Tecvan】回复【1】获取线上地址

留神上图，进入 runtime 解决环节时 Webpack 曾经解析得出 ModuleDependencyGraph 及 ChunkGraph 关系，也就意味着此时曾经能够计算出：

  • 须要输入那些 chunk
  • 每个 chunk 蕴含那些 module，以及每个 module 的内容
  • chunk 与 chunk 之间的父子依赖关系

对 bundle、module、chunk 关系这几个概念还不太清晰的同学，倡议扩大浏览：

  • [万字总结] 一文吃透 Webpack 外围原理
  • 有点难的 webpack 知识点：Dependency Graph 深度解析
  • 有点难的 webpack 知识点：Chunk 分包规定详解

基于这些信息，接下来首先须要收集运行时依赖。

依赖收集

Webpack runtime 的依赖概念上很像 Vue 的依赖，都是用来表白模块对其它模块存在附丽关系，只是实现办法上 Vue 基于动静、在运行过程中收集，而 Webpack 则基于动态代码剖析的形式收集依赖。实现逻辑大抵为：

运行时依赖的计算逻辑集中在 compilation.processRuntimeRequirements 函数，代码上蕴含三次循环：

  • 第一次循环遍历所有 module，收集所有 module 的 runtime 依赖
  • 第二次循环遍历所有 chunk，将 chunk 下所有 module 的 runtime 对立收录到 chunk 中
  • 第三次循环遍历所有 runtime chunk，收集其对应的子 chunk 下所有 runtime 依赖，之后遍历所有依赖并公布 runtimeRequirementInTree 钩子，(次要是) RuntimePlugin 插件订阅该钩子并依据依赖类型创立对应的 RuntimeModule 子类实例

上面咱们开展聊聊细节。

第一次循环：收集模块依赖

在打包 (seal) 阶段，实现 ChunkGraph 的构建之后，Webpack 会紧接着调用 codeGeneration 函数遍历 module 数组，调用它们的 module.codeGeneration 函数执行模块转译，模块转译后果如：

其中，sources 属性为模块通过转译后的后果；而 runtimeRequirements 则是基于 AST 计算出来的，为运行该模块时所须要用到的运行时，计算过程与本文主题无关，挖个坑下一回咱们再持续讲。

所有模块转译结束后，开始调用 compilation.processRuntimeRequirements 进入第一重循环，将上述转译后果的 runtimeRequirements 记录到 ChunkGraph 对象中。

第二次循环：整合 chunk 依赖

第一次循环针对 module 收集依赖，第二次循环则遍历 chunk 数组，收集将其对应所有 module 的 runtime 依赖，例如：

示例图中，module a 蕴含两个运行时依赖；module b 蕴含一个运行时依赖，则通过第二次循环整合后，对应的 chunk 会蕴含两个模块对应的三个运行时依赖。

第三次循环：依赖标识转 RuntimeModule 对象

源码中，第三次循环的代码起码但逻辑最简单，大抵上执行三个操作：

  • 遍历所有 runtime chunk，收集其所有子 chunk 的 runtime 依赖
  • 为该 runtime chunk 下的所有依赖公布 runtimeRequirementInTree 钩子
  • RuntimePlugin 监听钩子，并依据 runtime 依赖的标识信息创立对应的 RuntimeModule 子类对象，并将对象退出到 ModuleDepedencyGraph 和 ChunkGraph 体系中治理

至此，runtime 依赖实现了从 module 内容解析，到收集，到创立依赖对应的 Module 子类，再将 Module 退出到 ModuleDepedencyGraph /ChunkGraph 体系的全流程，业务代码及运行时代码对应的模块依赖关系图齐全 ready，能够筹备进入下一阶段 —— 生成最终产物。

但在持续解说产物逻辑之前，咱们有必要先解决两个问题：

  • 何谓 runtime chunk？与一般 chunk 是什么关系
  • 何谓 RuntimeModule？与一般 Module 有什么区别

总结：Chunk 与 Runtime Chunk

在上一篇文章 有点难的 webpack 知识点：Chunk 分包规定详解 我尝试残缺地解说 Webpack 默认分包规定，回顾一下在三种特定的状况下，Webpack 会创立新的 chunk：

  • 每个 entry 项都会对应生成一个 chunk 对象，称之为 initial chunk
  • 每个异步模块都会对应生成一个 chunk 对象，称之为 async chunk
  • Webpack 5 之后，如果 entry 配置中蕴含 runtime 值，则在 entry 之外再减少一个专门包容 runtime 的 chunk 对象，此时能够称之为 runtime chunk

默认状况下 initial chunk 通常蕴含运行该 entry 所须要的所有 runtime 代码，但 webpack 5 之后呈现的第三条规定突破了这一限度，容许开发者将 runtime 从 initial chunk 中剥离进去独立为一个多 entry 间可共享的 runtime chunk。

相似的，异步模块对应 runtime 代码大部分都被蕴含在对应的援用者身上，比如说：

// a.js
export default 'a-module'

// index.js
// 异步引入 a 模块
import('./a').then(console.log)

在这个示例中，index 异步引入 a 模块，那么按默认调配规定会产生两个 chunk：入口文件 index 对应的 initial chunk、异步模块 a 对应的 async chunk。此时从 ChunkGraph 的角度看 chunk[index] 为 chunk[a] 的父级，运行时代码会被打入 chunk[index]，站在浏览器的角度，运行 chunk[a] 之前必须先运行 chunk[index]，两者造成显著的父子关系。

总结：RuntimeModule 体系

在最开始浏览 Webpack 源码的时候，我就感觉很奇怪，Module 是 Webpack 资源管理的根本单位，但 Module 底下总共衍生出了 54 个子类，且大部分为 Module => RuntimeModule => xxxRuntimeModule 的继承关系：

在 有点难的 webpack 知识点：Dependency Graph 深度解析 一文中咱们聊到模块依赖关系图的生成过程及作用，但篇文章的内容是围绕业务代码开展的，用到的大多是 NormalModule。到 seal 函数收集运行时的过程中，RuntimePlugin 还会为运行时依赖一一创立对应的 RuntimeModule 子类，例如：

  • 模块化实现中依赖 __webpack_require__.r，则对应创立 MakeNamespaceObjectRuntimeModule 对象
  • ESM 依赖 __webpack_require__.o，则对应创立 HasOwnPropertyRuntimeModule 对象
  • 异步模块加载依赖 __webpack_require__.e，则对应创立 EnsureChunkRuntimeModule 对象
  • 等等

所以能够推导出所有 RuntimeModule 结尾的类型与特定的运行时性能一一对应，收集依赖的后果就是在业务代码之外创立出一堆撑持性质的 RuntimeModule 子类，这些子类对象随后被退出 ModuleDependencyGraph，并入整个模块依赖体系中。

资源合并生成

通过下面的运行时依赖收集过程后，bundle 所须要的所有内容都就绪了，接着就能够筹备写出到文件中，即下图外围流程中的生成 (emit) 阶段：

我的另一篇 [万字总结] 一文吃透 Webpack 外围原理 对这一块有比拟粗疏的解说，这里从运行时的视角再简略聊一下代码流程：

  • 调用 compilation.createChunkAssets，遍历 chunks 将 chunk 对应的所有 module，包含业务模块、运行时模块全副合并成一个资源 (Source 子类) 对象
  • 调用 compilation.emitAsset 将资源对象挂载到 compilation.assets 属性中
  • 调用 compiler.emitAssets 将 assets 全副写到 FileSystem
  • 公布 compiler.hooks.done 钩子
  • 运行完结

挖坑

Webpack 真的很简单，每次信念满满写出一个主题的内容之后都会发现更多新的坑点，比方本文能够衍生进去的关注点：

  • 除了 NormalModule 与 RuntimeModule 体系外，其余的 Module 子类别离起什么作用？
  • 单个 Module 的内容转译过程是怎么样的？在这个过程中具体是怎么计算出 runtime 依赖的？
  • 除了记录 module、chunk 的 runtimeRequirements 之外，ChunkGraph 还起什么作用？

缓缓挖坑，缓缓填坑吧。如果感觉文章有用，请务必点赞关注转发来一波。

往期文章

  • [万字总结] 一文吃透 Webpack 外围原理
  • [源码解读] Webpack 插件架构深度解说
  • 十分钟精进 Webpack：module.issuer 属性详解
  • 有点难的 webpack 知识点：Dependency Graph 深度解析
  • 有点难的知识点：Webpack Chunk 分包规定详解
  • 分享几个 Webpack 实用剖析工具
  • [倡议珍藏] Webpack 4+ 优良学习材料合集
退出移动版