© Allies Interactive/Shutterstock.com
Erweiterte Anleitung zur Migration auf die neue Symfony-Flex-Struktur

Die Flex für Symfony 4


Jedes Symfony-Projekt wird früher oder später auf die neue Symfony-Flex-Struktur angepasst. Hier und da kann einem die vorgegebene Upgradeanleitung in der Dokumentation etwas zu dünn erscheinen. Oftmals kommt es auf die Details an, die einem den Umstieg auf die neue Symfony-Flex-Struktur erleichtern können.

Als Symfony-Entwickler kommt einem die Dokumentation zum Upgrade auf Flex schnell mal zwischen die Finger. Jedoch ist diese sehr allgemein gehalten und geht (meiner Meinung nach) nicht auf diverse Details ein.

Grundsätzliches Vorgehen

Bevor man mit dem Upgrade von Symfony 3.x auf >= 4.2 beginnt, sollte man folgende Dateien (sofern vorhanden) sichern:

  • .env

  • .env.dist

  • bin/console

  • weitere modifizierte oder selbst erstellte Dateien im Ordner bin

Nach der Aktualisierung der Version muss man – falls notwendig – eventuelle Änderungen etc. manuell in die neuen Dateien zurückführen, Änderungen an der bin/console sowie eventuelle andere Dateien im bin-Verzeichnis sichern. Außerdem sollten mögliche Änderungen an der bin/console von Beginn an notiert werden, damit diese nach einem Update wiederhergestellt werden können.

Zusätzlich sollte das Verzeichnis src vor dem Update in src-bundles umbenannt werden, denn diese müssen später unter anderem in eine entsprechend neue Struktur im src-Verzeichnis gebracht werden – hier stört der alte Inhalt beim Update.

Anpassungen in „composer.json“

Um Symfony zu aktualisieren, sind die folgenden Änderungen in composer.json durchzuführen:

  1. Falls Incenteev/ParameterHandler installiert ist, ist dieser zu entfernen, da für die Konfiguration jetzt .env-Dateien beziehungsweise Umgebungsvariablen verwendet werden und nicht mehr das parameters.yml. Dazu zählen

    1. das Entfernen von incenteev/composer-parameter-handler in require und require-dev-Sektionen,

    2. das Entfernen aller Vorkommnisse von Incenteev\\ParameterHandler\\ScriptHandler::buildParameters in der scripts-Sektion und

    3. das Entfernen der alten scripts-Einträge, die mit Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler:: beginnen; hier kommt stattdessen auto-scripts zum Einsatz.

  2. Neue Einträge in scripts erstellen (Listing 1); bei diesem Schritt sind eventuell eigene Skripte zu ergänzen. Nach dem Upgrade von Symfony sieht das dann z. B. wie in Listing 2 aus. Hiermit kann man in auto-scripts weitere Symfony-Befehle ähnlich wie diese ergänzen bzw. bei assets:install definieren, ob man Kopien der Dateien oder Symlinks verwenden will.

  3. In der extra-Sektion müssen die Parameter, die mit symfony- beginnen, entfernt werden. Falls man nach dem Update die Struktur ändern will, kann man sich an die Dokumentation halten [1].

  4. Zusätzlich sollte man die Inhalte aus Listing 3 in der extra-Sektion ergänzen:

    1. require definiert hierbei, welche Version für die Symfony-Komponenten zum Einsatz kommt.

    2. allow-contrib definiert, dass Symfony Flex Recipes nicht nur für die offiziellen Symfony-Komponenten, sondern auch für solche anderer Bundles verwendet werden (eine Übersicht, welche das sind, findet man auf GitHub [2]). Ist dies nicht gewünscht, muss hier false eingesetzt werden (Listing 3). Es empfiehlt sich, diesen Wert zumindest bis nach dem Upgrade von Symfony auf true zu setzen und nach Bedarf danach auf false. Damit erhält man zumindest die Grundkonfiguration für die meisten der installierten Bundles.

  5. Aufgrund der extra-Sektion lassen sich die Symfony Dependencies jetzt wie in Listing 4 in require hinzufügen. Diese Liste kann bei Bedarf um weitere Dependencies erweitert werden – je nachdem, ob das für das Projekt notwendig beziehungsweise gewollt ist.

  6. Um sicherzustellen, dass die komplette Symfony Library nach der Änderung nicht mehr zum Einsatz kommt, muss Folgendes ergänzt werden:

    "conflict": { "symfony/symfony": "*" } 

    Falls es conflict schon gibt, muss lediglich "symfony/symfony": "*" ergänzt werden.

  7. Aus autoload muss der folgende Eintrag entfernt werden: "classmap": ["app/AppKernel.php", "app/AppCache.php"]

  8. Im autoload unter psr-4 muss der folgende Eintrag ergänzt werden: App\\": "src/",

  9. Existierende autoload-Einträge müssen entsprechend von src auf src-bundles angepasst werden, beispielsweise: "AppBundle\\": "src-bundles/AppBundle/",

Listing 1

"scripts": { "auto-scripts": [ ], "post-install-cmd": [ "@auto-scripts" ], "post-update-cmd": [ "@auto-scripts" ] },

Listing 2

"scripts": { "auto-scripts": { "cache:clear": "symfony-cmd", "assets:install %PUBLIC_DIR%": "symfony-cmd" }, "post-install-cmd": [ "@auto-scripts" ], "post-update-cmd": [ "@auto-scripts" ] },

Listing 3

"symfony": { “allow-contrib": true, "require": "4.2.*" }

Listing 4

"symfony/console": “*", "symfony/dotenv": "*", "symfony/flex": "^1.1", "symfony/framework-bundle": "*", "symfony/yaml": „*",

Am Schluss sollte ein fertiges composer.json, ähnlich dem des Symfony Skeletons [3], entstanden sein. Symfony Flex Recipes können unter [4] eingesehen oder gesucht werden. Auch auf GitHub in den Repositories [5] und [6] finden sich weitere Symfony Recipes.

Symfony updaten

Möchte man Symfony updaten, müssen zuerst folgende Verzeichnisse und Dateien gelöscht werden:

  1. bin

  2. vendor

  3. symfony.lock (falls vorhanden)

Im Anschluss kann Symfo...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang