JavaScript前端構建工具原理的理解

更新時間：2022年07月19日 11:44:10 作者：0o華仔o0

這篇文章主要為大家介紹了JavaScript前端構建工具原理的理解分享，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進步，早日升職加薪

前言

最近有幸在前端團隊里面做了一次關于 webpack 的技術分享。在分享的準備過程中，為了能讓大家更好的理解 webpack，特意對市面上以前和現(xiàn)在流行的構建工具做了一個梳理總結。在整理和分享的過程中，獲益匪淺，對前端構建工具有了新的認識。在這里，將自己的一些思考總結寫出來，希望也能給到對構建工具同樣感興趣的同學一點幫助。

本文的目錄結構如下:

構建工具的前世今生
js 模塊化的發(fā)展史和構建工具的變化
結束語

構建工具的前世今生

談到構建工具，大家首先想到的肯定就是 Webpack 以及現(xiàn)在最??的 Vite。Webpack，功能強大，生態(tài)豐富，從面世到今天，一直是很受大家歡迎；Vite 采用 unbundle 構建模式，帶來了極致的開發(fā)體驗，給開發(fā)人員以新的選擇。

在這兩個構建工具之外，還有其他的構建工具，如和 Webpack、Vite 類似的 Rollup、Parcel、Esbuild，自動化構建工具 grunt、gulp，以及更加久遠的 YUI Tool。

這些工具的存在，構成了前端構建工具的發(fā)展史。

YUI Tool + Ant

YUI tool 是 07 年左右出現(xiàn)的一個構建工具，功能比較簡單，用于壓縮混淆 css 和 js 代碼，需要配合 java 的 Ant 使用。

當時 web 應用開發(fā)主要采用 JSP，還不像現(xiàn)在這樣前后端分離，通常是由 java 開發(fā)人員來編寫 js、css 代碼，前端代碼都是和后端 java 代碼放在一起的。因此前端代碼的壓縮混淆也就基于 java 實現(xiàn)了。

Grunt / Gulp

Grunt / Gulp 都是運行在 node 環(huán)境上的自動化工具。

在開發(fā)過程中，我們可以將一些常見操作如解析 html、es6 代碼轉換為 es5、less / sass 代碼轉換為 css 代碼、代碼檢查、代碼壓縮、代碼混淆配置成一系列任務，然后通過 Grunt / Gulp 自動執(zhí)行這些任務。

Grunt 和 Gulp 的不同點：

使用 Grunt的過程中，會產生一些中間態(tài)的臨時文件。一些任務生成臨時文件，其它任務可能會基于臨時文件再做處理并生成最終的構建后文件，導致出現(xiàn)多次 I/O。
Gulp 有文件流的概念，通過管道將多個任務和操作連接起來，不會產生臨時文件，減少了 I/O 操作，流程更清晰，更純粹，大大加快了構建的速度。

Webpack / Rollup / Parcel

Webpack、Rollup、Parcel 統(tǒng)稱為靜態(tài)模塊打包器。

這一類構建工具，通常需要指定入口 - entry，然后以 entry 為起點，通過分析整個項目內各個源文件之間的依賴關系，構建一個模塊依賴圖 - module graph，然后再將 module graph 分離為三種類型的 bundle: entry 所在的 initial bundle、lazy load 需要的 async bundle 和自定義分離規(guī)則的 custome bundle。

這幾個構建工具各有優(yōu)勢:

Webpack 大而全，配置靈活，生態(tài)豐富，是構建工具的首選。
Parcel 號稱零配置，使用簡單，適合不太需要定制化構建的項目使用。
Rollup 推崇 ESM 標準開發(fā)，打包出來的代碼干凈，適用于組件庫開發(fā)。

Vite / Esbuild

新一代構建工具。

esbuild, 基于 go 語言實現(xiàn)，代碼直接編譯成機器碼(不用像 js 那樣先解析為字節(jié)碼，再編譯為機器碼)，構建速度比 webpack 更快。

vite, 開發(fā)模式下借助瀏覽器對 ESM 的支持，采用 nobundle 的方式進行構建，能提供極致的開發(fā)體驗；生產模式下則基于 rollup 進行構建。

js 模塊化的發(fā)展史和構建工具的變化

