Wechsel zu Webpack: Verträgt sich unser Buildsystem mit dem neuen Allheilmittel?
Beim letzten myInnovationDay hatte Thomas die Anwendungsmöglichkeiten des Buildtools webpack erkundet und getestet. Dort könnt ihr eine Einführung zum Thema nachlesen. Weil webpack langsam aber sicher in der Frontend-Community allgegenwärtig wird, habe ich mir dieses Mal vorgenommen auf Thomas Arbeit aufzubauen und unser derzeit aus vielen, verschiedenen gulp-Modulen bestehendes Buildsystem durch webpack zu ergänzen und (hoffentlich) übersichtlicher und modularer aufzubauen. Einen Vorteil und eine Schwierigkeit, auf die ich dabei gestoßen bin, möchte ich hier kurz vorstellen.
Unser Frontend-Framework nutzen wir um bei jedem Projektstart schon eine solide Basis an Werkzeugen und Architektur zur Verfügung zu haben. Es ist mittlerweile zu einem komplexen System aus einerseits verwendeten Bibliotheken und andererseits den Prozessen geworden, mit denen wir zum Beispiel SCSS oder ES6 kompilieren, Dateien mergen und minimieren, und so produktionsbereit machen. Schnell habe ich gemerkt, dass der Versuch, webpack einfach in dieses System hinein zu basteln, zum Scheitern verurteilt ist. Dafür ist das bestehende System einfach schon zu komplex, und Fehler, die beim ausprobieren einer neuen Technologie zwangsläufig auftreten, sind zu schwer zu identifizieren und zu lösen. Deshalb habe ich zunächst ein kleineres, in der Struktur aber unserem Framework genau entsprechendes Projekt aufgesetzt und damit weitergearbeitet.
Ein großer Vorteil von webpack ist eine größere Modularisierung der Komponenten. Thomas hatte das schon erwähnt und erklärt, welche Vorteile daraus folgen. Ich möchte illustrieren, was das für den geschriebenen Code bedeuten kann. Durch die Verwendung von vielen verschiedenen Bibliotheken von Dritten, müssen wir in unserem Code immer wieder auf deren Dateien verweisen um die Funktionen nutzen zu können. Wir nutzen bei 4c media zum Beispiel das Framework Foundation for Sites 6 von der amerikanischen Agentur Zurb. In unserem jetzigen Setup importieren wir es folgendermaßen:
@import '../bower_components/foundation-sites/scss/foundation';
Wir benutzen also einen relativen Pfad, der einen Fehler verursacht, sobald wir diese Datei, in der er steht, verschieben. Webpack hingegen erkennt bestimmte Ordner als Quellen für solche importierten Module und durchsucht diese um @import-Statements aufzulösen. So können wir die gleich Datei so importieren:
@import 'foundation-sites/scss/foundation';
Jetzt stimmt der Pfad, unabhängig davon, wo im Projekt der Import stattfindet. Bei so einem einfachen Beispiel mögen die Vorteile gering erscheinen, aber je größer das Projekt, desto komplizierter die Verknüpfungen und größer der Nutzen von solchen Vereinfachungen.
Während ich diesen Vorteil gerne für uns nutzbar machen möchte, besteht die Schwierigkeit, dass webpack nicht entwickelt wurde, um damit CSS und JavaScript für Landing Pages, oder Shopsysteme zu kompilieren. Es ist zunächst ein Tool für App-Entwickler und verpackt, zum Beispiel, per default alles in einer JavaScript-Datei, die dann CSS und JavaScript-Module der Anwendung in die HTML-Seite injeziert. Das ist ist für die Webseiten, die wir bei 4c media zumeist bauen, eher nicht gewünscht und muss deshalb erst anders konfiguriert werden.
Fazit des Tages ist, wie schon Thomas vorher angemerkt hat, webpack ist ein mächtiges, hochkonfigurierbares, und deshalb nicht ganz zugängliches Werkzeug. Es wird noch einige Stunden erfordern, es in unser Framework zu integrieren, ist aber sicherlich langfristig lohnenswert.