Diese Seite ergänzt Laravel-Paketentwicklung, Laravel-Pakete mit Orchestra Testbench testen und Versionskompatibilität von Paketen verwalten. Ergänzen Sie Implementierung, Test und Versionsstrategie um statische Analyse, um Pakete langfristig wartbar zu halten.
Was ist statische Analyse?
Statische Analyse erkennt Typfehler und potenzielle Bugs, ohne den Code auszuführen. Da Laravel-Pakete viele dynamische Mechanismen wie Service Container, Facades und Eloquent nutzen, kann sie Probleme erkennen, die im reinen Betrieb leicht übersehen werden. Die Einführung statischer Analyse bringt insbesondere:- Höhere Typsicherheit — falsche Argumente oder Rückgabetypen fallen vor dem Review auf.
- Frühe Fehlererkennung — Aufrufe nicht existierender Methoden oder übersehene
nullwerden vor Tests erkannt. - Bessere IDE-Vervollständigung — saubere PHPDocs und Generics erhöhen die Präzision.
- Stabilität in der Langzeitpflege — nach Laravel-/PHP-Upgrades sind kaputte Stellen leichter zu finden.
PHPStan einrichten
Bauen Sie zunächst die Basis mit PHPStan alleine auf. PHPStan 2.x geht strenger mitmixed und nullable um — Anlass, die Public API zu ordnen.
Larastan einrichten
Für Laravel-Pakete versteht PHPStan Container-Auflösung, Facades und Eloquent-Relations nicht ausreichend. Ergänzen Sie deshalb die PHPStan-Erweiterung Larastan.Larastan hinzufügen
Der aktuelle Paketname lautet
larastan/larastan. In älteren Artikeln taucht mitunter nunomaduro/larastan auf.Für Paketentwicklung Testbench installieren
Larastan startet zur Typ-Auflösung eine Laravel-Anwendungscontainer-Umgebung. Für die Einzelanalyse eines Laravel-Pakets ist häufig
orchestra/testbench nötig.Konfiguration von phpstan.neon
phpstan.neon bündelt Analyse-Level, Zielpfade, Ausschlüsse und Ausnahmen. Realistischer als sofort „100 Punkte” ist eine Konfiguration, die sich schrittweise steigern lässt.
Beispiel für eine phpstan.neon:
Wahl des Levels 0–9
PHPStan lässt sich stufenweise einführen. Starten Sie mit einem Level, das Ihre Codebasis bewältigen kann, und steigern Sie es nach Fortschritt.| Level | Passende Phase |
|---|---|
| 0–3 | Zuerst unbekannte Klassen, Funktionen, Methodenaufrufe reduzieren |
| 4–6 | Argumente, Rückgabetypen und Properties der Public API sauber typisieren |
| 7–9 | Nullable, Union und mixed strikt behandeln — Langzeitpflegephase |
paths
Geben Sie in paths die zu analysierenden Verzeichnisse explizit an. In Paketen lohnt es sich, neben src auch tests einzuschließen — die Typen sind dort häufiger brüchig.
excludePaths
Schließen Sie nur Orte mit geringem Analyse-Nutzen aus, z. B. generierte Dateien, Caches oder eine Workbench-Verifikationsumgebung. Zu breit auszuschließen kaschiert echte Fehler.
ignoreErrors
ignoreErrors ist letzte Wahl. Grenzen Sie Meldungen per Regex ein und ergänzen Sie path, um den Wirkungsbereich zu begrenzen. So können Sie später leichter zurückkehren, wenn Laravel oder Larastan Verbesserungen bringen.
Häufige Typannotationen
Die Präzision von PHPStan und Larastan hängt stark von den PHPDocs ab. Vor allem@param, @return, @var und Generics (@template) lohnen sich in Laravel-Paketen.
@param class-string<TModel>— der String ist keine beliebige Zeichenkette, sondern ein Model-Klassenname.@return TModel|null—find()liefert einen konkreten Model-Typ.@var Collection<int, TModel>— Key- und Value-Typ der Collection explizit machen.@template TModel of Model— ein wiederverwendbares generisches Repository.
Laravel-spezifische Fallstricke
Die „bequeme Magie” von Laravel wird von statischen Analysewerkzeugen nicht automatisch verstanden. Sie müssen Typinformationen so ergänzen, dass die Analyzer sie erfassen.Facades
Bei eigenen Facades helfen PHPDoc-Annotationen der aufrufbaren Methoden sowohl der IDE als auch der statischen Analyse.Magic Methods
APIs auf Basis von__call() oder Macroable sind bequem, aber typunfreundlich. In der Public API sind Wrapper-Methoden mit klaren Signaturen sicherer.
Typisierung von Eloquent-Modellen
Bei Eloquent-Relations und dynamischen Properties helfen@property und Generics an den Relations-Rückgaben.
Automatisierung in der CI
Führen Sie die statische Analyse nicht nur lokal, sondern auch in der CI aus. Vor allem bei Paketen, die mehrere Laravel-Versionen unterstützen, empfiehlt sich eine Testmatrix analog zu Versionskompatibilität von Paketen verwalten, um Kompatibilität und Typsicherheit gemeinsam zu überwachen. Ein Beispiel für.github/workflows/static-analysis.yml:
Häufige Fehlalarme und Umgang
Wenn eine Warnung erscheint, fragen Sie sich zuerst: „Fehlt Typinformation?” Was wie ein Fehlalarm aussieht, ist oft nur ein unvollständiger PHPDoc.@phpstan-ignore-next-line
Als temporäre Umgehung geeignet — beschränken Sie es aber auf Zeilen, deren Grund Sie selbst erklären können.
ignoreErrors
Nur einsetzen, wenn derselbe Fehler an mehreren Stellen auftritt. Grenzen Sie stets über path ein und vermeiden Sie zu grobe Regex-Muster, die alles verschlucken.
Reihenfolge der Gegenmaßnahmen
- PHPDoc ergänzen.
- Rückgabetypen von Facades und Relations explizit machen.
mixeddurch konkrete Typen ersetzen.- Erst danach — und nur mit Erklärung — Fehler ignorieren.
Verwandte Seiten
Laravel-Paketentwicklung
Grundlagen der Implementierung einschließlich Service Provider und veröffentlichter Ressourcen.
Laravel-Pakete mit Orchestra Testbench testen
Testinfrastruktur, die zusammen mit statischer Analyse betrieben wird.
Versionskompatibilität von Paketen verwalten
Laravel-/PHP-Kompatibilitätstabelle und die Matrix-Strategie in GitHub Actions.