关于vite:前端构建这十年

写在后面

前端模块化 / 构建工具从最开始的基于浏览器 运行时 加载的 RequireJs/Sea.js 到将所有资源组装依赖打包 webpack/rollup/parcel的 bundle 类模块化构建工具，再到当初的 bundleless 基于浏览器原生 ES 模块的 snowpack/vite，前端的模块化 / 构建工具倒退到当初曾经快 10 年了。

本文次要回顾 10 年间，前端模块化 / 构建工具的倒退历程及其实现原理。

（因波及一些历史、趋势，本文观点仅代表集体主观认识）

基于浏览器的模块化

CommonJS

所有的开始要从 CommonJS 标准说起。

CommonJS 原本叫 ServerJs，其指标原本是为 浏览器之外 的javascript代码制订标准，在那时 NodeJs 还没有出世，有一些零散的利用于服务端的 JavaScript 代码，然而没有残缺的生态。

之后就是 NodeJs 从 CommonJS 社区的标准中吸取经验创立了自身的模块零碎。

RequireJs 和 AMD

CommonJs 是一套同步模块导入标准，然而在浏览器上还没法实现同步加载，这一套标准在浏览器上显著行不通，所以基于浏览器的异步模块 AMD(Asynchronous Module Definition)标准诞生。

define(id?, dependencies?, factory);

define("alpha", ["require", "exports", "beta"], function (
  require,
  exports,
  beta
) {exports.verb = function () {return beta.verb();
    //Or:
    return require("beta").verb();};
});

AMD标准采纳 依赖前置 ，先把须要用到的依赖提前写在 dependencies 数组里，在所有依赖下载实现后再调用factory 回调，通过传参来获取模块，同时也反对 require("beta") 的形式来获取模块，但实际上这个 require 只是语法糖，模块并非在 require 的时候导入，而是跟后面说的一样在调用 factory 回调之前就被执行，对于依赖前置和执行机会这点在过后有很大的争议，被 CommonJs社区所不容。

在过后浏览器上利用 CommonJs 还有另外一个流派 module/2.0，其中有 BravoJS 的 Modules/2.0-draft 标准和 FlyScript的 Modules/Wrappings 标准。

代码实现大抵如下：

module.declare(function (require, exports, module) {var a = require("a");
  exports.foo = a.name;
});

奈何 RequireJs 如日中天，基本争不过。

对于这段的内容能够看玉伯的 前端模块化开发那点历史。

Sea.js 和 CMD

在一直给 RequireJs 提倡议，但一直不被驳回后，玉伯联合 RequireJs 和module/2.0标准写出了基于 CMD（Common Module Definition）标准的Sea.js。

define(factory);

define(function (require, exports, module) {var add = require("math").add;
  exports.increment = function (val) {return add(val, 1);
  };
});

在 CMD 标准中，一个模块就是一个文件。模块只有在被 require 才会被执行。
相比于 AMD 标准，CMD 更加简洁，而且也更加易于兼容 CommonJS 和 Node.js 的 Modules 标准。

总结

RequireJs和 Sea.js 都是利用动态创建 script 来异步加载 js 模块的。

在作者还是前端小白应用这两个库的时候就很好奇它是怎么在函数调用之前就获取到其中的依赖的，起初看了源码后豁然开朗，没想到就是简略的函数 toString 办法

通过对 factory 回调 toString 拿到函数的代码字符串，而后通过正则匹配获取 require 函数外面的字符串依赖

这也是为什么二者都不容许 require 更换名称或者变量赋值，也不容许依赖字符串应用变量，只能应用字符串字面量的起因

标准之争在过后还是相当凌乱的，先有 CommonJs 社区，而后有了 AMD/CMD 标准和 NodeJs 的 module 标准，然而当那些 CommonJs 的实现库逐步败落，并随着 NodeJs 越来越火，咱们口中所说的 CommonJs 如同就只有 NodeJs 所代表的 modules 了。

bundle 类的构建工具

Grunt

随着 NodeJs 的逐步风行，基于 NodeJs 的自动化构建工具 Grunt 诞生

Grunt能够帮咱们自动化解决须要重复反复的工作，例如压缩（minification）、编译、单元测试、linting 等，还有弱小的插件生态。

Grunt采纳配置化的思维：

module.exports = function (grunt) {
  // Project configuration.
  grunt.initConfig({pkg: grunt.file.readJSON("package.json"),
    uglify: {
      options: {
        banner:
          '/*! <%= pkg.name %> <%= grunt.template.today("yyyy-mm-dd") %> */\n',
      },
      build: {
        src: "src/<%= pkg.name %>.js",
        dest: "build/<%= pkg.name %>.min.js",
      },
    },
  });

  // 加载蕴含 "uglify" 工作的插件。grunt.loadNpmTasks("grunt-contrib-uglify");

  // 默认被执行的工作列表。grunt.registerTask("default", ["uglify"]);
};

