Larastan Livewire Laravel Package

Getting Started

1. Install as a dev dependency alongside Larastan/PHPStan:

   composer require --dev calebdw/larastan-livewire
   

2. Register the extension in phpstan.neon (or .dist). Because it builds on Larastan, include Larastan first, then this package:

   includes:
       - vendor/larastan/larastan/extension.neon
       - vendor/calebdw/larastan-livewire/extension.neon
   

3. Point PHPStan at your components and run:

   vendor/bin/phpstan analyse app/Livewire --level=5
   

Where to look first: the packaged extension.neon (it lists the registered services, type extensions, and rules — the fastest way to see what is actually wired up), then the src/ directory for the type extensions and rules, and tests/ for canonical usage examples. Check composer.json's require block to confirm it targets your Livewire 2 vs 3 and PHPStan major version.

First use case: run the analyser against a single component with public properties, mount(), actions, and a couple of $this->... calls. Before adding the extension you'll typically see "undefined property/method" noise on Livewire magic accessors; after including it those should resolve, confirming the install is live.

Implementation Patterns

• Scope the analysis to Livewire directories first. Run on app/Livewire (and app/Http/Livewire for Livewire 2 projects) at a moderate level, then widen paths and raise the level once the baseline is clean.
• Compose with Larastan, don't replace it. This package is an add-on to Larastan's Laravel-aware type inference; it fills the Livewire-specific gaps (dynamic properties, computed/action methods, component $this resolution). Keep Larastan's extension included.
• Declare authoritative types on properties. Livewire hydrates public properties from the request, so PHPStan treats them as user-controlled. Use native types plus @var/@property docblocks on the component to state the intended shape — the extension will then infer $this->foo consistently in actions, mount(), and tests.
• Model computed properties and actions. Type them so $this->someComputed() returns the right type inside other methods and inside your test cases. This is the biggest day-to-day payoff: Livewire::test(MyComponent::class)->call('doThing') chains become typed.
• Add to CI as a gate, not an afterthought. A typical job runs phpstan analyse --memory-limit=1G after composer install --no-progress and fails the build on error. Pair with a generated baseline only for legacy code, then shrink it.
• IDE integration comes for free. Anything the extension teaches PHPStan (type narrowing on $this->…) is also surfaced through PHPStan's language server / editor plugins, so you get completion and diagnostics on Livewire internals you'd otherwise fly blind on.
• Use the rules as a review aid. Run new/changed components through the analyser locally (phpstan analyse app/Livewire/Foo.php) before opening a PR — cheaper and faster feedback than the full-app CI run.
• Baseline per-directory when migrating. If you're introducing this to an existing app, generate a baseline for app/Livewire only, so new code is held to the stricter standard while legacy components are frozen.

Gotchas and Tips

• Include order matters. If you include this package's extension.neon before Larastan's, some services may not see the Laravel container types they depend on. Always put Larastan first.
• Version lockstep. The package is version-sensitive to PHPStan, Larastan, and Livewire majors. If you bump phpstan/phpstan or larastan/larastan, re-run the analyser against a known-good component before trusting results — silent inference regressions are more common than hard errors.
• Clear the result cache when changing config. vendor/bin/phpstan clear-result-cache after editing phpstan.neon or upgrading; stale caches produce confusing "no errors" runs.
• Dynamic properties vs declared properties. Livewire lets $this->anything resolve at runtime via magic methods, but PHPStan wants a declaration. Don't disable strictness to hide this — add the property or a @property docblock, otherwise you lose the type safety the extension is meant to give you.
• Hydrated properties are untrusted input. Livewire properties can be mutated from the browser; treat them as mixed at the boundary and validate before use. Don't silence PHPStan warnings about them — that's the bug class the analyser should catch.
• Blade templates are out of scope. wire:model bindings, wire:click actions, and $wire calls inside .blade.php are not type-checked by this extension. If you need that coverage, look at companion tooling (e.g., Blade-specific extensions) — don't assume this package covers them.
• Memory on large apps. PHPStan + Larastan + Livewire inference is heavy; raise --memory-limit or split analysis into multiple paths if you hit OOM.
• Debugging inference failures: run with -vvv and --debug to see which extensions ran and where a type went to mixed. If a property unexpectedly resolves to mixed, verify the component is actually discovered — a path outside the configured paths won't be analyzed at all.
• Extension points: you can register your own PHPStan\Rules\Rule implementations or DynamicMethodReturnTypeExtension services via an app-level phpstan.neon services: block. This is the clean way to teach PHPStan about project-specific base component classes or custom traits that the package can't know about.
• Don't fight the baseline. If you add the extension to a mature codebase, generate a baseline the first day and track its size over time; a baseline that grows after each PR is a signal the team is silencing real type issues rather than fixing them.