关于前端:聊聊-ESMBundle-Bundleless-Vite-Snowpack

前言

所有要都要从打包构建说起。

当下咱们很多我的项目都是基于 webpack 构建的，次要用于：

• 本地开发
• 打包上线

首先，webpack 是一个平凡的工具。

通过一直的欠缺，webpack 以及周边的各种轮子曾经能很好的满足咱们的日常开发需要。

咱们都晓得，webpack 具备将各类资源打包整合在一起，造成 bundle 的能力。

可是，当资源越来越多时，打包的工夫也将越来越长。

一个中大型的我的项目，启动构建的工夫能达到数分钟之久。

拿我的我的项目为例，首次构建大略须要三分钟，而且这个工夫会随着零碎的迭代越来越长。置信不少同学也都遇到过这样的问题，这是一个让人很好受的事件。

那有没有什么方法来解决呢？

当然是有的。

这就是明天的配角 ESM，以及以它为根底的各类构建工具，比方 Snowpack, Vite, Parcel 等等。

明天，咱们就这个话题展开讨论，心愿能给大家一些其发和帮忙。

注释

什么是 ESM

ESM 是实践根底，咱们都须要理解。

「ESM」全称 ECMAScript modules，根本支流的浏览器版本都以曾经反对。

ESM 是如何工作的

当应用 ESM 模式时，浏览器会构建一个依赖关系图。不同依赖项之间的连贯来自你应用的导入语句。

通过这些导入语句，浏览器 或 Node 就能确定加载代码的形式。

通过指定一个入口文件，而后从这个文件开始，通过其中的 import 语句，查找其余代码。

通过指定的文件门路，浏览器就找到了指标代码文件。然而浏览器并不能间接应用这些文件，它须要解析所有这些文件，以将它们转换为称为模块记录的数据结构。

而后，须要将 模块记录 转换为 模块实例。

模块实例 ，实际上是「 代码 」（指令列表）与「 状态」（所有变量的值）的组合。

对于整个零碎而言，咱们须要的是每个模块的模块实例。

模块加载的过程将从入口文件变为具备残缺的模块实例图。

对于 ES 模块，这分为 三个步骤：

1. 结构—查找，下载所有文件并将其解析为模块记录。
2. 实例化—查找内存中的框以搁置所有导出的值（但尚未用值填充它们）。而后使导出和导入都指向内存中的那些框，这称为链接。
3. 运行—运行代码以将变量的理论值填充到框中。

在构建阶段时，产生三件事件：

1. 找出从何处下载蕴含模块的文件
2. 提取文件（通过从 URL 下载文件或从文件系统加载文件）
3. 将文件解析为模块记录

1. 查找

首先，须要找到入口点文件。

在 HTML 中，能够通过脚本标记通知加载程序在哪里找到它。

然而，如何找到下一组模块，也就是 main.js 间接依赖的模块呢？

这就是导入语句的起源。

导入语句的一部分称为模块说明符，它通知加载程序能够在哪里找到每个下一个模块。

在解析文件之前，咱们不晓得模块须要获取哪些依赖项，并且在提取文件之前，也无奈解析文件。

这意味着咱们必须逐层遍历树，解析一个文件，而后找出其依赖项，而后查找并加载这些依赖项。

如果主线程要期待这些文件中的每个文件下载，则许多其余工作将沉积在其队列中。

那是因为当浏览器中工作时，下载局部会破费很长时间。

这样阻塞主线程会使应用模块的应用程序应用起来太慢。

这是 ES 模块标准将算法分为多个阶段的起因之一。

将结构分为本人的阶段，使浏览器能够在开始实例化的同步工作之前获取文件并建设对模块图的了解。

这种办法（算法分为多个阶段）是 ESM 和 CommonJS 模块 之间的次要区别之一。

CommonJS 能够做不同的事件，因为从文件系统加载文件比通过 Internet 下载破费的工夫少得多。

这意味着 Node 能够在加载文件时阻止主线程。

并且因为文件曾经加载，因而仅实例化和求值（在 CommonJS 中不是独自的阶段）是有意义的。

