Symfony Flex – der Workflow für Symfony 4.0

Im November ist es wieder so weit: Wenn in Cluj die diesjährige Symfony Con stattfindet, wird es auch zur Vorstellung von Symfony 4.0 kommen. Neben einigen Änderungen in der Struktur und Größe einer Symfony-Applikation scheint es eine weitere bahnbrechende Veränderung für Symfony-Applikationen zu geben: Symfony Flex.

Bei Symfony Flex handelt es sich nicht um ein neues Produkt oder ein neues Bundle; vielmehr geht es darum, einen neuen Workflow zu etablieren – einen Workflow, bei dem den Entwicklern beim Erstellen einer Symfony-Applikation einiges an Arbeit abgenommen werden soll.

Die Skeleton-App

Wie soll nun der Workflow aussehen? Fangen wir erst einmal mit einer Symfony-Applikation an:

Wir erhalten dadurch eine kleine aber lauffähige Symfony-App. Klein in dem Sinne, dass sie deutlich weniger beinhaltet, als wenn man beispielsweise mit composer require "symfony/symfony" das ganze Framework geladen hätte. Ein Blick in die geladenen Komponenten verrät, dass hier nur ein Bruchteil der Symfony-Bundles und Komponenten geladen wird. Die Applikation ist jedoch schon sofort lauffähig:

Ich will mehr

Will man nun weitere Komponenten hinzufügen, zeigt sich schon der neue Workflow. Wie man in der Liste erkennen kann, fehlt hier ganz klar das CLI, das sich mit wenigen Handgriffen nachladen lässt:

Hierbei sollten einem gleich mehrere Zeilen ins Auge fallen. composer req cli ersetzt composer require symfony/consolecli dient hier als Alias. Für diesen Alias kann man sogenannte „Rezepte“ definieren.

Ein solches Rezept wird hier auch verwendet: Configuring symfony/console (3.3): From github.com/symfony/recipes:master . Das bedeutet, dass in einem GitHub-Repository die Vorlagen für solche Komponenten und Bundles liegen.

Hier wurde im Übrigen ein Zwei-Klassen-System etabliert: Während sich auf github.com/symfony/recipes die „Main“-Rezepte befinden, kann man als allgemeiner Contributor seine Library in github.com/symfony/recipes-contrib als Rezept hinterlegen.

Backe, backe Kuchen …

Was bringen diese Rezepte nun? Sie erleichtern uns das Anlegen von neuen Bundles.

Werfen wir einen Blick in die bundles.php, die als neuer Ort für die Bundle-Registrierung dient, sehen wir, dass hier bereits der Eintrag für ein Bundle vorgenommen wurde. Natürlich haben wir eben nur eine Komponente geladen. Lädt man sich beispielsweise mit composer req twig Twig nach, so sieht man schnell, dass das Bundle sofort registriert ist. Was können Rezepte sonst?

  • Default-Konfiguration unter config/ für ein Bundle anlegen
  • Routen registrieren
  • Einträge im Makefile der Applikation anlegen
  • Parameter in Form von Environment-Variablen hinzufügen

Wie das in Symfony Flex geht ist in einem Blog von Fabian und in der Dokumentation hinterlegt.

Symfony Flex und die Struktur

Was ich bisher stillschweigend verschwiegen habe, sollte sichtbar werden, wenn man die neue Applikation im Editor seiner Wahl öffnet. So viel sei verraten: Es hat sich viel getan!

Symfony Flex: Struktur einer Symfony-4-Applikation

Es gibt keinen app/-Folder mehr und die Konfiguration liegt in einem eigenen config/-Verzeichnis im Projekt-Root. Dabei können Bundles einzelne Konfigurations- und Routing-Dateien bekommen. Die Dateien enden auch nicht mehr auf .yml sondern auf .yaml. yaml-Dateien die über Rezepte kommen, werden dort auch zusätzlich auf Validität überprüft.

Eine nächste Veränderung ist das Verzeichnis public/; das heißt web/ ist Geschichte. In diesem Verzeichnis finden wir auch nur noch einen Front-Controller. Das wiederum bedeutet, dass auch die app_dev.php inzwischen Geschichte ist.

Das Environment kann nun direkt über eine Environment-Variable geändert werden – genau hier versteckt sind die nächste Änderung: keine parameters.yml mehr. Parameter leben, wie ich es auch für Webserver als nativ empfinde, nun in der .env und werden als Environment-Variablen behandelt. Diese können dann in den Konfigurationen beispielsweise mit einem '%env(APP_SECRET)%' aufgerufen werden. Kommt man zu dem Punkt, dass man Twig-Templates verwendet, sieht man, dass auch diese ihren gewohnten Platz verlassen haben. Man findet sie dann unter templates/.

Conclusion

Auch wenn sich für mich als Library-Entwickler wenig an der reinen Bedienung von Symfony geändert hat – zumindest gehe ich derzeit davon aus, dass ich Symfony 4.0 ins Symfony CMF integrieren kann, ohne eine neue Major-Version veröffentlichen zu müssen kann –, hat sich sehr viel auf Ebene der Struktur und des Workflows getan.

Der kritische Leser könnte sich jetzt fragen „Warum der Workflow? Mein Projekt setze ich einmal auf und dann lebt das 10 Jahre“. Für diesen Fall sehe ich natürlich kaum einen Vorteil. Wenn ich jedoch kleine Apps (Micro-Services) am Band aufsetze, die wirklich nur dediziert einzelnen Komponenten Nutzen bringen sollen sollen, komme ich mit Symfony Flex sehr schnell voran.

Für neue Blogupdates anmelden:


4 Gedanken zu “Symfony Flex – der Workflow für Symfony 4.0

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.