基于 nodejs 的一系列自动化工具的呈现，也标记着前端进入了新的时代。

browserify

browserify致力于在浏览器端应用 CommonJs，他应用跟 NodeJs 一样的模块化语法，而后将所有依赖文件编译到一个bundle 文件，在浏览器通过 <script> 标签应用的，并且反对 npm 库。

var foo = require("./foo.js");
var gamma = require("gamma");

var elem = document.getElementById("result");
var x = foo(100);
elem.textContent = gamma(x);

$ browserify main.js > bundle.js

过后 RequireJs(r.js) 尽管也有了 node 端的 api 能够编译 AMD 语法输入到单个文件，但支流的还是应用浏览器端的RequireJs。

AMD / RequireJS：

require(["./thing1", "./thing2", "./thing3"], function (
  thing1,
  thing2,
  thing3
) {
  // 通知模块返回 / 导出什么
  return function () {console.log(thing1, thing2, thing3);
  };
});

CommonJS：

var thing1 = require("./thing1");
var thing2 = require("./thing2");
var thing3 = require("./thing3");

// 通知模块返回 / 导出什么
module.exports = function () {console.log(thing1, thing2, thing3);
};

相比于 AMD 标准为浏览器做出的斗争，在服务端的预编译方面 CommonJs 的语法更加敌对。

罕用的搭配就是 browserify + Grunt，应用 Grunt 的browserify插件来构建模块化代码，并对代码进行压缩转换等解决。

UMD

当初有了 RequireJs，也有了browserify 然而这两个用的是不同的模块化标准，所以有了 UMD – 通用模块标准，UMD 标准就是为了兼容 AMD 和CommonJS标准。就是以下这坨货色：

(function (global, factory) {
  typeof exports === "object" && typeof module !== "undefined"
    ? (module.exports = factory())
    : typeof define === "function" && define.amd
    ? define(factory)
    : (global.libName = factory());
})(this, function () {"use strict";});

Gulp

下面说到 Grunt 是基于配置的，配置化的上手难度较高，须要理解每个配置的参数，当配置复杂度回升的时候，代码看起来比拟凌乱。
gulp 基于代码配置和对 Node.js 流的利用使得构建更简略、更直观。能够配置更加简单的工作。

var browserify = require("browserify");
var source = require("vinyl-source-stream");
var buffer = require("vinyl-buffer");
var uglify = require("gulp-uglify");
var size = require("gulp-size");
var gulp = require("gulp");

gulp.task("build", function () {var bundler = browserify("./index.js");

  return bundler
    .bundle()
    .pipe(source("index.js"))
    .pipe(buffer())
    .pipe(uglify())
    .pipe(size())
    .pipe(gulp.dest("dist/"));
});

以上是一个配置 browserify 的例子，能够看进去十分简洁直观。

webpack

在说 webpack 之前，先放一下阮一峰老师的吐槽

webpack1反对 CommonJs 和AMD模块化零碎，优化依赖关系，反对分包，反对多种类型 script、image、file、css/less/sass/stylus、mocha/eslint/jshint 的打包，丰盛的插件体系。

以上的 3 个库 Grunt/Gulp/browserify 都是偏差于工具，而 webpack将以上性能都集成到一起，相比于工具它的性能大而全。

webpack的概念更偏差于工程化，然而在过后并没有马上火起来，因为过后的前端开发并没有太简单，有一些 mvc 框架但都是过眼云烟，前端的技术栈在 requireJs/sea.js、grunt/gulp、browserify、webpack 这几个工具之间抉择。

webpack真正的火起来是在 2015/2016，随着ES2015（ES6）公布，不止带来了新语法，也带来了属于前端的模块标准ES module，vue/react/Angular 三大框架打得火热，webpack2 公布：反对 ES module、babel、typescript，jsx，Angular 2 组件和 vue 组件，webpack 搭配 react/vue/Angular 成为最佳抉择，至此前端开发离不开 webpack，webpack 真正成为前端工程化的外围。

webpack的其余性能就不在这里赘述。

原理

webpack次要的三个模块就是，后两个也是咱们常常配置的：

• 外围流程
• loader
• plugins

webpack依赖于 Tapable 做事件散发，外部有大量的 hooks 钩子，在 Compiler 和compilation 外围流程中通过钩子散发事件，在 plugins 中注册钩子，理论代码全都由不同的内置 plugins 来执行，而 loader 在两头负责转换代码承受一个源码解决后返回处理结果content string -> result string。

因为钩子太多了，webpack 源码看起来非常的绕，简略说一下大抵流程：