这也意味着在返回模块实例之前，须要遍历整棵树，加载，实例化和评估任何依赖项。

在具备 CommonJS 模块的 Node 中，能够在模块说明符中应用变量。

require在寻找下一个模块之前，正在执行该模块中的所有代码。这意味着当进行模块解析时，变量将具备一个值。

然而，应用 ES 模块时，须要在进行任何评估之前事后建设整个模块图。

这意味着不能在模块说明符中蕴含变量，因为这些变量还没有值。

然而，有时将变量用于模块门路的确很有用。

例如，你可能要依据代码在做什么，或者在不同环境中运行来记录不同的模块。

为了使 ES 模块成为可能，有一个倡议叫做动静导入。有了它，您能够应用相似的导入语句：

import(`${path}/foo.js`)。

这种工作形式是将应用加载的任何文件 import() 作为独自图的入口点进行解决。

动静导入的模块将启动一个新图，该图将被独自解决。

然而要留神一件事–这两个图中的任何模块都将共享一个模块实例。

这是因为加载程序会缓存模块实例。对于特定全局范畴内的每个模块，将只有一个模块实例。

这意味着发动机的工作量更少。

例如，这意味着即便多个模块依赖该模块文件，它也只会被提取一次。（这是缓存模块的一个起因。咱们将在评估局部中看到另一个起因。）

加载程序应用称为模块映射的内容来治理此缓存。每个全局变量在独自的模块图中跟踪其模块。

当加载程序获取一个 URL 时，它将把该 URL 放入模块映射中，并记下它以后正在获取文件。而后它将发出请求并持续以开始获取下一个文件。

如果另一个模块依赖于同一文件会怎么？加载程序将在模块映射中查找每个 URL。如果在其中看到fetching，它将继续前进到下一个 URL。

然而模块图不仅跟踪正在获取的文件。模块映射还充当模块的缓存，如下所示。

2. 解析

当初咱们曾经获取了该文件，咱们须要将其解析为模块记录。这有助于浏览器理解模块的不同局部。

创立模块记录后，它将被搁置在模块图中。这意味着无论何时从此处申请，加载程序都能够将其从该映射中拉出。

解析中有一个细节看似微不足道，但实际上有很大的含意。

解析所有模块，就像它们 "use strict" 位于顶部一样。还存在其余轻微差别。

例如，关键字 await 是在模块的顶级代码保留，的值 this 就是undefined。

这种不同的解析形式称为“解析指标”。如果解析雷同的文件但应用不同的指标，那么最终将失去不同的后果。
因而，须要在开始解析之前就晓得要解析的文件类型是否是模块。

在浏览器中，这非常简单。只需放入 type="module" 的 script 标签。
这通知浏览器应将此文件解析为模块。并且因为只能导入模块，因而浏览器晓得任何导入也是模块。

然而在 Node 中，您不应用 HTML 标记，因而无奈抉择应用 type 属性。社区尝试解决此问题的一种办法是应用 .mjs扩大。应用该扩展名通知 Node，“此文件是一个模块”。您会看到人们在议论这是解析指标的信号。目前探讨仍在进行中，因而尚不分明 Node 社区最终决定应用什么信号。

无论哪种形式，加载程序都将确定是否将文件解析为模块。如果它是一个模块并且有导入，则它将从新开始该过程，直到提取并解析了所有文件。

咱们实现了！在加载过程完结时，您曾经从只有入口点文件变为领有大量模块记录。

下一步是实例化此模块并将所有实例链接在一起。

3. 实例化

就像我之前提到的，实例将代码与状态联合在一起。

该状态存在于内存中，因而实例化步骤就是将所有事物连贯到内存。

首先，JS 引擎创立一个模块环境记录。这将治理模块记录的变量。而后，它将在内存中找到所有导出的框。模块环境记录将跟踪与每个导出关联的内存中的哪个框。

内存中的这些框尚无奈获取其值。只有在评估之后，它们的理论值才会被填写。该规定有一个正告：在此阶段中初始化所有导出的函数申明。这使评估工作变得更加容易。

为了实例化模块图，引擎将进行深度优先的后程序遍历。这意味着它将降落到图表的底部 - 底部的不依赖其余任何内容的依赖项 - 并设置其导出。

