写在前面
前端模块化/构建工具从最开始的基于浏览器运行时加载的 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文件，在浏览器通过
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 的速度远远甩开其他构建工具。
总结
简单的汇总：
前端运行时模块化
RequireJsAMD 规范sea.jsCMD 规范
自动化工具
Grunt基于配置Gulp基于代码和文件流
模块化
browserify基于CommonJs规范只负责模块化rollup基于ES module，tree shaking优化代码，支持多种规范导出，可通过插件集成压缩、编译、commonjs 语法 等功能
工程化
webpack大而全的模块化构建工具parcel极速 0 配置的模块化构建工具snowpack/viteESM运行时模块化构建工具
这 10 年，前端的构建工具随着 nodejs 的逐渐成熟衍生出一系列的工具，除了文中列举的还有一些其他的工具，或者基于这些工具二次封装，在nodejs出现之前前端也不是没有构建工具虽然很少，只能说nodejs的出现让更多人可以参与进来，尤其是前端可以使用本身熟悉的语言参与到开发工具使用工具中，npm 上至今已经有 17 万个包，周下载量 300 亿。
在这个过程中也有些模块化历史遗留问题，我们现在还在使用着 UMD 规范库来兼容这 AMD 规范，npm 的包大都是基于CommonJs，不得不兼容ESM和CommonJs。
webpack统治前端已经 5 年，人们提到开发项目只会想到 webpack，而下一个 5 年会由谁来替代？snowpack/vite吗，当打包速度达到 0 秒后，未来有没有可能出现新一代的构建工具？下一个 10 年前端又会有什么变化？