作為前端工程師，前端工程化是經常聽到的概念，但雖然經常聽到，很多人對它的認識依然很模糊。

比如，提到前端工程化，他并不能說出什么是前端工程化。給出一門具體的技術，他也不能確定是不是屬于工程化范疇的技術。

這是因為他沒有對前端工程化有一個概念上的認識。

那么，這篇文章我們就來給前端工程化下個定義吧。

什么是前端工程化

提到前端工程化，最容易想到的就是編譯了。很多代碼需要經過編譯才能運行在目標環(huán)境：

• 高版本的語法需要用 babel 編譯成低版本的。
• less、sass 要經過各自的編譯器轉換成 css 代碼。
• TypeScript 代碼需要經過 tsc 或者 babel 等編譯器轉成 JS 代碼。
• ...

前端工程化首先要做的就是支持各種代碼的編譯。

最早的前端工程化是通過任務的形式組織這些編譯過程的，指定對什么文件用什么編譯器編譯，然后輸出到哪個目錄。任務之間可以規(guī)定先后順序、串行并行。

gulp 就是這一類工具，叫做任務運行器（task runner）。

這一類工具能夠組織整個編譯流程，對不同的文件分別做相應的處理，使之能運行在目標環(huán)境。但因為每個任務都比較獨立，很難做一些全局的優(yōu)化。

后來出現(xiàn)了另一種思路，不通過任務組織了，而是分析模塊之間的依賴關系，從入口模塊開始構建一棵依賴圖，中間遇到的用到的 js、css、圖片等都會作為他的依賴。然后對依賴圖的每個節(jié)點分別用對應的編譯器處理。

有的同學說，這個和 task runner 的方式有啥區(qū)別，不都是對不同的文件用不同的編譯器處理么？

那肯定有區(qū)別呀，現(xiàn)在有了模塊之間的依賴圖了，那就可以做一些全局的優(yōu)化：

比如通過分析依賴關系來去掉一些沒有用到的代碼，這叫做 tree shaking。

比如把這些模塊拆分到不同的分組（chunk）里，然后生成不同的文件，這樣把變動頻繁的模塊和不咋變動的模塊分到不同的 chunk，進而生成到不同的文件里，就可以更好的利用緩存，這叫做 code splitting。

而且，因為生成的代碼是自己控制的，有自己的 runtime 代碼，那就可以配合 runtime 來實現(xiàn)一些功能，比如實現(xiàn)模塊的 lazy load，也就是把 code splitting 分出來的 chunk，在運行時動態(tài)加載。

這叫做打包工具（bundler），典型的是 webpack。

任務運行器和打包工具的區(qū)別還是很明顯的：

任務運行器只是把不同的編譯任務組織起來，并不參與具體的代碼處理，具體處理啥文件，怎么處理都是開發(fā)者指定的。

而打包工具則是分析模塊依賴關系，構成依賴圖，通過這種方式確定處理哪些文件，可以基于這種依賴關系實現(xiàn) tree shking、code splitting 等優(yōu)化，并且生成的代碼會有自己的 runtime，可以配合 runtime 實現(xiàn) lazy load 等功能。

因為打包工具這種明顯的優(yōu)勢，慢慢的就取代了任務運行器，成為了構建的主流方式。

但是打包工具也不是完美的，因為每次都要構建整個依賴圖，對不同文件分別做處理，之后才能生成代碼，所以當項目的模塊多了就會很慢，大項目打包幾分鐘也是很常見的事情。

有痛點問題，大家就會想辦法去解決，所以出現(xiàn)了 no bundle 的方案，也就是不打包，比如 vite。

不打包也就不會進行依賴分析，那怎么確定處理哪些文件呢？

no bundle 是基于瀏覽器支持 es module 來實現(xiàn)的，瀏覽器會做 es module 的依賴分析，然后加載對應的模塊，這樣自然就不用自己做依賴分析了，只需要實現(xiàn)模塊的編譯即可。

所以，no bundle 工具會啟動一個開發(fā)服務器，根據(jù)請求的模塊路徑來進行相應的編譯，然后返回編譯后的代碼。

當然，生產環(huán)境還是需要打包的，會用打包工具來處理。no bundle 方案只是解決了開發(fā)環(huán)境下打包工具要構建整個依賴圖導致比較慢的痛點問題。

我們回過頭來綜合看一下：

構建的核心是對不同的文件做不同的編譯，最早的任務運行器的方案實現(xiàn)了編譯流程的組織，但是并沒有做全局的優(yōu)化，也沒有自己的 runtime 代碼，所以出現(xiàn)了基于依賴分析的打包工具，打包工具可以基于依賴分析實現(xiàn) treeshking、code splitting 等優(yōu)化，可以配合 runtime 代碼實現(xiàn) lazy load。但成也依賴分析，敗也依賴分析，這個太慢了，所以出現(xiàn)了 no bundle 的方案，配合瀏覽器對 es module 的支持，只要實現(xiàn)對應模塊的編譯服務即可，不過生產環(huán)境還是要打包的。

