幾乎所有構建系統都選擇使用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插件組成的管道中，則輸出便是瀏覽器需要的文件。

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

總結

以上是生活随笔為你收集整理的为什么watch机制不是银弹？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。