Damit aus Tailwind-Klassen im Template tatsächlich sichtbares CSS wird, muss Tailwind einmal (oder wiederholt während der Entwicklung) laufen und eine styles.css erzeugen. Dieses Kapitel zeigt den kompletten Build-Prozess - von der lokalen Entwicklung mit einem Watcher bis zur produktiven Deploy-Sequenz, die in diesem Projekt für jede Änderung gilt.

npm über den Wrapper

Genau wie bei Composer läuft auch npm im mironsoft-Projekt nie direkt, sondern immer über bin/npm - das stellt sicher, dass die Node-Version aus dem Docker-Container verwendet wird, nicht eine eventuell abweichende lokale Installation.

bin/npm --prefix app/design/frontend/Mironsoft/default/web/tailwind install

Tailwind CSS v4: CSS-first statt tailwind.config.js

Ein wichtiger Unterschied zu älteren Tailwind-Versionen: Ab Tailwind CSS v4 wird die Konfiguration nicht mehr primär in einer tailwind.config.js vorgenommen, sondern direkt im CSS, über die @theme-Direktive. Das Projekt nutzt durchgängig diesen CSS-first-Ansatz.

@import 'tailwindcss';

@theme {
  --color-brand-dark: #1a2332;
  --color-brand-slate: #475569;
  --color-brand-accent: #0ea5e9;
  --font-sans: 'Inter', sans-serif;
}

Diese Werte stehen danach als ganz normale Utility-Klassen zur Verfügung, zum Beispiel text-brand-dark oder bg-brand-accent. Kapitel 11 und 12 gehen im Detail auf eigene Design-Tokens ein - hier reicht es zu wissen, dass die Konfiguration im CSS selbst liegt, nicht in einer separaten JavaScript-Datei.

Der Watcher für die Entwicklung

Während der lokalen Entwicklung soll sich CSS bei jeder Template- oder CSS-Änderung automatisch neu bauen, ohne dass man manuell einen Befehl ausführt. Dafür gibt es den Tailwind-Watcher, der im mironsoft-Projekt bereits automatisch mit bin/start mitläuft:

bin/npm --prefix app/design/frontend/Mironsoft/default/web/tailwind run watch

Der produktive Build

Für ein Deployment (oder um lokal die tatsächliche Produktions-CSS zu testen) wird statt des Watchers ein einmaliger, minifizierter Build ausgeführt:

bin/npm --prefix app/design/frontend/Mironsoft/default/web/tailwind run build

Die korrekte Deploy-Sequenz

Genau hier passiert der häufigste Anfängerfehler: Nur den Tailwind-Build laufen zu lassen reicht nicht, wenn Magento bereits alte, statische Dateien zwischengespeichert hat. Für dieses Projekt gilt immer diese Reihenfolge, in genau dieser Reihenfolge:

1. CSS neu bauen - bin/npm --prefix app/design/frontend/[Vendor]/[theme]/web/tailwind run build
2. Static Files löschen (WICHTIG: immer zuerst, vor dem Deploy!) - cd src && rm -rf var/view_preprocessed/* pub/static/frontend/*
3. Static Content deployen - bin/magento setup:static-content:deploy de_DE -t [Vendor]/[theme] -f
4. Cache leeren - bin/magento cache:flush

# 1. CSS neu bauen
bin/npm --prefix app/design/frontend/Mironsoft/default/web/tailwind run build

# 2. Static Files löschen (WICHTIG: immer zuerst!)
cd src && rm -rf var/view_preprocessed/* pub/static/frontend/*

# 3. Static Content deployen
bin/magento setup:static-content:deploy de_DE -t Mironsoft/default -f

# 4. Cache leeren
bin/magento cache:flush

Entwicklungs-Workflow im Alltag

Im Tagesgeschäft (lokale Entwicklung mit Watcher aktiv) reicht meist ein einfaches bin/cache-clean, um Template- oder Layout-XML-Änderungen sichtbar zu machen - die volle Deploy-Sequenz mit produktivem Build ist typischerweise nur vor einem Live-Deployment nötig. Kapitel 27 geht noch einmal detailliert auf diese Sequenz ein, inklusive typischer Fehlerbilder.