- What is nunomaduro/laravel-code-analyse and how is it related to Larastan?
- It is presented as a Laravel static analysis tool built on Larastan, which is a phpstan/phpstan extension that understands Laravel-specific patterns such as Eloquent, facades, collections, and container resolution. The repository link points to larastan/larastan, so the Composer package name and the upstream project do not line up one-to-one. Treat the wrapper as a convenience layer for onboarding and Larastan as the durable engine underneath it. Confirm the canonical package name and publisher identity before adopting it beyond a pilot.
- How do I install and run Larastan in a Laravel application?
- Add it as a development dependency with Composer, since it is a development-time analysis tool and not runtime code. Create or update a phpstan.neon file pointing at your app directories, then run the analysis with vendor/bin/phpstan analyse or with the wrapper's artisan command as described in the package overview. No service provider, route, migration, or bootstrap change is required, so nothing in your application code needs to be modified for it to work.
- Which PHP, Laravel, and PHPStan versions does Larastan 3.13 require?
- Version 3.13.0 keeps the same PHP and Laravel requirements as 3.12.x, so it does not raise the platform floor. The hard constraint is inherited from the engine: PHPStan must be 2.3.0 or higher within the 2.x line. Check the package's composer.json for the exact PHP and Laravel ranges before pinning it in a legacy or long-lived application.
- Does Larastan change anything in production or at runtime?
- No. Larastan is a development-time PHPStan extension and contributes no routes, service providers, container bindings, migrations, or production code paths. It belongs in require-dev and should never be invoked in a deployed environment. Removing it is a single lockfile revert with no deployment window, no data migration, and no customer-visible behaviour change.
- How do I configure which paths and analysis level Larastan checks?
- Configuration lives in phpstan.neon or phpstan.neon.dist, where you define paths, level, and any Larastan-specific options such as model and relation discovery. If you adopt the wrapper, its opinionated defaults handle the initial setup, but those defaults should be reconciled with team policy rather than inherited as a black box. As soon as you need custom rules, stubs, or targeted suppressions you will be editing raw PHPStan configuration anyway, so plan for that.
- Can Larastan run in CI as a blocking gate rather than an advisory check?
- Yes, and the technical assessment recommends making it blocking, because diagnostics such as invalid eager-loading column selection combined with callbacks catch real correctness and performance pitfalls. Install it as a dev dependency, cache Composer downloads and PHPStan's result cache, and run it in a dedicated CI job. Budget review time for the first run after any upgrade, since improved inference can legitimately surface a delta of previously silent errors.
- What Laravel-specific issues does Larastan catch that plain PHPStan misses?
- Larastan adds Laravel-aware inference for Eloquent models, facades, collections, and container resolution, so PHPStan can reason about types it would otherwise treat as mixed. Version 3.13.0 adds a relation custom type and inferred relationship types inside with(), withOnly(), load(), and loadMissing(), plus corrected collection key types for concat(), merge(), shift(), and splice(). It also flags invalid eager-loading column selection combined with callbacks, such as with(['posts:id' => $callback]), and resolves forwarded builder calls through toBase(), which matters for repositories with custom query builders.
- How do I handle existing errors when first adopting Larastan?
- Use PHPStan's baseline feature to record current errors so the gate starts clean, then shrink that baseline over time as you fix issues or raise the analysis level. The wrapper is described as handling baselines out of the box, which is one of its onboarding advantages for repositories with no analysis today. Avoid permanently baselining whole categories of checks, because that undermines the value of a blocking gate.
- What are the alternatives to Larastan and what should I verify before an organisation-wide rollout?
- The realistic alternatives are plain PHPStan without the Laravel extension, another static analyser such as Psalm, or the wrapper package layered on top of Larastan. Before going beyond a pilot, verify provenance: the Composer name, the larastan/larastan repository URL, the reported dependents, and a future-dated release do not currently line up, which is a governance concern rather than a tooling preference. Also decide explicitly whether you standardise on the upstream engine or the wrapper, since mixing them across repositories creates divergent profiles and two upgrade cadences.
- How should I upgrade Larastan and PHPStan together?
- Ship PHPStan and Larastan in a single pull request, because a split upgrade can leave Larastan resolving against an unsupported PHPStan version, which is a broken intermediate state worse than not upgrading at all. Treat the coupled bump as a scheduled maintenance item rather than an opportunistic merge. Version 3.13.0 itself is additive with no removals or config-breaking changes, but the PHPStan 2.3.0-or-higher constraint within the 2.x line still governs the upgrade.