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

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

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

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

什么是前端工程化

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

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

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

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

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

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

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

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

那肯定有區別呀，現在有了模塊之間的依賴圖了，那就可以做一些全局的優化：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

肯定不是呀，還有很多別的方面，比如代碼的規范和靜態分析：

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

靜態分析工具、格式化工具并不影響構建，他們一般是單獨來跑的，用來發現一些代碼潛在的問題，規范代碼格式等。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

總結

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

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

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

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

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