写在前面
前端模块化/构建工具从最开始的基于浏览器运行时加载的RequireJs/Sea.js到将所有资源组装依赖打包webpack/rollup/parcel的bundle类模块化构建工具，再到现在的bundleless基于浏览器原生ES模块的snowpack/vite，前端的模块化/构建工具发展到现在已经快10年了。
本文主要回顾10年间，前端模块化/构建工具的发展历程及其实现原理。
看完本文你可以学到以下知识：
模块化规范方案
前端构建工具演变，对前端构建有一个系统性认识
各个工具诞生历程及所解决的问题
webpack/parcel/vite的构建流程及原理分析
（因涉及一些历史、趋势，本文观点仅代表个人主观看法）
基于浏览器的模块化
·CommonJS
一切的开始要从CommonJS规范说起。
CommonJS本来叫ServerJs，其目标本来是为浏览器之外的javascript代码制定规范，在那时NodeJs还没有出生，有一些零散的应用于服务端的JavaScript代码，但是没有完整的生态。
之后就是NodeJs从CommonJS社区的规范中吸取经验创建了本身的模块系统。
·RequireJs和AMD
CommonJs是一套同步模块导入规范，但是在浏览器上还没法实现同步加载，这一套规范在浏览器上明显行不通，所以基于浏览器的异步模块AMD(AsynchronousModuleDefinition)规范诞生。
define(id?,dependencies?,factory);
AMD规范采用依赖前置，先把需要用到的依赖提前写在dependencies数组里，在所有依赖下载完成后再调用factory回调，通过传参来获取模块，同时也支持require("beta")的方式来获取模块，但实际上这个require只是语法糖，模块并非在require的时候导入，而是跟前面说的一样在调用factory回调之前就被执行，关于依赖前置和执行时机这点在当时有很大的争议，被CommonJs社区所不容。
在当时浏览器上应用CommonJs还有另外一个流派module/.0，其中有BravoJS的Modules/.0-draft规范和FlyScript的Modules/Wrappings规范。
代码实现大致如下：
奈何RequireJs如日中天，根本争不过。
关于这段的内容可以看玉伯的前端模块化开发那点历史。
·Sea.js和CMD
在不断给RequireJs提建议，但不断不被采纳后，玉伯结合RequireJs和module/.0规范写出了基于CMD（CommonModuleDefinition）规范的Sea.js。
define(factory);
在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采用配置化的思想：
基于nodejs的一系列自动化工具的出现，也标志着前端进入了新的时代。
·browserify
browserify致力于在浏览器端使用CommonJs，他使用跟NodeJs一样的模块化语法，然后将所有依赖文件编译到一个bundle文件，在浏览器通过script标签使用的，并且支持npm库。
当时RequireJs(r.js)虽然也有了node端的api可以编译AMD语法输出到单个文件，但主流的还是使用浏览器端的RequireJs。
AMD/RequireJS：
CommonJs:
相比于AMD规范为浏览器做出的妥协，在服务端的预编译方面CommonJs的语法更加友好。
常用的搭配就是browserify+Grunt，使用Grunt的browserify插件来构建模块化代码，并对代码进行压缩转换等处理。
·UMD
现在有了RequireJs，也有了browserify但是这两个用的是不同的模块化规范，所以有了UMD-通用模块规范，UMD规范就是为了兼容AMD和CommonJS规范。就是以下这坨东西：
·Gulp
上面说到Grunt是基于配置的，配置化的上手难度较高，需要了解每个配置的参数，当配置复杂度上升的时候，代码看起来比较混乱。
gulp基于代码配置和对Node.js流的应用使得构建更简单、更直观。可以配置更加复杂的任务。
以上是一个配置browserify的例子，可以看出来非常简洁直观。
·webpack
在说webpack之前，先放一下阮一峰老师的吐槽
webpack1支持CommonJs和AMD模块化系统，优化依赖关系，支持分包，支持多种类型script、image、file、css/less/sass/stylus、mocha/eslint/jshint的打包，丰富的插件体系。
以上的个库Grunt/Gulp/browserify都是偏向于工具，而webpack将以上功能都集成到一起，相比于工具它的功能大而全。
webpack的概念更偏向于工程化，但是在当时并没有马上火起来，因为当时的前端开发并没有太复杂，有一些mvc框架但都是昙花一现，前端的技术栈在requireJs/sea.js、grunt/gulp、browserify、webpack这几个工具之间抉择。
webpack真正的火起来是在/，随着ES（ES6）发布，不止带来了新语法，也带来了属于前端的模块规范ESmodule，vue/react/Angular三大框架打得火热，webpack发布：支持ESmodule、babel、typescript，jsx，Angular组件和vue组件，webpack搭配react/vue/Angular成为最佳选择，至此前端开发离不开webpack，webpack真正成为前端工程化的核心。
webpack的其他功能就不在这里赘述。
·原理
webpack主要的三个模块就是，后两个也是我们经常配置的：
核心流程
loader
plugins
webpack依赖于Tapable做事件分发，内部有大量的hooks钩子，在Compiler和