Dieses Jahr wird voraussichtlich am 23. November PHP 8.3 veröffentlicht. Nur wenige Tage später, am 26.November, soll der Security Support für PHP 8.0 eingestellt werden. Das führt dazu, dass viele Entwickler ihre Applikationen für die neuen PHP-Versionen vorbereiten müssen!

Heute möchte ich kurz erklären, wie ich sicherstelle, dass meine Applikationen mit den neuesten PHP-Versionen kompatibel sind und wie ich herausfinde, ob ich meinen Code aktualisieren muss.

Statische Code-Analyse

Heutzutage führt eigentlich kaum noch ein Weg an den sogenannten statischen Code-Analysen vorbei. Diese Tools prüfen automatisiert den Code auf Probleme wie Syntaxfehler und veraltetes Verhalten (Deprecations), die durch PHP zur Laufzeit generiert werden würden.

Vor etwas über einem Jahr hatte ich bereits über Psalm geschrieben – ein super Tool, das ich auch jetzt noch in verschiedenen Projekten einsetze. Für manche Applikationen nutze ich im beruflichen Umfeld PHPStan. Beide Tools prüfen den Code, ohne ihn auszuführen, bringen ein Plugin-System mit und lassen sich über die Konsole ausführen. Soweit ich es herausfinden konnte, hat PHPStan die etwas größere Community hinter sich stehen.

Psalm auf Packagist und GitHub.
PHPStan auf Packagist und GitHub.

Beide Tools liefern inhaltlich sehr gute Ergebnisse, jedoch musste ich bei PHPStan etwas mehr Mühe aufbringen, um das Bootstrapping zum Laufen zu bringen. Schuld daran ist zwar die Applikation (bzw. deren Bootstrapping), doch Psalm hatte es mir leichter gemacht. Fairerweise wollte ich das erwähnen 😉

PHP Lint

Eine andere Möglichkeit, um PHP Code für bestimmte Versionen zu prüfen und Syntaxfehler zu finden ist ein Linter. Ich habe dazu PHP-Parallel-Lint genutzt. Auch dieses Tool wird über die Konsole ausgeführt, hat aber einen entscheidenden Vorteil gegenüber den anderen: Es ist möglich, den Code auf Basis verschiedener PHP-Versionen zu prüfen. PHPStan und Psalm konnten mir das nicht anbieten – zumindest konnte ich in der Doku nichts dazu finden 🙁

Wie funktioniert das? Nun, das ist eigentlich ganz einfach – bedarf aber etwas Vorbereitung. Damit PHP-Parallel-Lint die Codebasis für eine bestimmte PHP-Version prüfen kann muss diese PHP-Version auf dem System installiert sein. Anschließend kann man beim Ausführen des Tools die „executable“ per Parameter mitgeben. Hier kann man dann auf beliebige PHP Executables verweisen, sofern diese installiert sind.

Achtung! Der Lint-Prozess bricht bei Syntaxfehlern ab. Das heißt ihr solltet eine Datei, nach dem korrigieren eines Fehlers, unbedingt erneut linten lassen.

PHP-Parallel-Lint auf Packagist und GitHub.

GrumPHP als weitere Hilfe

Seit mehreren Jahren nutzen wir im Büro GrumPHP – dieses Tool hängt sich an die GIT Hooks und wird immer dann ausgeführt, wenn ihr Code committen möchtet. Die geänderten Dateien werden an eine Reihe konfigurierter Tools übergeben, die nun darüber entscheiden ob euer Code committet werden darf oder nicht.

Gerade zu Beginn kann diese „Hürde“ etwas nervig erscheinen und zusätzliche Zeit kosten – auf lange Sicht gesehen macht ein solcher Workflow aber absolut Sinn. Ich kann aus eigener Erfahrung berichten, das durch PHPStan und Psalm der ein oder andere grobe Schnitzer NICHT im Repository gelandet ist 😉

GrumPHP liefert eine grumphp.yml.dist in der die meisten Tools hinterlegt sind.

GrumPHP auf Packagist und GitHub.

Wir nutzen übrigens die Phar Version, damit wir keine Probleme mit anderen Paket-Abhängigkeiten bekommen 😉

Erwähnenswerte weitere Tools

Neben PHPStan, Psalm und dem PHP-Parallel-Lint sind natürlich noch andere Tools bzw. „Tasks“, wie es bei GrumPHP heißt, im Einsatz, die ich hier zumindest stichpunktartig erwähnen möchte:

• GIT Blacklist – hier können verbotene Keywords hinterlegt werden, die den Commit unterbinden. Üblicherweise findet man hier so Dinge wie var_dump(, alert( oder dump(.
• GIT Commit Message – im Büro muss jeder Commit auf ein Ticket referenzieren. Dieser Task hilft uns dabei, die Commit Message über einen regulären Ausdruck zu definieren, zum Beispiel Merge branch oder TICKET-[0-9]+.
• JSON Lint – Ähnlich wie PHP-Parallel-Lint … Nur für JSON 😉
• XML Lint – Siehe oben
• YAML Lint – Siehe oben
• PHP-CS-Fixer – Ein Code-Style Checker, der den Code-Style automatisch versucht anzupassen
• PHPStan – Wie erwähnt, muss der Code erst an PHPStan vorbei 🙂

Und mit dieser Liste verabschiede ich mich für heute von euch. Ich werde keine Versprechen mehr für neue Postings machen – wenn es zeitlich passt und ich etwas Spannendes zu berichten habe, melde ich mich 🙂

Bis dahin wünsche ich euch Happy Coding!