Tommy Mühle move:elevator

Möchte man nicht im Projekt genutzte PHAR-Dateien in seine Versionierung mit aufnehmen und Speicherplatz sparen, jedoch die benötigten Tools und Versionen festhalten, teamübergreifend schnelle Entwicklungsbereitschaft sicherstellen und nicht mehr als Composer dazu nutzen, hat man mit tooly-composer-script eine Möglichkeit dazu.

Jeder Entwickler hat sein Toolset zur Entwicklung von PHP-Projekten. Sehr oft kann dieses jedoch nicht zu einhundert Prozent auf jedes Projekt angewandt werden. Arbeitet man zusätzlich im Team, muss sichergestellt werden, dass alle das gleiche Toolset nutzen, da es ansonsten zu Problemen kommen kann, die unter Umständen viel Zeit für Konfiguration und Absprache kosten. Wie kann Composer dabei helfen?

In den letzten Jahren sind die Anforderungen an PHP-Projekte immer weiter gestiegen. Viele Entwickler achten mehr auf definierte Standards und Muster, schreiben Tests, erzeugen und analysieren Metriken. Das führt dazu, dass ein PHP-Projekt zur Entwicklung unter Umständen sehr viele Tools zur Qualitätssicherung und -analyse oder zum Testen benötigt. Da mittlerweile so gut wie jedes PHP-Projekt zur Verwaltung seiner Abhängigkeiten auf Composer setzt, kann diese Problemstellung auf den ersten Blick jedoch schnell gelöst werden. Ein Beispiel für die Verwendung des PHP-Testframeworks Behat im Projekt könnte dabei wie folgt aussehen:

{
  "require-dev": {
    "behat": "@stable"
  }
}

Warum sollte man besser PHAR-Dateien verwenden?

Diese Lösung birgt jedoch auch eine Gefahr: Da mittlerweile die meisten Projekte und Tools selbst auf Frameworks oder zumindest Frameworkkomponenten setzen, kann es im eigenem Projekt zu Abhängigkeitskonflikten kommen. Hier spricht man auch gern von der so genannten „Dependency Hell“. Das ist beispielsweise dann der Fall, wenn das eigene Symfony-Projekt auf Komponenten des Versionszweigs 2.8 setzt, das benötigte externe Tool jedoch bereits auf Komponenten des 3.0er Entwicklungszweigs aufbaut. Composer würde an dieser Stelle abbrechen, da nicht zwei Versionen einer Komponente im Projekt genutzt werden können. Um das zu vermeiden, empfehlen fast alle Autoren, die jeweiligen Tools als PHAR-Datei im Projekt zu nutzen. Das hat den großen Vorteil, dass die Abhängigkeiten der Tools nicht mehr zu Abhängigkeiten des eigenen Projekts werden und man diese in einer Datei gekapselt hat.

Was ist ein PHAR?

PHAR ist ein Applikationsarchivformat, das Dateien und Ordnerstrukturen enthalten kann. Dieses Archiv kann ausgeführt und genutzt werden, ohne es zu entpacken. Es kann ganze Applikationen enthalten, vom Autor verifiziert und einfach verteilt werden.

Ist man selbst nicht der einzige Entwickler, sondern arbeitet im Team, vielleicht sogar mit unterschiedlichen OS pro Entwickler, muss jedoch eine Menge Vorarbeit geleistet werden. Bei jedem Teammitglied muss sichergestellt sein, dass es das notwendige Toolset vollständig und in den jeweilig benötigten Versionen installiert hat. Oft werden auch mehrere Versionen ein und desselben Tools für unterschiedliche Projekte benötigt, z. B. PHPUnit in den Versionen 4.x und 5.x. Wird außerdem ein CI-System, z. B. Jenkins CI, verwendet, muss auch dieses entsprechend eingerichtet sein.

Den vollständigen Artikel lesen Sie in der Ausgabe:

PHP Magazin 2.17 - "Vue.js"

Alle Infos zum Heft
579758741Alles aus einer Hand: PHAR-Management mit Composer
X
- Gib Deinen Standort ein -
- or -