當(dāng)我們開始一個(gè)新的 JavaScript 項(xiàng)目時(shí)，我們需要考慮的第一件事就是搭建一個(gè)前端編譯環(huán)境。但是在面對(duì)眾多的 JavaScript 構(gòu)建工具時(shí)，我們卻無所適從，不知道究竟哪一個(gè)才是最適合我們的。

想象一下，如果有一個(gè)很簡(jiǎn)單的判斷標(biāo)準(zhǔn)，讓你知道如何針對(duì)不同的項(xiàng)目，選取不同的前端構(gòu)建工具，那是不是很美好呢？事實(shí)上，在使用自動(dòng)構(gòu)建系統(tǒng)，積累了5年的項(xiàng)目開發(fā)經(jīng)驗(yàn)之后，我總結(jié)出來如下內(nèi)容。相信我，它是可以讓你明白不同構(gòu)建工具的使用場(chǎng)景的。

開門見山

判斷你的項(xiàng)目需要使用哪種構(gòu)建工具是很容易的：

• 如果是小項(xiàng)目的話，基于 ES6 編譯器即可
• 如果是單頁應(yīng)用的話，還需要一個(gè)模塊打包器
• 如果你的項(xiàng)目，部署在了生產(chǎn)環(huán)境之中，除了上述之外，還需要一個(gè)能夠自動(dòng)執(zhí)行的任務(wù)運(yùn)行器

下面是我推薦的一些可以滿足你上述需求的前端構(gòu)建工具：

• 使用 Babel 可以編譯適配 ES6 代碼
• 使用 Webpack 能夠打包 JavaScript 文件以及其相關(guān)的依賴
• 使用 Gulp 能夠自動(dòng)化地將文件批量重命名，從而刷新靜態(tài)資源文件的緩存

那么，問題來了，前端構(gòu)建工具那么多，為什么我偏偏推薦上述的這些呢？

追根溯源

我對(duì)很多流行的 JavaScript 構(gòu)建工具進(jìn)行了分析，并分別找出了它們的優(yōu)點(diǎn)與缺點(diǎn)。既然編譯器是無論如何都需要的，那么我們就從編譯器開始說起吧。

編譯器

ES5 版的 JavaScript 并不是那么優(yōu)雅。盡管 ES6 與 ES7 有了非常大的提升，但是目前的瀏覽器并不支持 ES6 與 ES7。

幸運(yùn)的是，有很多工程師打造了能夠?qū)?code>新的 JavaScript 代碼轉(zhuǎn)換成瀏覽器支持的 JavaScript 代碼的工具，有的甚至還在此基礎(chǔ)上，加入了新的特性與功能 — 例如微軟的 TypeScript 。但是如果我們要在眾多的 JavaScript 編譯器中，選取一個(gè)最接近 JavaScript 官方代碼風(fēng)格的，那么Babel無疑是最優(yōu)秀的。

Babel

在閱讀完這篇文章之后，如果你必須要學(xué)著使用一款工具，那么這款工具肯定就是 Babel 了

Babel的功能并不會(huì)讓你大吃一驚，正如你所期待的那樣，它主要是將 ES6 代碼轉(zhuǎn)換成瀏覽器所支持的 ES5 代碼而已。還有一點(diǎn)就是它允許你在 Babel 已擁有的轉(zhuǎn)換器基礎(chǔ)之上，定制屬于你自己的轉(zhuǎn)換器——欣喜的是，Babel的社區(qū)在轉(zhuǎn)換器方面，已經(jīng)為我們提供了很多。此外，它還能夠?qū)?ES7 的特性進(jìn)行轉(zhuǎn)換，例如 async / await 以及 decorators。同時(shí)，它也提供了對(duì) React JSX 的支持。

盡管 Babel 在轉(zhuǎn)換 JavaScript 代碼方面做得足夠優(yōu)秀，但是除此之外，它不能幫我們做任何事情。事實(shí)上，它甚至不能通過ES6 的 import 和export的表達(dá)式，將我們的多個(gè)文件進(jìn)行合并。這也是為什么我們接下來需要一個(gè)模塊打包器了。

模塊打包器

大多數(shù)的項(xiàng)目，無論規(guī)模多大，程序員都習(xí)慣于將代碼拆分到多個(gè)文件之中。盡管你可以使用 script 標(biāo)簽，來一個(gè)個(gè)地引入這些單獨(dú)的js文件，但是你終究還是需要基于不同文件的依賴關(guān)系來決定它們引入的先后順序的。在這件事情上，工具能夠比你做得更好，這也就是為什么你需要使用模塊打包器，來將一些文件自動(dòng)化地打包進(jìn)一個(gè)單獨(dú)的文件的原因。

盡管我們可以從網(wǎng)上找到很多的模塊打包器，但是只有兩款是最具代表性的：Browserify 與 Webpack

Browserify

Browserify 可以使得 Node packages 獲得瀏覽器的支持。當(dāng)然，它也可以幫助我們將 Web 應(yīng)用打包成一個(gè) Node Packages。

這種以 Node 為中心的哲學(xué)，有很多的好處。使用 Browserify 來打包一個(gè)應(yīng)用是非常容易的。你可以使用 Node 內(nèi)置的模塊，例如 path ，也可以引用你之前在Node項(xiàng)目中寫過的任何代碼。當(dāng)然，缺點(diǎn)就是，你的單頁應(yīng)用通常需要的資源，正好是 Node 項(xiàng)目不需要的，例如 CSS 、圖片以及字體。