引擎实现了模块上面所有进口的接线 - 模块所依赖的所有进口。而后，它返回一个级别，以连贯来自该模块的导入。

请留神，导出和导入均指向内存中的同一地位。首先连贯进口，能够确保所有进口都能够连贯到匹配的进口。

这不同于 CommonJS 模块。在 CommonJS 中，整个导出对象在导出时被复制。这意味着导出的任何值（例如数字）都是正本。

这意味着，如果导出模块当前更改了该值，则导入模块将看不到该更改。

相同，ES 模块应用称为实时绑定的货色。两个模块都指向内存中的雷同地位。这意味着，当导出模块更改值时，该更改将显示在导入模块中。

导出值的模块能够随时更改这些值，然而导入模块不能更改其导入的值。话虽如此，如果模块导入了一个对象，则它能够更改该对象上的属性值。

之所以领有这样的实时绑定，是因为您能够在不运行任何代码的状况下连贯所有模块。当您具备循环依赖性时，这将有助于评估，如下所述。

因而，在此步骤完结时，咱们已连贯了所有实例以及导出 / 导入变量的存储地位。

当初咱们能够开始评估代码，并用它们的值填充这些内存地位。

4. 执行

最初一步是将这些框填充到内存中。JS 引擎通过执行顶级代码（函数内部的代码）来实现此目标。

除了仅在内存中填充这些框外，评估代码还可能触发副作用。例如，模块可能会调用服务器。

因为存在潜在的副作用，您只须要评估模块一次。与实例化中产生的链接能够完全相同的后果执行屡次相同，评估能够依据您执行多少次而得出不同的后果。

这是领有模块映射的起因之一。模块映射通过标准的 URL 缓存模块，因而每个模块只有一个模块记录。这样能够确保每个模块仅执行一次。与实例化一样，这是深度优先的后遍历。

那咱们之前谈到的那些周期呢？

在循环依赖关系中，您最终在图中有一个循环。通常，这是一个漫长的循环。然而为了解释这个问题，我将应用一个简短的循环的人为例子。

让咱们看一下如何将其与 CommonJS 模块一起应用。首先，主模块将执行直到 require 语句。而后它将去加载计数器模块。

而后，计数器模块将尝试 message 从导出对象进行拜访。然而因为尚未在主模块中对此进行评估，因而它将返回 undefined。JS 引擎将在内存中为局部变量调配空间，并将其值设置为 undefined。

评估始终继续到计数器模块顶级代码的开端。咱们想看看咱们是否最终将取得正确的音讯值（在评估 main.js 之后），因而咱们设置了超时工夫。而后评估在上复原main.js。

音讯变量将被初始化并增加到内存中。然而因为两者之间没有连贯，因而在所需模块中它将放弃未定义状态。

如果应用实时绑定解决导出，则计数器模块最终将看到正确的值。到超时运行时，main.js的评估将实现并填写值。

反对这些循环是 ES 模块设计背地的重要理由。正是这种设计使它们成为可能。

（以上是对于 ESM 的实践介绍，原文链接在文末）。

Bundle & Bundleless

谈及 Bundleless 的劣势，首先是 启动快。

因为不须要过多的打包，只须要解决批改后的单个文件，所以响应速度是 O(1) 级别，刷新即可即时失效，速度很快。

所以，在开发模式下，相比于 Bundle，Bundleless 有着微小的劣势。

基于 Webpack 的 bundle 开发模式

下面的图具体的模块加载机制能够简化为下图：

在我的项目启动和有文件变动时从新进行打包，这使得我的项目的启动和二次构建都须要做较多的事件，相应的耗时也会增长。

基于 ESModule 的 Bundleless 模式

从上图能够看到，曾经不再有一个构建好的 bundle、chunk 之类的文件，而是间接加载本地对应的文件。

从上图能够看到，在 Bundleless 的机制下，我的项目的启动只须要启动一个服务器承接浏览器的申请即可，同时在文件变更时，也只须要额定解决变更的文件即可，其余文件可间接在缓存中读取。

比照总结

