Gemeinsame Nutzung des Symfony-Codes mit Packagist und Composer
Code wiederzuverwenden ist eine gängige Praxis für Entwickler, um eine ständige Neuentwicklung zu vermeiden. Statt viele Dateien mehrfach zu kopieren, umfasst die moderne Entwickler-Toolkette Paketverwaltungen und gemeinsame Repositories. Die Verwendung von geteiltem Code ist ein Muss für Entwickler, die mit Symfony arbeiten, die gemeinsame Nutzung der eigenen Funktionalität ist hingegen nicht so üblich. Wir wollen nun im Folgenden lernen, wie man dies angeht.
Symfony wird mit der Programmiersprache PHP erstellt. Zusätzlich zu der zentralen Sprache und den mit ihr erstellten Frameworks (wie Symfony) gibt es ein Ökosystem von Tools. Der am häufigsten verwendete Weg zur gemeinsamen Nutzung von Code ist die Verwendung des Paketmanagers Composer. Diese Software verwaltet die Abhängigkeiten der für ein Projekt benötigten Softwarekomponenten. Sie verwaltet die Komplexität bei der Suche nach der richtigen Kombination von Paketen und installiert sie in Ihrem Projekt.
Composer ist eine Client-Anwendung, die von einem Code-Repository unterstützt werden muss. Ein Repository ist eine zentrale Sammlung von Code mit angehängten Metadaten wie Versionsdaten, anderen Abhängigkeiten usw. Es kann ein eigenes Repository gehostet werden, aber die PHP-Community verwendet meistens das Repository von Packagist.org. Zum Zeitpunkt der Erstellung dieses Artikels gibt es über 272.000 einzelne Pakete, die auf Packagist gehostet werden.
In einem praktischen Beispiel wollen wir die erforderlichen Schritte untersuchen, um den in einem früheren Blog-Beitrag erstellten Befehl zur Konvertierung von Feldtyp-Inhalten der eZ Platform freizugeben. Dieser Befehl ist projektübergreifend nützlich, weshalb es sich lohnt, ihn mit anderen zu teilen. Zudem ist er einfach genug, um ihn als Beispiel zu verwenden. Ferner lässt es sich in das Symfony Framework integrieren, so dass es direkt nach der Installation ohne Konfiguration einsatzbereit ist.
Es sind vier Schritte erforderlich, um einen Teil der Symfony-Funktionalität auf Packagist zu veröffentlichen:
- Code in ein Symfony-Bundle verpacken
- Komponisten-Metadaten hinzufügen
- Push an ein GitHub- (oder anderes) Repository
- Auf Packagist veröffentlichen
Das Bundle-System in Symfony ist ein Verfahren zum Verpacken von Code, Konfiguration, Vorlagen usw. in ein einziges Paket. Es gibt viele Möglichkeiten und bei Interesse empfehle ich, sich den Screencast der SymfonyCasts anzusehen: Creating a Reusable (& Amazing) Symfony Bundle
Heute verpacken wir einen einzelnen Konsolbefehl, wozu Folgendes in unserem Bundle benötigt wird:
- Bundle Boilerplate
- Service-Konfigurationsdatei
- Befehlscode
Der Boilerplate-Code umfasst die Bundle Class und die Dependency Injection Class. Die enthaltene Service-Konfigurationsdatei wird im YAML-Format geladen. Wenn diese vorhanden ist, kann das Symfony-Framework unser Bundle bootstrappen und das Herzstück unserer Anwendung laden: den Konsolenbefehl zur Konvertierung von Bildfeldinhalten in Bild-Asset-Felder unter Verwendung der eZ Platform PHP-API.
Nachdem unser Code installiert ist, müssen wir Metadaten für den Composer-Paketmanager hinzufügen. Diese werden in der Datei composer.json im Stammverzeichnis gespeichert. Der einfachste Weg, sie mit Composer zu erzeugen:
$ composer init Welcome to the Composer config generator This command will guide you through creating your composer.json config. Package name (<vendor>/<name>) [janit/ezplatform-migrate-image-asset]: Description []: Copy eZ Platform image field contents to image asset field type Author [, n to skip]: n Minimum Stability []: Package Type (e.g. library, project, metapackage, composer-plugin) []: symfony-bundle License []: MIT Define your dependencies. Would you like to define your dependencies (require) interactively [yes]? no Would you like to define your dev dependencies (require-dev) interactively [yes]? no { "name": "janit/ezplatform-migrate-image-asset", "description": "Copy eZ Platform image field contents to image asset field type", "type": "symfony-bundle", "license": "MIT", "require": {} } Do you confirm generation [yes]? yes $
In der obigen Konfiguration sollte der Fokus besonders auf den Paketnamen gelegt werden. Der Paketname sollte mit dem auf Packagist vorhandenen Paketnamen übereinstimmen. Wenn das Paket z. B. andere Abhängigkeiten benötigt, sollten diese aufgelistet werden, damit Composer alle Abhängigkeiten wie andere Bibliotheken usw. auflösen kann. In unserem Fall hat unser Paket keine externen Abhängigkeiten, so dass hier nichts benötigt wird.
Sobald der Code vervollständigt ist, sollte ein Repository auf GitHub oder anderswo erstellt und der Code dorthin verschoben werden. Die Veröffentlichung auf packagist.org ist selbsterklärend. Sobald man sich eingeloggt hat, kann man ein Paket über das obere Menü übermitteln. Dazu wird eine Repository-URL (Git, Subversion oder Mercurial) benötigt, dann kann das neu erstellte Repository eingegeben werden. Nach der Einreichung des Pakets geht es weiter.
Packagist holt nun die Metadaten der Pakete aus dem Repository und veröffentlicht sie im öffentlichen Katalog. Hier sollte darauf geachtet werden, dass eine ordnungsgemäße Version mit Tags im Repository versehen wird. Wie dies möglich ist, lässt sich in der Composer-Dokumentation unter Versionen und Einschränkungen einsehen.
Sobald alles überprüft ist, wird das Paket veröffentlicht und kann mit Composer installiert werden:
composer require janit/ezplatform-migrate-image-asset
Wie der Veröffentlichungsprozess funktioniert, hier im Video:
eZ Platform ist nun Ibexa DXP
Ibexa DXP wurde im Oktober 2020 veröffentlicht und ersetzt den Produktnamen eZ Platform. Damit einhergehend steht eine Weiterentwicklung der Technologie. Erfahren Sie mehr dazu in dem Blogpost Vorstellung der Ibexa DXP v3.2, um mehr über die DXP und den Produkten Ibexa Content, Ibexa Experience und Ibexa Commerce zu erfahren.