乐趣区

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

全文 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-serverwebpack/hot/xxxquerystring 等框架,这一部分占了大部分代码
  • __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 曾经解析得出 ModuleDependencyGraphChunkGraph 关系,也就意味着此时曾经能够计算出:

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

对 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 子类对象,并将对象退出到 ModuleDepedencyGraphChunkGraph 体系中治理

至此,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+ 优良学习材料合集
退出移动版