javascript 語言設計之初，只是作為一個簡單的腳本語言用來豐富網(wǎng)站的功能，并不像 java、c++ 那樣有 module 的概念，發(fā)展到現(xiàn)在的模樣，也經歷了相當長的時間。

這段時間，可以簡單歸納為：

青銅時代 - no module；
白銀時代 - cjs、amd、cmd、umd、esm 相繼出現(xiàn)；
黃金時代 - 組件模塊化；

不同的時代，構建工具也不同。

青銅時代

由于沒有 module 的概念, javascript 無法在語言層面實現(xiàn)模塊之間的相互隔離、相互依賴，只能由開發(fā)人員手動處理。

相應的，早期的 web 開發(fā)也比較簡單甚至簡陋:

通過對象、iife(或者閉包)的方式實現(xiàn)模塊隔離；
通過手動確定 script 的加載順序確定模塊之間的依賴關系。
jsp 開發(fā)模式，沒有專門的前端，html、js、css 代碼通常也由后端開發(fā)人員編寫。

為了節(jié)省帶寬和保密，通常需要對前端代碼做壓縮混淆處理。這個時候，構建工具為 YUI Tool + Ant。

白銀時代

chrome v8 引擎和 node 的橫空出世，給前端帶來了無限的可能。

同時，javascript 的模塊化標準也有了新的發(fā)展:

commonjs 規(guī)范，適用于 node 環(huán)境開發(fā)。
amd、cmd 規(guī)范，適用于瀏覽器環(huán)境。
umd，兼容 amd、commonjs，代碼可以同時運行在瀏覽器和 node 環(huán)境。
ESM，即 ES6 module(這個時候還不是很成熟)；

同時還出現(xiàn)了 less、sass、 es6、 jslint、 eslint、typescript 等新的東西，前端角色也開始承擔越來越重要的作用，慢慢的獨立出來。

有了 node 提供的平臺，大量的工具開始涌現(xiàn):

requirejs 提供的 r.js 插件，可以分析 amd 模塊依賴關系、合并壓縮 js、優(yōu)化 css；
less / sass 插件，可以將 less / sass 代碼轉化為 css 代碼；
babel，可以將 es6 轉化為 es5；
typescript，將 ts 編譯為 js；
jslint / eslint，代碼檢查；
...

這個時候，我們可以將上面的的這些操作配置成一個個任務，然后通過 Grunt / Gulp 自動執(zhí)行任務。

黃金時代

基于 Angular、Vue、React 三大框架和 Webpack 的使用，組件模塊化成為前端開發(fā)的主流模式。同時 ESM 規(guī)范也原來越成熟，被更多的瀏覽器支持。

以 React 和 Webpack 為例，通常我們會將一個應用涉及到的所有的功能拆分為一個個組件，如路由組件、頁面組件、表單組件、表格組件等，一個組件對應一個源文件，然后通過 Webpack 將這些源文件打包。在開發(fā)過程中，還會通過 Webpack 開啟一個 local server，實時查看代碼的運行效果。

Webpack 是一個靜態(tài)模塊打包器，它會以 entry 指定的入口文件為起點，分析整個項目內各個源文件之間的依賴關系，構建一個模塊依賴圖 - module graph，然后將 module graph 分離為多個 bundle。在構建 module graph 的過程中，會使用 loader 處理源文件，將它們轉化為瀏覽器可以是識別的 js、css、image、音視頻等。

隨著時間的發(fā)展， Webpack 的功能越來越來強大，也迎來諸多對手。

Webpack1
   |
   |
Rollup 出現(xiàn)(推崇 ESM 規(guī)范，可以實現(xiàn) tree shaking, 打包出來的代碼更干凈)
   |
   |
Webpack2(也實現(xiàn)了 tree shaking, 但是配置還是太繁瑣了)
   |
   |
Parcel (號稱 0 配置)
   |
   |
Webpack4(通過 mode 確定 development 和 production 模式，各個模式有自己的默認配置)
   |
   |
Webpack5(持久化緩存、module federation)
Esbuild(采用 go 語言開發(fā)，比 Webpack 更快)
Vite(推崇 ESM 規(guī)范，開發(fā)模式采用 nobundle，更好的開發(fā)體驗)

豐富的構建工具，形成了百花綻放的局面，可用于不同的情形，給開發(fā)人員帶來了越來越多的選擇。