我為何放棄Gulp與Grunt，轉投npm scripts（上）

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的認識，并且認為在現在的工程中，我們完全可以拋棄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能夠完成哪些事情。