Bundleless 模式能够充分利用浏览器自主加载的个性，跳过打包的过程，使得咱们能在我的项目启动时获取到极快的启动速度，在本地更新时只须要从新编译单个文件。

实现一个乞丐版 Vite

Vite 也是基于 ESM 的，文件处理速度 O(1)级别，十分快。

作为摸索，我就简略实现了一个乞丐版 Vite:

GitHub 地址：Vite-mini，

简要剖析一下。

<body>
  <div id="app"></div>
  <script type="module" src="/src/main.js"></script>
</body>

html 文件中间接应用了浏览器原生的 ESM（type="module"）能力。

所有的 js 文件通过 vite 解决后，其 import 的模块门路都会被批改，在后面加上 /@modules/。当浏览器申请 import 模块的时候，vite 会在 node_modules 中找到对应的文件进行返回。

其中最要害的步骤就是 模块的记录和解析，这里我简略用 koa 简略实现了一下，整体构造：

const fs = require('fs');
const path = require('path');
const Koa = require('koa');
const compilerSfc = require('@vue/compiler-sfc');
const compileDom = require('@vue/compiler-dom');
const app = new Koa();

// 解决引入门路
function rewriteImport(content) {// ...}

// 解决文件类型等，比方反对 ts, less 等相似 webpack 的 loader 的性能
app.use(async (ctx) => {// ...}

app.listen(3001, () => {console.log('3001');
});

咱们先看门路相干的解决：

function rewriteImport(content) {return content.replace(/from ['"]([^'"]+)['"]/g, function (s0, s1) {
        // import a from './c.js' 这种格局的不须要改写
        // 只改写须要去 node_module 找的
        if (s1[0] !== '.' && s1[0] !== '/') {return `from '/@modules/${s1}'`;
        }
        return s0;
    });
}

解决文件内容：源码地址

后续的都是相似的：

这个代码只是解释实现原理，不同的文件类型解决逻辑其实能够抽离进来，以中间件的模式去解决。

代码实现的比较简单，就不额解释了。

Snowpack

应用 Snowpack 做了个 demo, 反对打包，输入 bundle。

github: Snowpack-react-demo

可能清晰的看到，控制台产生了大量的文件申请，不过因为都是加载的本地文件，所以速度很快。

配合 HMR，实现编辑实现立即失效，简直不必期待：

对于打包：

打包实现的文件目录：

在 build 目录下启动一个动态文件服务：

build 模式下，还是借助了 webpack 的打包能力：

做了资源合并：

就这点而言，我认为将来一段时间内，生产环境还是不可避免的要走 bundle 模式。

bundleless 模式在理论开发中的一些问题

单刀直入吧，开发体验不是很敌对，几点比较突出的问题：

• 局部模块没有提供 ESModule 的包。（这一点尤为致命）
• 生态不够健全，工具链不够欠缺；

当然还有其余方方面面的问题，就不一一列举。

我简略革新了一个页面，就遇到很多奇奇怪怪的问题，开发起来非常好受，只管代码的批改能立即失效。

论断

bundleless 能在开发模式下带了很大的便当，但目前来说，还有一段路要走。

就目前而言，如果要用的话，可能还是 bundleless(dev) + bundle(production) 的组合。

至于将来能不能全面铺开 bundleless，我认为还是有可能的，交给工夫吧。

结尾

本文次要介绍了 esm 的原理，以及介绍了以此为根底的 Vite, Snowpack 等工具，提供了两个可运行的 demo：

• 1. Vite-mini，
• 1. Snowpack-React-Demo

并摸索了 bundleless 在生产中的可行性。

Bundleless 实质上是将原先 Webpack 中模块依赖解析的工作交给浏览器去执行，使得在开发过程中代码的转换变少，极大地晋升了开发过程中的构建速度，同时也能够更好地利用浏览器的相干开发工具。

非常感谢 ESModule、Vite、Snowpack 等规范和工具的呈现，为前端开发提效。

满腹经纶，文中若有谬误，还能各位大佬斧正，谢谢。

参考资料

1. https://hacks.mozilla.org/201…
2. https://developer.aliyun.com/…