1. 通过命令行和 webpack.config.js 来获取参数
2. 创立 compiler 对象，初始化plugins
3. 开始编译阶段，addEntry增加入口资源
4. addModule 创立模块
5. runLoaders 执行 loader
6. 依赖收集，js 通过 acorn 解析为 AST，而后查找依赖，并反复 4 步
7. 构建完 依赖树 后，进入生成阶段，调用compilation.seal
8. 通过一系列的 optimize 优化依赖，生成 chunks，写入文件

webpack的长处就不用说了，当初说一下 2 个毛病：

• 配置简单
• 大型项目构建慢

配置简单这一块始终是 webpack 被吐槽的一点，次要还是过重的插件零碎，简单的插件配置，插件文档也不清晰，更新过快插件没跟上或者文档没跟上等问题。

比方当初 webpack 曾经到 5 了网上一搜全都是 webpack3 的文章，往往是新增一个性能，依照文档配置完后，诶有报错，网上一顿查，这里拷贝一段，那里拷贝一段，又来几个报错，又通过一顿搞后终于能够运行。

起初针对这个问题，衍生出了前端脚手架，react出了 create-react-app，vue 出了 vue-cli，脚手架内置了webpack 开发中的罕用配置，达到了 0 配置，开发者无需关怀 webpack 的简单配置。

rollup

2015 年，前端的 ES module 公布后，rollup应声而出。

rollup编译 ES6 模块，提出了 Tree-shaking，依据ES module 动态语法个性，删除未被理论应用的代码，反对导出多种标准语法，并且导出的代码十分简洁，如果看过 vue 的dist 目录代码就晓得导出的 vue 代码齐全不影响浏览。

rollup的插件零碎反对：babel、CommonJs、terser、typescript等性能。

相比于 browserify 的CommonJs，rollup专一于 ES module。
相比于 webpack 大而全的前端工程化，rollup专一于纯 javascript，大多被用作打包tool 工具或 library 库。

react、vue 等库都应用 rollup 打包我的项目，并且上面说到的 vite 也依赖 rollup 用作生产环境打包 js。

Tree-shaking

export const a = 1;
export const b = 2;

import {a} from "./num";

console.log(a);

以上代码最终打包后 b 的申明就会被删除掉。

这依赖 ES module 的动态语法，在编译阶段就能够确定模块的导入导出有哪些变量。

CommonJs 因为是基于运行时的模块导入，其导出的是一个整体，并且 require(variable) 内容能够为变量，所以在 ast 编译阶段没方法辨认为被应用的依赖。

webpack4中也开始反对 tree-shaking，然而因为历史起因，有太多的基于CommonJS 代码，须要额定的配置。

parcel

下面提到过 webpack 的两个毛病，而 parcel 的诞生就是为了解决这两个毛病，parcel 主打 极速零配置。

以上是 parcel 官网的一个数据，基于一个正当大小的利用，蕴含 1726 个模块，6.5M 未压缩大小。在一台有 4 个物理外围 CPU 的 2016 MacBook Pro 上构建。

parcel 应用 worker 过程去启用多核编译，并且应用文件缓存。

parcel 反对 0 配置，内置了 html、babel、typescript、less、sass、vue等性能，无需配置，并且不同于 webpack 只能将 js 文件作为入口，在 parcel 中万物皆资源，所以 html 文件 css 文件都能够作为入口来打包。

所以不须要 webpack 的简单配置，只须要一个 parcel index.html 命令就能够间接起一个自带热更新的 server 来开发 vue/react 我的项目。

parcel 也有它的毛病：

• 0 配置的代价，0 配置是好，然而如果想要配置一些简单的配置就很麻烦。
• 生态，相比于 webpack 比拟小众，如果遇到谬误查找解决方案比拟麻烦。

原理

1. commander 获取命令
2. 启动 server 服务，启动 watch监听文件，启动 WebSocket 服务用于 hmr，启动多线程
3. 如果是第一次启动，针对入口文件开始编译
4. 依据扩展名生成对应 asset 资源，例如 jsAsset、cssAsset、vueAsset，如果parcel 辨认 less 文件后我的项目内如果没有 less 库会主动装置
5. 读取缓存，如果有缓存跳到第 7 步
6. 多线程编译文件，调用 asset 内办法parse -> ast -> 收集依赖 -> transform(转换代码) -> generate(生成代码)，在这个过程中收集到依赖，编译完后果写入缓存
7. 编译依赖文件，反复第 4 步开始
8. createBundleTree 创立依赖树，替换 hash 等，package打包生成最终代码
9. 当 watch 文件发生变化，反复第 4 步，并将后果 7 通过 WebSocket 发送到浏览器，进行热更新。

一个残缺的模块化打包工具就以上性能和流程。

基于浏览器 ES 模块的构建工具

