Skip to main content
Een Laravel-package is niet klaar na één release. Om het jarenlang te onderhouden terwijl je meebeweegt met updates van Laravel zelf, PHP en je dependencies, moet je naast tests ook continu statische analyse draaien.
Deze pagina is een aanvullende gids bij Laravel-packages ontwikkelen, Laravel-packages testen met Orchestra Testbench en Versiecompatibiliteit van packages beheren. Als je statische analyse toevoegt aan implementatie, tests en versiestrategie, krijg je een package dat op de lange termijn goed te onderhouden is.

Wat is statische analyse?

Statische analyse is een techniek die type-inconsistenties en potentiële bugs opspoort zonder de code uit te voeren. Omdat Laravel-packages veel dynamische mechanismen bevatten — de service container, facades, Eloquent — vang je hiermee in een vroeg stadium problemen op die je bij alleen functioneel testen makkelijk mist. Statische analyse invoeren levert vooral het volgende op:
  • Betere typeveiligheid — verkeerde argumenten of returnwaarden worden vóór de review gedetecteerd
  • Vroege bugdetectie — aanroepen van niet-bestaande methodes of over het hoofd geziene nullables ontdek je vóór het testen
  • Betere IDE-autocomplete — door PHPDoc en generics op orde te brengen wordt de autocomplete nauwkeuriger
  • Stabieler langetermijnonderhoud — bij upgrades van Laravel of PHP spoor je kapotte plekken makkelijker op

PHPStan opzetten

Zet eerst met alleen PHPStan een analysefundament op. PHPStan 2.x gaat strikter om met mixed en nullables dan voorheen, dus het is ook een goed moment om de publieke API van je package op te schonen.
1

Voeg PHPStan toe als dev-dependency

2

Analyseer eerst de doelmappen rechtstreeks

Bij packages neem je meestal src en tests als eerste doelwit.
3

Leg het vast als Composer-script

Door een script te definiëren in composer.json gebruik je in CI en lokaal hetzelfde commando, wat het beheer makkelijker maakt.

Larastan opzetten

Met alleen PHPStan begrijpt de analyse Laravel-specifieke mechanismen zoals containerresolutie, facades en Eloquent-relaties onvoldoende. Daarom gebruik je daarnaast Larastan, de Laravel-extensie voor PHPStan.
1

Voeg Larastan toe

De huidige packagenaam is larastan/larastan. In oudere artikelen kom je soms nunomaduro/larastan tegen.
2

Installeer bij packageontwikkeling ook Testbench

Larastan start een Laravel-applicatiecontainer om types op te lossen. Als je een Laravel-package los analyseert, kan orchestra/testbench nodig zijn.
3

Laad extension.neon in

Include de Larastan-configuratie in phpstan.neon.

De configuratie van phpstan.neon

phpstan.neon is de centrale configuratie voor het analyseniveau, de doelpaden, uitgesloten paden en uitzonderingsregels. Voor een Laravel-package is het realistischer om een configuratie te kiezen die je stapsgewijs kunt aanscherpen dan om meteen op een perfecte score te mikken. Hieronder een voorbeeld van phpstan.neon.

Niveau 0–9 kiezen

PHPStan kun je stapsgewijs invoeren. Het is het veiligst om te beginnen op een niveau dat je huidige codebase aankan en het te verhogen naarmate je verbeteringen doorvoert.
PHPStan 2.x heeft ook level 10, maar voor Laravel-packages is het realistisch om eerst 5–7 te stabiliseren en dan door te groeien naar 8–9. Bij een nieuw package kun je beter meteen op een hoger niveau beginnen; dat scheelt terugwerken.

paths

In paths geef je expliciet de mappen op die je wilt analyseren. Bij packages loont het om naast src ook tests op te nemen, waar types makkelijk verwateren.

excludePaths

Sluit alleen plekken uit waar statische analyse weinig waarde heeft, zoals gegenereerde bestanden, caches en de Workbench voor verificatie. Als je te breed uitsluit, zie je ook de fouten niet meer die je juist wilde detecteren.

ignoreErrors

