本文來源於我在InfoQ中文站翻譯的文章。原文地址是：http://www.infoq.com/cn/news/2016/02/gulp-grunt-npm-scripts-part1
Cory House是“Building Applications with React and Flux”與“Clean Code: Writing Code for Humans”的作者。同一時候也是Pluralsight上眾多課程的講師。他是VinSolutions的軟體架構師。在全球培訓了為數眾多的軟體開發人員，主要領域是前端開發與整潔程式碼等軟體開發實踐。
Cory是微軟MVP、Telerik開發人員專家，同一時候也是outlierdeveloper.com的創始人。眼下。環繞著Gulp、Grunt及npm scripts社群展開了非常多爭論，討論Gulp與Grunt在專案中是否還有繼續使用的必要。有人堅持覺得Gulp與Grunt等前端構建工具依舊是不可或缺的，還有些人則覺得Gulp與Grunt是全然不是必需使用的，並且還新增了一層抽象，會導致非常多問題。近日，Cory撰文談到了他對於Gulp、Grunt與npm scripts的認識。並且覺得在如今的project中，我們全然能夠拋棄Gulp與Grunt，使用npm scripts就能夠滿足專案之所需。
眾所周知，Gulp與Grunt是非常多專案所使用的構建工具，他們也擁有非常豐富的外掛。
只是。我卻覺得Gulp與Grunt是全然不必要的抽象，npm scripts更加強大。並且更易於使用。
我本人是Gulp的粉絲。只是在上一個專案中，gulpfile居然有100多行。並且還使用了不少Gulp外掛。我嘗試通過Gulp整合Webpack、Browsersync、熱載入、Mocha等工具，為什麼要這麼做呢？這是由於有些外掛的文件實在是太不充分了；還有些外掛僅僅公開了我所需的部分API。當中有個外掛存在一個奇怪的Bug。它僅僅能看到檔案的部分內容。
還有一個外掛則在輸出到命令列時丟失了顏色。
當然了，這些問題都是能夠解決的；只是，當我直接使用這些工具時，全部問題都不復存在了。近期，我注意到有非常多開源專案僅僅是使用了npm scripts。因此，我決定又一次審視一下自己的做法。我真的須要Gulp麼？答案就是：全然不須要。
我決定在我新的開源專案中僅僅使用npm scripts。
我僅僅使用npm scripts為一個React應用搭建了開發環境與構建流程。想知道這個專案是什麼樣子的麼？看一下React Slingshot吧。如今，相對於Gulp來說。我更傾向於使用npm scripts，以下就來談談原因。
Gulp與Grunt怎麼了？
隨著時間的流逝，我發現諸如Gulp與Grunt等任務執行器都存在以下3個核心問題：
- 對外掛作者的依賴
- 令人沮喪的除錯
- 脫節的文件
以下就來具體分析上述3個問題。
問題1：對外掛作者的依賴
在使用比較新或是不那麼流行的技術時，可能根本就沒有外掛。
當有外掛可用時，外掛可能已經過時了。
比方說，Babel 6前一陣公佈了。其API變化非常大，這樣非常多Gulp外掛都無法相容於最新的版本號。
在使用Gulp時，我就感到深深的受傷，由於我所須要的Gulp外掛還沒有更新。在使用Gulp或是Grunt時。你不得不等待外掛維護者提供更新，或是自己修復。
這會阻礙你使用最新版現代化工具的機會。與之相反。在使用npm scripts時。我會直接使用工具，不必再加入一個額外的抽象層。這意味著當新版本號的Mocha、Istanbul、Babel、Webpack、Browserify等公佈時，我能夠立馬就使用上新的版本號。
對於選擇來說。沒有什麼能夠打敗npm：
圖從上圖能夠看到，Gulp有將近2,100個外掛；Grunt有將近5,400個。而npm則提供了227,000多個包。同一時候還以每天400多個的速度在持續新增。
在使用npm scripts時，你無需再搜尋Grunt或是Gulp外掛；僅僅需從227,000多個npm包中選擇即可了。公平地說，假設所須要的Grunt或是Gulp外掛不存在，你當然能夠直接使用npm packages。
只是。這樣就無法再針對這個特定的任務使用Gulp或是Grunt了。
問題2：令人沮喪的除錯
假設整合失敗了，那麼在Grunt和Gulp中除錯是一件令人沮喪的事情。由於你面對的是一個額外的抽象層，對於不論什麼Bug來說都有可能存在很多其它潛在的原因：
- 基礎工具出問題了麼？
- Grunt/Gulp外掛出問題了麼？
- 配置出問題了麼？
- 使用的版本號是不是不相容？
使用npm scripts能夠消除上面的第2點，我發現第3點也非常少會出現，由於我通常都是直接呼叫工具的命令列介面。
最後。第4點也非常少出現，由於我通過直接使用npm而不是任務執行器的抽象降低了專案中包的數量。
問題3：脫節的文件
一般來說。我所須要的核心工具的文件質量總是要比與之相關的Grunt和Gulp外掛的好。比方說。假設使用了gulp-eslint。那麼我就要在gulp-eslint文件與ESLint站點之間來回切換。不得不在外掛與外掛所抽象的工具之間來回切換上下文。Gulp與Grunt的問題在於：光理解所用的工具是遠遠不夠的。
Gulp與Grunt要求你還得理解外掛的抽象。
大多數構建相關的工具都提供了清晰、強大，且具有高質量文件的命令列介面。
ESLint的CLI文件就是個非常好的樣例。
我發如今npm scripts中閱讀並實現一個簡短的命令列呼叫會更加輕鬆，阻礙更少。也更易於除錯（由於並沒有抽象層存在）。既然已經知道了痛點，接下來的問題就在於，為何我們覺得自己還須要諸如Gulp與Grunt之類的任務執行器呢？
我相信個中原因應該是因人而異的。毫無疑問。Gulp與Grunt等任務執行器已經出現非常長一段時間了。並且環繞著這些任務執行器的外掛生態圈也呈現出欣欣向榮的繁榮景象。依賴於這些外掛，非常多日常工作都能夠實現自己主動化。並且執行良好。這樣，人們就會覺得僅僅有通過這些任務執行器才幹實現任務的構建、檔案的打包、工作流的良好執行等等。
另外一個原因就是人們對於npm scripts的認識還遠遠不夠。對於npm scripts所能完畢的事情與任務也流於表面。
這也進一步造成了非常多人並沒有發現npm scripts能夠實現非常多日常開發時的構建任務的結果。我相信隨著開發人員對於npm scripts認識的進一步深入。大家會逐步發現原來使用npm scripts也能夠完畢Gulp與Grunt等任務執行器所能完畢的任務，並且配置更加簡單，也更加直接，由於它會直接使用目標工具而不必再使用對目標工具的包裝器了。
在本系列的下一篇文章中，我們就來看看npm scripts為人所忽視的原因，以及使用npm scripts能夠完畢哪些事情。