在前端項目的規模和複雜性不斷提升的情況下，各類構建思想和相應工具層出不窮。本文竭己所能對比了當下13個構建工具，包括 Browserify、 Webpack、 Rollup、 Grunt、 Gulp和 Yeoman6個廣為流行的工具， FIS、 Athena、 WeFlow和 Cooking等4個國產工具，以及三大框架： React， Vue和 Angular的官方腳手架。希望能在項目初期的構建工具選型上為大家提供些參考。
全覽
構建工具可以分為三類：模塊化打包類、任務流構建類和集合型工具類（腳手架）。其中最為突出的，當屬用於模塊化打包的 Webpack和用於任務流構建的 Gulp。下面是截至2018年11月28日某時某刻， GitHub上各個工具的 Star數目（聽說 Star數目可以造假？好生無聊的傢伙們！）。
前端的構建一般包括JS轉碼（使用 Babel轉 ES6或 TypeScript自轉等）、CSS轉碼（ Less或 Sass轉 Css）、代碼或資源的合併與壓縮，基礎檢查和各類測試等等。這些雖與本文關係密切，但都不在討論的範圍之內。原因有二：一是實現這些功能的都是某些插件，不是工具本身，各類構建工具都是直接或間接（調用以自己的模式封裝後的插件）使用它們的；二是本文介紹的是，構建方向上的類別和各類別裡不同工具間的差異，與具體的操作無關。
模塊化打包類
現在的前端項目基本是模塊化的，原因就不在這多說。而模塊化意味著分散，無法直接用於呈現，因此需要進行相應的打包形成一個整體。有些執行環境（ Node）能自動打包各個模塊，而有些（瀏覽器）則因為技術或其它考慮需要自行操作。模塊化打包工具就是為模塊化項目在瀏覽器上的優化呈現而服務的。
模塊化打包的核心是：找出依賴，打包成體。各類工具的基本運行思路便是根據已有配置，從某個文件開始，遞歸的找出所有與其相關的依賴模塊，打包成某種類型的可直接在瀏覽器中運行的一個或多個新文件。這之中還可以優化輸出，以實現代碼分離、異步加載和長效緩存等高級功能。
Browserify
官網：https://github.com/browserify/browserify
正如其官網介紹的， Browserify會遞歸的分析，項目中所有使用 require引入的JS模塊（包括 Node內置模塊）並打包，使得 Node類項目能在瀏覽器上運行。不過對於與項目有關的其它資源，比如 Css和圖片等，依然需要手動管理。雖然網上已有人編寫了支持此些功能的插件，但這不僅違背了設計初衷，也使配置變得雜亂。而且對於要求越來越高的單頁面應用來說，它能提供的助力著實已顯疲憊。
Webpack
官網 | 中文 | https://github.com/webpack/webpack
穩定版已到 v4.26.0，本文以此版本為據。另附加官方的對比文檔https://webpack.docschina.org/comparison。
Webpack的設計思想新穎實用，社區活躍，功能強大全面，已經是針對前端各類資源的、目前最優秀的模塊化管理和打包工具。它入門簡單，基本的常用功能能很快上手，並用於實際開發。但精通不易，畢竟打包已是 web開發中最重要的挑戰之一，必然要耗費些許精力。學習尚且不易，介紹就更為困難，得要有一本書的厚度。所幸此節不是詳細介紹，只是亮點闡述，善哉善哉。
入門已趨簡單
掌握了構建的基本思路，任意工具的入門都是較為簡單的（讀者批：廢話）。之所以強調 Webpack入門簡單，是為了減輕有意者學習之前的顧慮。一方面是它剛被推出時，由於自身的概念新穎而且文檔不全面，使開發者處於懵懵懂懂的狀態，總感覺離真諦還差些距離。另一方面是它的體系著實龐大，仔細想想都不免膽怯。筆者初次接觸時便是這些個感受。
但現在不一樣。吃土的日子已經遠去，啃草的夢想還會遠嗎？大家準備好鐮刀！
Webpack第四版在入門上的方便性體現在三方面。一是基礎功能高度集成和約定優於配置思想：安裝好 Webpack及其 CLI後便可直接打包 JS和 JSON文件，與 Browserify一樣簡單。二是官方文檔詳細（而且有基本同步的中文版），無論是概念的解析、實際運用的示例還是接口的展示都十分完備。三是現在使用和介紹 Webpack的人已經很多了，因此網上的各路資料和相應問題的解決方案都十分豐富。你還在猶豫？
一切皆模塊
如從官網上截取的圖片所示，在 Webapck眼中一切文件（ .js、 .css、 .jpg、 .woff、 .csv和 .ts等除了某些用於下載的靜態大文件外）都是模塊，都能通過與 JS相似的方式被打包，並安置於合適瀏覽器渲染的位置。真是十分優秀的立足點。以此思想便可囊括前端會使用到的幾乎所有資源，可以十分方便的統一管理和安置，更為便捷和高效。
而且此思想就是為單頁面應用而生的。在 Webpack的另一層意境中，一個 asset（各類資源）是一個模塊，一個 component是一個模塊，一個 module也是一個模塊。而單頁面應用的特點，不就是應用的更新不是整個頁面的更新，而是某個 module或 component或 asset的更新嗎？十分的契合。
有人說 Webpack的缺點在服務端渲染（或說多頁面應用）上。喂喂，一來別人的目標本就不在此，二是多頁面應用也不需要如此複雜的支持體系。
高效的構建性能
單頁面應用或說需要構建才能展示的應用，相比多頁面應用，從每次修改到重新呈現要多經歷一個構建的階段。實際操作中，如果項目龐大而構建性能不夠優化，一個小小的修改（打印某值）都會消耗5秒以上的時間，對開發者來說真是個地獄！而優化的方法不外乎兩點，一是開發者優化項目的構建思路，二是構建工具優化自身的構建性能。
Webpack擁有較理想的構建性能。在開發階段，當開啟了 Webpack的模塊熱替換之後（使用 webpack-dev-server會自動開啟），一旦檢測到文件被修改，會在應用程序運行過程中通過冒泡捕獲的方式最小化替換、添加或刪除模塊，而無需重新加載整個頁面。類似 Dom渲染中的迴流：如果子元素髮生的大小變化，會影響兄弟元素但不影響父元素，那麼父元素及其它是無需重新繪製的。而且即便完全重新構建，也會保留先前的應用程序狀態，減少等待時間。
活躍的社區
活躍的社區可以提升系統的豐富度，降低學習與使用的成本。
Webapck社區十分活躍，應用於各種需求的插件都被一一封裝而可直接使用（官方也統一展示和說明了一些常用的優秀的 Loader和 Plugin）。不單單是其它工具的高度協調，開發中的各個階段：搭建本地服務器、集成測試等，以及與任務流工具（ Gulp、 Grunt）的集成等等方面的解決或最優方案，都是豐富和全面的。基本上可以想到的需求，在這個社區中，都能直接借鑑他人已有的成果。
Rollup
官網 | 中文 | https://github.com/rollup/rollup
Rollup定位為一個 JS模塊打包器（明指 JS），主要用來構建 JS庫，也可服務於一些無需代碼拆分和動態導入的小型應用程序。能在 Webpack已穩居打包之首的情況下殺出一條血路，得到 Vue、 D3、 Three和 React等著名庫的青睞，想必其著手點和性能有過人之處。
Rollup本身結構簡單，需要的配置項也不多，再加文檔全面，所以很容易上手並全部掌握。它使用 ES6本身的 Module語法作為自己的標準，而不是諸如 CommonJS和 AMD等以前的解決方案。這意味著按照 Module標準編成的代碼，不僅現在可以藉助 Rollup打包運行，未來更能在實現此標準的瀏覽器上直接運行。
通過 Module的特性， Rollup開創了 Tree-shaking功能——清除沒有在項目中使用到的代碼。它基於顯式的 import和 export語句的方式，通過靜態分析，排除了任何未在實際中使用的代碼，能極大的減少構建於已有模塊的項目體積。再加上其構建基本不添加自身的控制代碼，使打包後的文件真正的達到純淨二字。想想還有點癢癢，我撓撓襠部。
與 Webpack 對比
Rollup和 Webpack因其定位和專注點是可以共同存在並相互支持的。
正如 Rollup官網所說的， Rollup更適合構建獨立的 JS庫，而 Webpack為資源豐富的應用程序。雖然 Webpack也增加了自己的 Tree-shaking功能，但在編譯後的輸出代碼中，簡單地運行自動 minifier檢測未使用的變量，得到的結果是不如原生的靜態分析。更何況 Webpack生成的代碼一定是經過自己包裝後的代碼——將每個模塊封裝在一個函數中，再置於一個包中，通過瀏覽器能使用的 require方式逐一執行這些模塊。
任務流構建類
基於任務的構建行為，是不在乎操作對象是否為模塊化的。
這類工具的目標是通過配置來解放日常需要重複的工作——轉化、合併壓縮和單元測試等等。有人說：這些操作 Webpack和 Rollup不是也能做？是的，基本能做。實際上，在用模塊化構建工具的開發中，很少會用到任務流構建工具。但這絕不是說任務流工具會被取代，也不會被取代，至少多頁面應用需要。再說任務流工具是十分純粹的自動化行為，與模塊化打包工具立足點就不一樣，何談取代一說。
Grunt
官網 | 中文 |https://github.com/gruntjs/grunt
Grunt雖是老牌構建工具，但依然被許多知名項目如 WordPress、 Twitter和 Jquery等使用，也擁有持續更新的完整生態圈和中文文檔。它是通過配置驅動——通過獲取到的 JSON配置執行操作，來流水線式執行相應任務。雖然在學習成本和執行效率上不出眾，但如果項目原本就是通過它自動化構建的，是沒有必要遷移到其它工具的。
- // Grunt 的配置驅動示例
- module.exports =
- function
- (grunt) {
- grunt.initConfig({
- jshint: {
- files: [
- 'Gruntfile.js'
- ,
- 'src/**/*.js'
- ,
- 'test/**/*.js'
- ],
- options: {
- globals: {
- jQuery:
- true
- }
- }
- },
- watch: {
- files: [
- ''
- ],
- tasks: [
- 'jshint'
- ]
- }
- });
- grunt.loadNpmTasks(
- 'grunt-contrib-jshint'
- );
- grunt.loadNpmTasks(
- 'grunt-contrib-watch'
- );
- grunt.registerTask(
- 'default'
- , [
- 'jshint'
- ]);
- };
Gulp
官網 | 中文 | https://github.com/gulpjs/gulp
Gulp是新型的構建工具，雖與 Grunt的功能相同，但其構建過程卻有三大優勢。
代碼驅動
代碼驅動即通過執行實際代碼驅動程序執行，與常見的配置驅動不同（ Webpack、 Rollup和 Grunt等都是配置驅動）。從任務流構建的角度上看，代碼驅動相比配置驅動有三點好處：一是高度的靈活；二是沒有過多的配置項，減少學習成本；三是更方便錯誤的斷定和異常情況的調試。
- // Gulp 的代碼驅動示例
- gulp.src(
- './client/templates/*.jade'
- )
- .pipe(jade())
- .pipe(gulp.dest(
- './build/templates'
- ))
- .pipe(minify())
- .pipe(gulp.dest(
- './build/minified_templates'
- ));
Node流
Gulp作為後來者，充分利用 NodeJS流的思想進行 IO操作，極大增加了大型項目的構建速度。比方說轉化 Scss成 Css， Grunt的操作流程是：讀取 Scss文件、轉化成 Css、存儲到磁盤，讀取 Css、壓縮處理最後存儲到磁盤；而 Gulp得操作是：讀取 Scss文件、轉化成 Css、壓縮處理最後存儲到磁盤。一步到位，無需多次的 IO操作。
簡單明瞭
Gulp有十分精簡的 API。你能想到各種類型的任務，基本是通過僅有的五個可鏈式操作的方法實現的嗎？不僅僅是學習和使用方便，編寫後的功能也是一目瞭然。雖然代碼驅動相比配置驅動，需要自己寫的代碼增加，但一是沒增加難度只是函數名的多次重寫，二是相對代碼驅動的好處來說可以忽略。
集合型工具類
集合型工具類便是常說的腳手架，也可以看作是以模塊化或任務流工具為主體的，各類常用工具的高度封裝。它是一個開箱即可用的集合體，類似前後端同構時代的後端框架。它會根據你的選擇，生成一個完整的、已配置好各類工具的、具有某些特定代碼約定的項目框架。這些配置幾乎包攬前端開發的整個流程，甚至可以集成自動化部署等後端接口。
官方框架
React CLI：https://facebook.github.io/create-react-app/Vue CLI：https://cli.vuejs.org/Angular CLI：https://cli.angular.io/集合型工具一般為單頁面應用服務，而單頁面應用需要使用某個前端框架。無論你是用 React、 Vue或 Angular，還是其它框架，首先得想到它是否有官方腳手架。比如 Vue有 VueCLI。一般推薦有官方腳手架的直接使用官方的。因為現代前端框架一般不單獨運行，需結合官方提供的其它工具，比如路由、狀態管理等。而且各個框架及配件更新不斷，每次更新都可能導致與其它插件的兼容問題，新的功能可能需要某些特定插件才能發揮作用。這是一項工程，僅靠個人或某些團體很難照顧周全的。而各個框架又都有意識的通過官方腳手架來充分展示新的特性，降低學習和使用的成本。我們何樂而不為呢？
Yeoman
官網：https://github.com/yeoman/yeoman
Yeoman是一個專為現代前端而生的、靈活通用的腳手架工具。
它的運作方式和其它腳手架不同。在安裝好 CLI後，需要找到一個符合要求的 Generator（一個 npm包，相當於腳手架），使用 Yeoman運行安裝，生成初始化的項目。你也可以自行配置，使用 Yeoman封裝成符合特定需求的 Generator，併發布出去。等到下次，其他人或你自己，需要生成符合此要求的項目時，便可以直接安裝並使用 Yeoman生成。
這樣有明顯的兩點好處：一是節省體力。在開始一個有特定需求的新項目時，如果有老項目可借鑑，一般會直接複製相關文件。但這樣的複製文件可能不純粹，即增加體積又帶來安全隱患。二是在社區的支持下，很多有特殊要求的腳手架，早已有人解決併發布成 Generator，是沒必要自己動手的。
國內其它
百度 - FIS - 官網：https://github.com/fex-team/fis3微信 - WeFlow - 官網：https://github.com/Tencent/WeFlow/京東 - Athena - 官網：https://github.com/o2team/athena餓了麼 - Cooking（名字與公司的性質相得益彰） - 官網：https://github.com/ElemeFE/cooking作為程序員或至各行各業，在與年齡增長速度相當的壓力下，工資的高低自然成為日常性的評定標準。但在同行老友的酒桌上或某個太陽異常溫煦下的小道上，能使自己為自己而不是其他事驕傲的，也肯定是“老子之前做過些什麼”之類的實際付出而不是物質方面的獲得。因此能夠成為被公司支持的、被眾多人使用的、開源框架維護團隊中的程序員，多少是更為幸福的一類。
這些由國內各個前端團隊開發的集合型腳手架，都是基於自用在實踐中得到的最為符合本身需求的產品。裡面的包含內容十分豐富，不僅僅是這以上提到的前端本職工作，還有與後端的集成方案或自動化部署配置等。且流程簡化，開箱即可使用。不過這些筆者都沒用過，也沒有打算用。不是打趣，原因很現實，有識之士可以在文章下留言。不用卻依然寫出的原因倒是簡單：宣傳，宣傳即讚許和期盼；湊數，湊到13種好立個多少浮誇的標題。
總結
個人觀點，不喜請噴，但要和藹可親。
如果是使用某個前端框架開發應用程序，推薦框架官方的腳手架。如果是自己頭腦發熱想開源個 JS庫，推薦 Rollup打包。如果不是模塊化項目，又需要自動化處理一些事情，推薦 Gulp作為構建工具。如果項目有特殊要求或作為核心的部件比較稀有，可以先查看 Yeoman上是否有符合要求的 Generator，沒有就只能自食其力。最後如果你處在已有自己腳手架的公司（比如餓了麼），可能要按規章制度使用 Cooking為自己的仕途烹煮些吃食。肚子真餓，這種宣傳餓了麼會返優惠券嗎？
最後，如果是自食其力的搭建前人沒有的腳手架，推薦使用 Yeoman發佈，方便你我他。
閱讀更多 程序弈說 的文章
