写在后面

前端模块化/构建工具从最开始的基于浏览器运行时加载的 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 主打极速零配置。

打包工具工夫
browserify22.98s
webpack20.71s
parcel9.98s
parcel - with cache2.64s

以上是 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 年前端又会有什么变动？