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:
composer create-project "symfony/skeleton:^3.3" mayflower-blog
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:
composer show symfony/* symfony/cache v3.3.9 Symfony Cache component with PSR-6, PSR-16, and... symfony/class-loader v3.3.9 Symfony ClassLoader Component symfony/config v3.3.9 Symfony Config Component symfony/debug v3.3.9 Symfony Debug Component symfony/dependency-injection v3.3.9 Symfony DependencyInjection Component symfony/dotenv v3.3.9 Registers environment variables from a .env file symfony/event-dispatcher v3.3.9 Symfony EventDispatcher Component symfony/filesystem v3.3.9 Symfony Filesystem Component symfony/finder v3.3.9 Symfony Finder Component symfony/flex v1.0.21 symfony/framework-bundle v3.3.9 Symfony FrameworkBundle symfony/http-foundation v3.3.9 Symfony HttpFoundation Component symfony/http-kernel v3.3.9 Symfony HttpKernel Component symfony/polyfill-apcu v1.5.0 Symfony polyfill backporting apcu_* functions t... symfony/polyfill-mbstring v1.5.0 Symfony polyfill for the Mbstring extension symfony/routing v3.3.9 Symfony Routing Component symfony/stopwatch v3.3.9 Symfony Stopwatch Component symfony/yaml v3.3.9 Symfony Yaml Component
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:
composer req cli Using version ^3.3 for symfony/console ./composer.json has been updated Loading composer repositories with package information Updating dependencies (including require-dev) - Installing symfony/console (v3.3.9) Loading from cache symfony/console suggests installing symfony/process () Writing lock file Generating autoload files Symfony operations: 1 recipe - Configuring symfony/console (3.3): From github.com/symfony/recipes:master Executing script make cache-warmup [OK] Executing script assets:install --symlink --relative public [OK]
Hierbei sollten einem gleich mehrere Zeilen ins Auge fallen. composer req cli ersetzt composer require symfony/console – cli 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!
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.
Schreibe einen Kommentar