Saturday, 13 Jun 2020 ｜ 14 min read

对 ES Modules 的一点理解

长久以来，在前端工程里我们不断的书写 ✍️ 类似的文件头部，引入我们需要的模块，无论是自己编写的组件还是引入公共库。

在之前很长一段时间，这类机制在我看来仿佛黑箱一样，对其背后发生感到了好奇

在逐渐理解模块化之后，如果你也对此有过我曾经同样的感受，我想接下来的内容能让你减少一些困惑

Motivation

我们可能已经习惯书写了各式各样的模块引入方式，但让我们先忘记这些

如果一切还原到最初的时期，仅仅是一些零碎的变量组成的文件

比如 a.js 和 b.js

那么现在我们需要一点更好玩的东西了，我们需要让两个文件同时使用公共的第三方变量

最好的例子就是 jQuery

可以看到 a.js 和 b.js 都使用了 jQuery 的变量

那如果我们将 jQuery 删掉，或者改变书写的顺序，比如 <script> 放在引入 a.js 或 b.js之后

使用 jQuery 的地方将抛出一个错误，并停止继续执行下去

我们这个简单的例子可能有点简陋，不足以说明在类似情景所遇到的困难。维护老代码成了关于作用域的运气游戏或者经历抽丝剥茧才能确定变量被哪些文件引用，才能安全的修改

模块化提供给我们更好的方式组织变量，拆分/组织不同含义的模块，并且可以明确何时何地引用了哪些变量，显式的关系更容易排查问题，以及可以让引擎去做一些语义分析

How ES modules work

ES Modules 是浏览器原生支持的模块系统

而在之前，常用的是 CommonJS 和基于 AMD 的其他模块系统如 RequireJS

以及 Webpack 自己实现的模块化系统，在后面我们会再次提及这个

ES Modules 的关键字是 import 和 export

ES Moudles 模块加载将包含三个主要的阶段，这里简单提要一下

Construction — 查找、下载并解析所有文件到模块记录中。
Instantiation — 在内存中寻找一块区域来存储所有导出的变量（但还没有填充值）。然后让 export 和 import 都指向这些内存块。这个过程叫做链接（linking）
Evaluation — 运行代码，在内存块中填入变量的实际值

这三个阶段可以分开完成，意味着异步的

最后的产物将被称作 Module Graph 模块图谱

我们用一个简单的例子来说明ES Moudles 加载模块其背后大致发生了什么

Construction

Find 查找

通常我们会有一个主文件 main.js 作为一切的开始

然后通过 import 语句去引入其他模块所导出的内容

import 语句中的一部分称为 Module Specifier。它告诉 Loader 在哪里可以找到引入的模块。

注意不同宿主环境下，不同的 Loader 实现可能不尽相同，这将导致在 Node 中习惯使用的方式换在浏览器上可能发生错误

比如在 CommonJS 中或者利用 Webpack 进行 bundled，我们通常习惯这样书写

import moment from 'moment';

通过仅仅指定包名称，背后就能通过查询算法找到包的主程序

这个方式的主要优点是可以轻松地在整个生态系统中进行协调。任何人都可以编写一个模块，并使用包的众所周知的包名称，然后让 Node.js 运行时或其构建时工具负责将其转换为磁盘上的实际文件

而在浏览器端，目前无法直接这样使用包名称

但在未来或许可以

详细请参阅 import-maps

在此之前，在浏览器只能使用 URL 作为 Module Specifier ，也就是使用 URL 去加载模块

Download 下载

而有个问题也随之而来，浏览器在解析文件前并不知道文件依赖哪些模块，当然获取文件之前更无法解析文件，这将导致整个解析依赖关系的流程是阻塞的，

如果浏览器按这样进行解析，那么模块系统会慢到无法使用

而 CommonJS 是在 Node 环境下诞生的，从文件系统加载文件比在 Internet 上下载的时间要少得多，这意味着 Node 可以在加载文件时阻塞主线程。而且既然文件已经加载了，直接实例化和求值（在 CommonJS 中并不区分这两个阶段）

所以 ES Modules 规范将 Construction 这个步骤单独分离出来，使浏览器在执行同步的初始化过程前可以自行获取并下载文件以及解析

补充：ES Modules 规范没有规定浏览器如何获取（查找/下载）文件，只定义了该如何解析文件（解析文件到 Module Record）

这也暗示了 ES Modules 可以被称为异步的原因之一

Parse 解析

刚才已经提及了很多关于解析的内容，实际上解析文件是助于浏览器了解模块内的构成，而我们把它解析出来的模块构成表称为 Module Record 模块记录

模块记录包含了当前模块的 AST，引用了哪些模块的变量，以前一些特定属性和方法

模块记录被创建后将被记录在称作 Module Map 的表中

被记录后，如果再有对相同 URL 的请求，Loader 将直接采用 Module Map 中 URL 对应的 Module Record

当解析完全部文件后，我们将得到很多 Module Record

另外提及一下不同方式的 Parse 被称为 Parse Goal ,使用不同方式 Parse Goal 解析相同的 file ，得到的产物也是不一样的，所以我们会在 script 标签添加 type = "module" 来告诉浏览器这个文件将是一个模块
但在 Node 中，是没有 HTML 标签的，所以需要其他的方式来辨别，社区目前的主流解决方式是修改文件的后缀为 .mjs ，来告诉 Node 这将是一个模块。不过还没有标准化，而且还存在很多兼容问题

在Construction过程不会实例化和执行任何的代码，在进行任何求值之前，需要事先构建整个模块图，这也是被称为 静态解析 的原因。

正因为此，Module Specifier 也无法使用变量，因为在解析时并没有执行任何代码，也就没有任何状态

而 CommonJS 的话，在查找下一个模块之前，执行了此模块中的所有代码（直至 require 语句）。这意味着当进行模块解析时，变量会有值。

ES Moudle 为了支持在模块路径中使用变量，有一个提案实现它：动态导入

原理是任何通过 import() 加载的模块，将称为独立的依赖图入口，也就是说脱离之前的依赖图独自处理（就像 main.js）

好了，从普通的主入口文件，到现在我们有了很多 Module Record，接下里可以进行实例化

Instantiation

为了实例化 Module Record ，引擎将采用 Depth First Post-order Traversal 深度优先后序进行遍历，JS 引擎将会为每一个 Module Record 创建一个 Module Environment Record 模块环境记录，它将管理 Module Record 对应的变量，并为所有 export 分配内存空间（这个阶段中并未求值）