Gulp構建流程的缺陷

接觸Gulp幾個月了，對這款構建工具也愈來愈熟悉。因而逐漸發現了它的一些問題。

場景

設想如下常見場景，有以下三個task：

• build：用於編譯Sass

• compress：用於壓縮CSS

• release：執行build和compress，編譯Sass並壓縮CSS

這個場景十分常見，在開發環境下經過build生成用戶CSS進行調試，而在生產環境下則須要執行release。

問題

衆所周知gulp.run接口已經棄用，官方API只剩下gulp.src，gulp.dest，gulp.task，gulp.watch四個。task的啓動只能經過命令行或者gulp.watch觸發。

幸運的是，嘗試一下就會發現gulp.start也是能夠用於啓動task的。那麼如上場景中的release應該寫成：

gulp.task('release', function() {
    gulp.start(['build', 'compress']);
}

可是這樣寫明顯是有問題的。因爲gulp.start並不是順次同步啓動列表中的task，設想當build耗時較長時，實際執行順序可能將會是：

Starting 'release'...
Starting 'build'...
Starting 'compress'...
Finishing 'build'...
Finishing 'compress'...
Finishing 'release'...

這樣形成的問題是，compress讀取的CSS文件並不是最新編譯生成的版本，所以壓縮所得的min.css文件並非咱們想要的。

要解決這個問題，就必需要build完成後才啓動compress，所以有以下寫法：

gulp.task('release', ['build'], function() {
    gulp.start(['compress']);
}

這樣確實可以避免上述的問題，可是很明顯語義上並不符合邏輯：

Starting 'build'...
Finishing 'build'...
Starting 'release'...
Starting 'compress'...
Finishing 'compress'...
Finishing 'release'...

咱們想要的難道不該該是這樣嗎：

Starting 'release'...
Starting 'build'...
Finishing 'build'...
Starting 'compress'...
Finishing 'compress'...
Finishing 'release'...

爲了實現這個順序，只有一種寫法：

gulp.task('compress', ['build'], function () {
    // compress
});
gulp.task('release', function () {
    gulp.start(['compress']);
});

這樣看起來就更奇怪了…compress毫不應是依賴於build的，而release也毫不應是start compress。

而就Gulp目前的語法來看，並無什麼好的解決辦法。

總結

總的來講，Gulp目前的語法並不能很好的支持語義化的構建流程。我所但願的最好的解決方法是gulp.start可以支持同步任務。