Asset Bundling

Asset Bundling ist das Zusammenstellen und nötigenfalls Kompilieren von Modulen. Module können u.a. JavaScript, CSS, LESS-CSS enthalten. Module haben Abhängigkeiten unter einander. Asset Bundling löst diese Abhängigkeiten auf, kompiliert Module falls nötig und generiert zum Beispiel fertige JS- und CSS-Dateien.

Stud.IP verwendet in der Version 4.2 und aufwärts den Open-Source-Asset-Bundler “webpack”.

Die Konfigurationsdateien liegen im Projektverzeichnis und lauten “webpack.dev.js”, “webpack.dev-server.js” und “webpack.prod.js”.

Damit stehen drei Modi zum Asset-Bundling zur Verfügung:

make webpack-dev: Schnell. Kompiliert und bundled im Developer-Modus. Die Bundles sind nicht optimiert und leicht zu debuggen.
make webpack-prod: Langsam. Kompiliert und bundled im Production-Modus. Die Bundles sind optimiert und mit Source Maps zu debuggen.
make webpack-watch: Inkrementell. Der Befehl startet Webpack im Entwicklungsmodus und läuft dauerhaft weiter, um Änderungen automatisch neu zu bauen.

Einmalig vor dem ersten make-Aufruf müssen die npm-Pakete installiert werden:

npm install

Wenn man dann JavaScript- oder CSS-Dateien modifiziert hat, ruft man make webpack-dev oder make webpack-prod auf, damit die Änderungen in die Output-Dateien hineinkompiliert werden.

make webpack-dev vs. make webpack-prod

Da webpack-dev einiges schneller ist (aber nicht optimiert), eignet sich make webpack-dev für die lokale Entwicklung.

Bei make webpack-prod werden die Debug-Informationen in Sourcemap-Dateien hinterlegt, mit denen das Debugging ähnlich komfortabel sein sollte.

Auf einem Testsystem läuft make webpack-dev in ~6 Sekunden durch. Die make webpack-prod-Variante benötigt auf dem System ~17 Sekunden.

Kryptische Namen von gebundelten JavaScript-Dateien

Damit nach einem Versionswechsel einer Stud.IP-Installation keine Caching-Probleme beim Nutzer entstehen, wurde vor einigen Jahren eingeführt, dass die JavaScript-Dateien via PHP mit einem speziellen versionsabhängigen URL-Parameter eingebunden werden, der damit das Caching-Problem löst.

Wenn nun JavaScript-Dateien dynamisch geladen werden (siehe JavaScript in Stud.IP), werden die nachzuladenden Dateien direkt über JS eingebunden, ohne den Umweg über PHP zu nehmen. Damit kann man also den vorhandenen PHP-Mechanismus nicht mehr verwenden. Das Problem wird in ticket:9114 berichtet. Die nachzuladenden JS-Dateien werden als “chunks” bezeichnet.

Glücklicherweise bietet webpack zu diesem Zweck die Konfigurationsmöglichkeit, den Dateinamen der nachzuladenden JS-Dateien (“chunks”) anzupassen:

output: {
    chunkFilename: 'javascripts/[id].chunk.js?h=[chunkhash]',
}

Beim Asset-Bundling bekommen damit die “chunks” einen Namen, der einen Hash-Wert über den Inhalt des Chunks enthält. Ändert sich der Chunk inhaltlich bekommt er einen neuen Namen. An den Stellen im JS-Code, an denen auf diesen “chunk” verwiesen wird, setzt webpack automatisch diesen inhaltabhängigen Namen ein. Das ganze funktioniert natürlich automatisch, sodass man als Entwickler keine Mühe damit hat.

ABER: Ändert man den “chunk” oder updatet (automatisch) 3rd-party-Bibliotheken, die im “chunk” verwendet werden, ändert sich auch der Name der gebundelten “chunk”-Datei. Ruft man nach so einer Änderung “make” oder “webpack []” auf, entstehen neue “*.chunk.js” Dateien. Wenn man diese Dateien in eine Versionsverwaltung (svn oder git) einchecken möchte, muss man dann zuvor die alten “chunk”-Dateien abräumen und die neuen “chunk”-Dateien hinzufügen. Dies ist aber lediglich dann erforderlich, wenn man an diesen Dateien Änderungen vornimmt.

Damit kann es also passieren, dass Änderungen am Tablesorter durch Caching nicht unmittelbar beim Nutzer ankommen. Dieses Problem habe ich in ticket:9114 berichtet.