ignoreErrors is een laatste redmiddel. Beperk de melding met een reguliere expressie en gebruik ook path om de reikwijdte in te perken. Zo kun je makkelijk terugdraaien wanneer Laravel of Larastan in de toekomst verbetert.

Veelgebruikte typeannotaties

De nauwkeurigheid van PHPStan en Larastan hangt sterk af van hoe je PHPDoc schrijft. Bij Laravel-packages is het vooral waardevol om @param, @return, @var en generics (@template) op orde te hebben.
In dit voorbeeld geef je de volgende informatie aan PHPStan door:
  • @param class-string<TModel> — geeft aan dat de string geen willekeurige string is, maar de naam van een Model-klasse
  • @return TModel|null — vertelt dat find() een concreet modeltype teruggeeft
  • @var Collection<int, TModel> — maakt de key/value-types van de collection expliciet
  • @template TModel of Model — drukt een herbruikbare generieke repository uit

Laravel-specifieke aandachtspunten

De “handige magic” van Laravel komt niet vanzelf bij de statische analyse terecht. Je moet aan de packagekant type-informatie toevoegen en het in een vorm gieten die de analyzer begrijpt.

Facades

Bij een custom facade helpt het om de methodes die gebruikers aanroepen in PHPDoc aan te vullen; dat werkt zowel voor de IDE als voor statische analyse.

Magic methods

API’s die leunen op __call() of Macroable zijn handig, maar het zijn plekken waar types makkelijk verwateren. Als je er een publieke API van maakt, is het veiliger om wrapper-methodes toe te voegen waarvan de argumenten en returnwaarden duidelijk zijn.
Als je alleen omwille van de statische analyse steeds meer ignoreErrors toevoegt, verberg je hoe facades en macro’s echt kapotgaan. Kijk eerst of je het kunt oplossen met expliciete methodes, getypte value objects of extra PHPDoc.

Types opgeven voor Eloquent-modellen

Voor Eloquent-relaties en dynamische properties werkt de combinatie van @property en generics op relaties goed.

Automatisch uitvoeren in CI

Voer statische analyse niet alleen lokaal uit, maar altijd ook in CI. Zeker bij packages die meerdere Laravel-versies ondersteunen kun je, met dezelfde aanpak als de testmatrix in Versiecompatibiliteit van packages beheren, compatibiliteit en typeveiligheid tegelijk bewaken. Hieronder een voorbeeld van .github/workflows/static-analysis.yml.
In dit voorbeeld gebruik je dezelfde Laravel/Testbench-combinatietabel als in je testmatrix. Als je met zowel tests als statische analyse dezelfde combinaties bewaakt, mis je minder snel de situatie waarin “de code wel draait, maar de types kapot zijn”.

Veelvoorkomende false positives en hoe je ermee omgaat

Vraag je bij een waarschuwing van de statische analyse eerst af of er type-informatie ontbreekt. Wat op een false positive lijkt, is in werkelijkheid vaak gewoon een tekort aan PHPDoc.

@phpstan-ignore-next-line

Bruikbaar als tijdelijke omweg, maar beperk het tot regels waarvan je zelf de reden kunt uitleggen.

ignoreErrors

Alleen overwegen wanneer dezelfde fout op meerdere plekken opduikt. Beperk altijd het pad en smoor niet met een slordige reguliere expressie alles in de kiem.

Aanpak die je eerst moet proberen

  1. PHPDoc toevoegen
  2. Returntypes van facades en relaties expliciet maken
  3. mixed vervangen door concrete types
  4. Alleen de false positives negeren die je kunt verantwoorden

Gerelateerde pagina’s

Laravel-packages ontwikkelen

Bekijk de basis van een package-implementatie, inclusief service providers en gepubliceerde resources.

Laravel-packages testen met Orchestra Testbench

Uitleg over de testinfrastructuur voor packages die je samen met statische analyse wilt gebruiken.

Versiecompatibiliteit van packages beheren

Bekijk de Laravel/PHP-compatibiliteitstabel en de matrixstrategie voor GitHub Actions.
Laatst gewijzigd op 6 september 2026