Webpack5 內建快取方案探索

隨著babel、typescript、vueloader、terser等編譯、轉譯技術的大規模使用，webpack的編譯時間正不斷膨脹。為了優化編譯速度，社群主要有兩種方案：

這些方案在一定程度上解決了編譯速度慢的問題，但隨之而來的是成堆的配置，嚴重影響了webpack的使用體驗，甚至出現了「webpack配置工程師」這種「新職業」。

與此同時，社群出現了一些新興的編譯技術，比如snowpack，它使用瀏覽器原生的es module實現了o(1)時間的編譯，對於「苦webpack久已」的那些人來說簡直不要太有吸引力。

但是這對webpack來說是一種挑戰，面對可能會被蠶食的使用者市場，webpack5的內建快取方案終於出來了。

長效快取是瀏覽器層面的快取，webpack通過optimization的splitchunks和runtimechunk的配置，讓編譯輸出的檔案具有穩定的hash名稱，從而讓瀏覽器能長期有效、安全的復用快取，達到加速頁面載入的效果。

編譯快取是編譯時的快取，webpack通過在首次編譯後把結果快取起來，在後續編譯時復用快取，從而達到加速編譯的效果。

webpack5的內建快取，以及本文所討論的，都是指編譯快取。

在使用webpack4以及之前的版本時，我們都會注意到這樣的現象：

這種現象的本質是：webpack4在執行時是有快取的，只不過快取只存在於記憶體中。所以，一旦webpack的執行程式被關閉，這些快取就丟失了。這就導致我們npm run start/build的時候根本無快取可用。

所以，解決問題的辦法就是把這些webpack編譯過程中的產生的快取持久化到本地磁碟、資料庫或者雲端。這裡面涉及到兩點：要持久化什麼，持久化到**。

webpack本身就已經有一套快取方案，只是不夠完善，不支援持久化。站在現在的角度來看，我們應該直接去完善webpack核心**，補充上持久化快取的功能，使用一套快取方案解決所有問題，這是顯而易見的。

然而，當時社群好像沒搞清楚「要持久化什麼」這個問題，他們沒有在webpack核心**上發力，而是選擇了從外部解決。於是就出現了cache-loader、dll等技術，雖然在一定程度上解決了問題，但卻引入了過多的複雜性。

實際上，「要持久化什麼」這個問題從一開始就是顯而易見的：是webpack執行時存在於記憶體中的那些快取，不是loader的產物，更不是dll。因此，webpack5提供了一套持久化抽象，並提供了幾個實現：

根據webpack執行環境的不同，在dev開發時依舊使用memorycacheplugin，而在build時使用idlefilecacheplugin。

webpack5直接從內部核心**的層面，統一了持久化快取的方案，有效降低了快取配置的複雜性。除此之外，由於所有被webpack處理的模組都會被快取，我們npm run start/build的二次編譯速度會遠超cache-loader，同時dll也可以退出歷史舞台了。

webpack4時之所以要有dll，是因為cache-loader並不能覆蓋所有模組，只能對個別被loader處理的模組進行快取。而那些通用的庫是沒法被cache-loader處理的，所以只能通過dll的方式來預編譯。

實際上，webpack5的內建快取方案無論從效能上還是安全性上都要好於cache-loader：