Symfony Flex – der neue Workflow in Symfony 4

Symfony Flex – der Workflow für Symfony 4.0

Avatar von Maximilian Berghoff

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/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.

Avatar von Maximilian Berghoff

Kommentare

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

  1. i wrote a (german) introduction into „Symfony Flex – der Workflow für Symfony 4.0“ https://t.co/wnpZRrEMYW #symfony #flex

  2. Symfony Flex – die große Neuerung in Symfony 4 im Schnellcheck: https://t.co/ZJuHwWIRIH

  3. Unser @ElectricMaxxx hat sich ein wenig mit Symfony Flex beschäftigt: https://t.co/ZJuHwX0sAf

Schreibe einen Kommentar

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


Für das Handling unseres Newsletters nutzen wir den Dienst HubSpot. Mehr Informationen, insbesondere auch zu Deinem Widerrufsrecht, kannst Du jederzeit unserer Datenschutzerklärung entnehmen.