那我們馬后炮一下，假如回到 gulp 當時的時代，能夠實現(xiàn)打包工具和 no bundle 服務么？

還真不一定，因為打包工具的實現(xiàn)是基于模塊規(guī)范的，很早的時候并沒有，所以只能簡單的對編譯流程做下組織。更不用說 no bundle 還要瀏覽器支持 es module 了，這個也是近幾年才可以的。

所以，不管是任務運行器、打包工具、no bundle 服務都是在當時的環(huán)境下的最優(yōu)的解決方案，并不是說被淘汰的就是不好的。

上面我們只聊了構建，那前端工程化就等于構建么？

肯定不是呀，還有很多別的方面，比如代碼的規(guī)范和靜態(tài)分析：

• JS 代碼會用 ESLint 來禁止掉一些寫法，比如 concole、debugger 的使用，還可以修復格式問題，比如縮進方式，還能檢查出一些邏輯錯誤，比如 if 中用了賦值。
• CSS 代碼也同樣會用 StyleLint 來禁用一些寫法，修復格式問題，檢查出一些邏輯錯誤。
• ESLint、StyleLint 只是局部的格式修復，我們還可以用 prettier 來進行整體的格式化。
• 如果我們用了 TypeScript，那就可以用 tsc 來進行類型檢查，發(fā)現(xiàn)代碼中潛在的類型不匹配的錯誤。

靜態(tài)分析工具、格式化工具并不影響構建，他們一般是單獨來跑的，用來發(fā)現(xiàn)一些代碼潛在的問題，規(guī)范代碼格式等。

代碼寫完之后，會上傳到代碼倉庫，比如 gitlab，代碼托管也是工程化的一部分。

代碼上線的話，需要進行構建和部署，我們可以通過 jenkins 來組織構建流程，當 gitlab 代碼有新的 push 的時候觸發(fā)，進行構建，然后把產物部署到服務器，基于 git hook 的構建部署流程就叫做持續(xù)集成、持續(xù)部署（CI/CD）。這也是前端工程化的一部分。

好像很多東西都屬于前端工程化，那怎么給前端工程化下個定義呢？

前面聊了構建、靜態(tài)分析、格式化、代碼托管、CI/CD，不知道大家有沒有發(fā)現(xiàn)這些工具的共同特點：

他們的處理對象都是代碼。

他們只是把代碼當作字符串來處理，并不管你用的是 vue、react 還是 angular，你用的啥狀態(tài)管理庫、動畫庫之類的。

所以說，前端工程化就是處理代碼的一系列工具鏈，他們并不會運行代碼，只是把代碼作為字符串來進行一系列處理。編譯構建、ci/cd、代碼托管、靜態(tài)分析、格式化等都是。

不知道大家是否理解了。我們來看兩個例子：

我們項目用了 react，公共組件比較多，所以封裝了 react 的組件庫。這屬于前端工程化么？

不屬于。前端框架還有組件都是運行時才有的，工程化并不會運行代碼，只會處理代碼。所以組件庫屬于前端基建，但不屬于前端工程化。

我們好幾個項目之間公共代碼比較多，所以改造成了 monorepo 的形式，也就是一個工程下保存了多個項目的代碼，使用了 pnpm workspace 來作為 monorepo 的管理工具，可以自動的進行依賴的關聯(lián)，統(tǒng)一的進行依賴安裝、構建、發(fā)版等。這屬于前端工程化么？

屬于。monorepo 是組織代碼的方式，pnpm workspace 是管理 monorepo 的工具，它也是處理代碼的工具，不會運行代碼，所以也屬于前端工程化的范疇。

我們公司自研了 IDE，集成了很多內部工具，這屬于前端工程化么？

屬于。IDE 是圍繞代碼編輯的場景來打造一系列工具鏈，也是處理代碼但不會運行代碼，所以屬于前端工程化的范疇。

經過這些例子，相信大家對什么是前端工程化，哪些技術屬于前端工程化就比較清晰了。

我們是前端工程師，所以經常談的是前端的工程化，其實別的語言也有工程化，比如 java 代碼，同樣需要構建、格式化、靜態(tài)分析、CI/CD，所以也有工程化的概念。

其實大公司都會有一個工程效能部門，他們做的就是工程化的事情，不過一般是跨語言的工程化，并不局限于前端工程化、后端工程化等。

總結

前端工程化是指圍繞代碼處理的一系列工具鏈，他們把代碼當作字符串處理，并不運行代碼，包括編譯構建、靜態(tài)分析、格式化、CI/CD 等等。

我們詳細了解了編譯構建的歷史，從任務運行器、打包工具到 no bundle 服務的演變歷史，他們都是特定時代下的產物。

再就是靜態(tài)分析和格式化用的 eslint、stylelint、prettier、tsc 等工具。

前端工程化的范圍可以很大，可以囊括很多工具進來，比如 monorepo、IDE 等等，因為在不同的場景下對代碼處理，也就是工程化有不同的需求。

當你對前端工程化有了清晰的定義之后，對于前端工程化要做哪些事情，哪些技術屬于前端工程化、哪些不屬于，就很容易理清了。