YellowLeds Weblog v2

Artikel über Webdesign, Webstandards und Serendipity von Matthias Mees.

Vom Build-Tool zur Projektvorlage

Bereits seit zwei Jahren verwende ich Grunt als Build-Tool in Webprojekten. Seit ich hier zuletzt darüber geschrieben habe, hat sich das „kleine Build-Skript“ eher zu einer Projektvorlage entwickelt – Zeit für ein Update.

Was enthält die Projektvorlage?

Vereinfacht gesagt: Alles, was ich – normalerweise – in einem Webprojekt brauche oder brauchen könnte. HTML, SCSS, jQuery samt einigen nützlichen Plugins, ein paar weitere sinnvolle Dateien und eben ein auf Grunt basierendes Build-Skript, um das alles zusammen zu bringen und Abläufe zu automatisieren.

Ich verwende ausdrücklich und bewusst kein CSS-Framework und keine Sass-Bibliothek wie Compass. Natürlich schreibe ich nicht jede Zeile SCSS in jedem Projekt komplett neu. Ausgehend von normalize habe ich ein Basis-SCSS sowie eine kleine Bibliothek aus (zum Teil selbst geschriebenen, zum Teil von anderen übernommenen) Mixins. Die SCSS-Partials sind dabei so stukturiert, dass man nur in bestimmten (anfänglich leeren) Partials Code schreibt oder !default-Variablen überschreibt, damit man die Projektvorlage bei Bedarf einfach aktualisieren kann.

Und was machen nun all diese Grunt-Plugins?

Mittlerweile hat sich im Build-Skript so viel verändert oder ist neu hinzu gekommen, dass ich es noch einmal komplett neu dokumentieren wollte.

Generieren

Mit einer Ausnahme bereits oben beschrieben.

Servieren

Der lokale Webserver, den Grunt hier startet, ist sehr einfach gehalten, also nicht mit einem lokalen Apache zu vergleichen. Nötig ist er dennoch, da bestimmte Dinge (AJAX) ohne einen lokalen Server nicht funktionieren. Zudem bietet er Livereload-Funktionalität, schont also die Tastatur. ;-)

Optimieren

Organisieren

Ich hab's gern ordentlich, deshalb landet alles, was auf einen Staging- oder Live-Server soll, in einem eigenen Verzeichnis.

Testen

Diese Plugins bzw. die dazugehörigen Tasks machen alle dasselbe – sie überprüfen den betreffenden Code auf syntaktische Korrektheit.

Aus diesen Plugins habe ich ein paar Tasks definiert:

Ist das also nur für statisches HTML gedacht?

Jein. Alle Grunt-Tasks können grundsätzlich auch z.B. PHP-Dateien für ein CMS wie ProcessWire oder Smarty-Templates für Serendipity verarbeiten. Allerdings müssen dafür Stand heute einige Tasks von Hand angepasst werden. (Deshalb liegen übrigens alle Javascripte in scripts und alle Stylesheets in styles – so erwartet es ProcessWire standardmäßig.)

Ich fange zwar grundsätzlich jedes Webprojekt mit einem HTML-Prototypen an, aber das wäre für mich derzeit das letzte Feature, um das man diese Projektvorlage noch erweitern könnte: Projektstruktur und Build-Skript so anzupassen, dass man nahtlos vom HTML-Prototypen zum CMS-Template wechseln kann (was zumindest in ProcessWire ansonsten problemlos möglich ist). Allein, fehlt mir noch ein wenig die richtig Idee, wie man das sinnvoll umsetzen könnte …