盡管存在這種問題，但是這種問題也并不是不能解決的。許多人已經(jīng)寫了插件來使得 Browserify 可以打包這些資源。這些插件可以使你能夠轉(zhuǎn)換 ES6 到 ES5 、打包 CSS、分離你的代碼到多個(gè)文件之中等等。但是考慮到這些插件違背了 Browserify 這一工具的設(shè)計(jì)初衷，它的配置將會(huì)比較混亂。

因此，盡管 Browserify 是一款能夠優(yōu)雅地將 Node Packages 打包成瀏覽器支持形式的工具，但是如果你寫的是一個(gè)單頁應(yīng)用，那么你最好選擇一款專門用于打包、并且能夠打包所有資源文件的模塊打包器。

Webpack

Webpack 是一款能夠?qū)⒃S多的 JavaScript 模塊以及它的相關(guān)依賴打包進(jìn)一個(gè)單獨(dú)文件的工具。它并不需要你給出這些模塊的依賴具體是哪些，只要它能夠打包成 JavaScript 模塊即可。

只要它能夠打包成 JavaScript 模塊即可？這意味著它不支持 CSS 和圖片，是嗎？當(dāng)然不是，Webpack 是可以通過各種 loaders 來將各種資源文件都轉(zhuǎn)換成 JavaScript 模塊的神器。

Loaders 是一種能夠處理不同資源文件的轉(zhuǎn)換器。它們能夠接收任何形式的資源文件，也能輸出任何形式的資源文件，而不僅僅是 JavaScript 。而且，這種操作也是可以鏈?zhǔn)降模试S你先將 SCSS 文件轉(zhuǎn)換為 CSS，然后再將CSS 轉(zhuǎn)換為 JavaScript 模塊。然后，Webpack 再對(duì)這些 JavaScript 模塊統(tǒng)一打包！

如果非要說 Webpack 有什么缺點(diǎn)的話，那就是許多流行的案例項(xiàng)目都包含了令開發(fā)人員感到害怕的 Webpack 復(fù)雜的配置文件。如果你按照我的 configuring Webpack with Babel in 26 lines 教程來做的話，你就會(huì)發(fā)現(xiàn)解決這種問題是如此的 so easy。

經(jīng)過上述的分析，現(xiàn)在你應(yīng)該知道怎樣使用模塊打包器來生成一系列的靜態(tài)資源文件了。但是有了這些文件之后，我們?cè)撛趺醋瞿兀窟@就是該任務(wù)運(yùn)行器發(fā)揮作用的時(shí)候了。

任務(wù)運(yùn)行器

任務(wù)運(yùn)行器是用來定義并運(yùn)行任務(wù)的工具。簡(jiǎn)言之，任何你可能在命令行上執(zhí)行的操作，都可以通過任務(wù)運(yùn)行器來完成。

在使用任務(wù)運(yùn)行器之前，理解這句話是非常重要的：不要為了編寫任務(wù)而編寫任務(wù)。也就是說，如果你自己編寫一個(gè)任務(wù)來進(jìn)行模塊打包，這也是可以的。但是如果你把這件事情交給Webpack去做的話，你只需要啟動(dòng)一下 Webpack 就好了，我們完全沒有必要重復(fù)造輪子。

編寫一些你的模塊打包器不能處理的任務(wù)才是有必要的，例如為模塊打包器自動(dòng)生成的靜態(tài)資源文件在網(wǎng)頁中插入一個(gè) script 標(biāo)簽。

Grunt

Grunt 是一個(gè)運(yùn)行你先前定義過的任務(wù)的工具。也就是說，如果你不定義任務(wù)，基本上 Grunt 不能為你做任何事情。

原因就在于，Grunt 的任務(wù)并不是使用 JavaScript 的代碼來定義，而是通過一系列的配置對(duì)象來進(jìn)行聲明式的定義的。為了保持 Grunt 核心包的大小，它的所有配置對(duì)象都是插件化的 — 從監(jiān)控文件變化到復(fù)制、串聯(lián)文件。

這種做法也是有它的優(yōu)勢(shì)的。Grunt 有成千上萬的插件，基本上你不需要編寫任何代碼，針對(duì)不同的需求，選取其一，直接拿來用即可。它最大的問題其實(shí)在于，如果你感覺確實(shí)有必要對(duì)插件運(yùn)行的效果做一些微調(diào)的話，通過編寫純 JavaScript 代碼是沒法實(shí)現(xiàn)的，你必須要為此重新編寫一個(gè) Grunt 插件了。

Gulp

Gulp，類似 Grunt ，也是一個(gè)用來定義并運(yùn)行任務(wù)的工具。

Grunt 與Gulp 最大的不同就在于 Grunt 使用配置對(duì)象來聲明任務(wù)的運(yùn)行方式，而 Gulp 則使用 JavaScript 的函數(shù)來定義任務(wù)。也正是由于 Gulp 知道如何處理 JavaScript 返回的 streams 或者 promises ，這使得你在編寫任務(wù)的時(shí)候具備很大的靈活性。

Gulp 與 Grunt 一樣，也擁有非常豐富的插件庫(kù)。不過考慮到 Gulp 的插件提供的都是一些原始基礎(chǔ)的功能，你也可以引用 Node 模塊來豐富完善你的 Gulp 任務(wù)體系。

Gulp 最大的問題在于 streams 與 promises 的對(duì)接對(duì)新手來說可能是比較困難的。但是這也是一個(gè)雙刃劍，隨著實(shí)踐經(jīng)驗(yàn)的積累，你就能夠體會(huì)到 streams 與 promises 的好處了。

譯自：James K Nelson, http://jamesknelson.com/which-build-system-should-i-use-for-my-javascript-app/

總結(jié)

以上是生活随笔為你收集整理的如何选择JavaScript构建工具之Babel、Browserify、Webpack、Grunt以及Gulp的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。