browserify、webpack、rollup、parcel这些工具的思维都是递归循环依赖，而后组装成依赖树，优化完依赖树后生成代码。
然而这样做的毛病就是慢，须要遍历完所有依赖，即便 parcel 利用了多核，webpack 也反对多线程，在打包大型项目的时候仍然慢可能会用上几分钟，存在性能瓶颈。

所以基于浏览器原生 ESM 的运行时打包工具呈现：

仅打包屏幕中用到的资源，而不必打包整个我的项目，开发时的体验相比于 bundle类的工具只能用极速来形容。
（理论生产环境打包仍然会构建依赖形式打包）

snowpack 和 vite

因为 snowpack 和 vite 比拟相似，都是 bundleless 所以一起拿来说，区别能够看一下 vite 和 snowpack 区别，这里就不赘述了。

bundleless类运行时打包工具的启动速度是毫秒级的，因为不须要打包任何内容，只须要起两个 server，一个用于页面加载，另一个用于HMR 的WebSocket，当浏览器收回原生的 ES module 申请，server收到申请只需编译以后文件后返回给浏览器不须要管依赖。

bundleless工具在 生产环境 打包的时候仍然 bundle 构建所以依赖视图的形式，vite 是利用 rollup 打包生产环境的 js 的。

原理拿 vite 举例：

vite在启动服务器后，会事后以所有 html 为入口，应用 esbuild 编译一遍，把所有的 node_modules 下的依赖编译并缓存起来，例如 vue 缓存为单个文件。

当关上在浏览器中输出链接，渲染 index.html 文件的时候，利用浏览器自带的 ES module 来申请文件。

<script type="module" src="/src/main.js"></script>

vite 收到一个 src/main.js 的 http 文件申请，应用 esbuild 开始编译 main.js，这里不进行main.js 外面的依赖编译。

import {createApp} from "vue";
import App from "./App.vue";

createApp(App).mount("#app");

浏览器获取到并编译 main.js 后，再次收回 2 个申请，一个是 vue 的申请，因为后面曾经说了 vue 被事后缓存下来，间接返回缓存给浏览器，另一个是 App.vue 文件，这个须要 @vitejs/plugin-vue 来编译，编译实现后返回后果给浏览器（@vitejs/plugin-vue会在脚手架创立模板的时候主动配置）。

因为是基于浏览器的ES module，所以编译过程中须要把一些 CommonJs、UMD 的模块都转成 ESM。

Vite 同时利用 HTTP 头来减速整个页面的从新加载（再次让浏览器为咱们做更多事件）：源码模块的申请会依据 304 Not Modified 进行协商缓存，而依赖模块申请则会通过 Cache-Control: max-age=31536000,immutable 进行强缓存，因而一旦被缓存它们将不须要再次申请，即便缓存生效只有服务没有被杀死，编译后果仍然保留在程序内存中也会很快返回。

下面屡次提到了 esbuild，esbuild 应用 go 语言编写，所以在 i/o 和运算运行速度上比解释性语言 NodeJs 快得多，esbuild 号称速度是 node 写的其余工具的 10~100 倍。

ES module 依赖运行时编译的概念 + esbuild + 缓存 让 vite 的速度远远甩开其余构建工具。

总结

简略的汇总：

• 前端运行时模块化

  • RequireJs AMD 标准
  • sea.js CMD 标准

• 自动化工具

  • Grunt 基于配置
  • Gulp 基于代码和文件流

• 模块化

  • browserify 基于 CommonJs 标准只负责模块化
  • rollup 基于 ES module，tree shaking 优化代码，反对多种标准导出，可通过插件集成压缩、编译、commonjs 语法 等性能

• 工程化

  • webpack 大而全的模块化构建工具
  • parcel 极速 0 配置的模块化构建工具
  • snowpack/vite ESM运行时模块化构建工具

这 10 年，前端的构建工具随着 nodejs 的逐步成熟衍生出一系列的工具，除了文中列举的还有一些其余的工具，或者基于这些工具二次封装，在 nodejs 呈现之前前端也不是没有构建工具尽管很少，只能说 nodejs 的呈现让更多人能够参加进来，尤其是前端能够应用自身相熟的语言参加到开发工具应用工具中，npm 上至今曾经有 17 万个包，周下载量 300 亿。

在这个过程中也有些模块化历史遗留问题，咱们当初还在应用着 UMD 标准库来兼容这 AMD 标准，npm 的包大都是基于 CommonJs，不得不兼容ESM 和CommonJs。

webpack统治前端曾经 5 年，人们提到开发我的项目只会想到 webpack，而下一个 5 年会由谁来代替？snowpack/vite吗，当打包速度达到 0 秒后，将来有没有可能呈现新一代的构建工具？下一个 10 年前端又会有什么变动？