node.js中watch機制詳解_node.js

幾乎所有構建系統都選擇使用watch機制來解決開發過程中需要反覆產生構建後檔案的問題，但在watch機制下，長期以來我們必須忍受修改完代碼，儲存完代碼必須喝口茶才能重新整理看看效果的問題。在這裡我們嘗試探討為什麼watch不是銀彈，並嘗試尋找一種更好的方案來解決這個問題。

watch基於的事實

當一個檔案修改，我們能知道其修改可能導致的檔案修改，那麼重新構建這些檔案即可。

通常對於檔案A，構建成檔案B這種情境，這種對應關係是極好確定的。但現實情境下，構建過程往往不是那麼簡單。例如：

檔案A ＋ 檔案B（被檔案A引用） －> 檔案C
在這種情境下，檔案B的修改，可能難以定位哪些檔案需要重新跑構建任務，因為可能有很多檔案引用了檔案B。

除非我們建立一個依賴樹，並在每次檔案更新的情況下更新依賴樹，並根據新的依賴樹觸發檔案構建。但這對每一個外掛程式都需要自行實現這個機制，並且極易出錯。故實際上watch機制僅僅是重跑了整個task。所以當項目越來越大的時候，watch機制將越來越慢（因為越來越多檔案需要重新跑整個過程，即使通過緩衝減少了整個過程所需的耗時）。

解決方案

src直接可用

AlloyTeam & @ldjking，簡單來說直接讓src直接可跑，把構建任務放置在瀏覽器端，甚至根本不構建，既可做到及時修改及時重新整理，在開發過程中減少了時間消耗。線下構建僅僅負責效能最佳化上的問題，不負責開發效率。
典型代表有LESS、React等。但也有一些問題：

難以在瀏覽器端實現優雅的構建方式，難以提供強大的功能進一步減少開發成本，大部分只能採用類似<style type="text/less"></style>的方式引入指令碼。
開發模式下的執行順序不一定和實際情境相同，可能導致隱形bug出現，例如實現一個HTML inline由於開發模式下inline是非同步，而發布模式下inline時同步的，產生莫名其妙的bug。
瀏覽器編譯效能堪憂，例如js版的sass，編譯速度幾乎無法忍受。
需要維護線上、線下兩套構建系統，增加了工具開發成本。
本機伺服器動態構建

一個事實是：在合理的規範支援下，我們可以從瀏覽器請求的檔案，回溯到該檔案構建過程中的入口檔案。這樣我們就可以動態觸發一次構建過程。

通過在本地建立一個伺服器，讓伺服器捕獲請求後，在伺服器中動態構建。只要回溯到入口檔案，我們便能將入口檔案丟進gulp外掛程式組成的管道中，則輸出便是瀏覽器需要的檔案。

這樣我們就能解決上面的所有問題。