- How do I install wyrihaximus/phpstan-rules-wrapper in a Laravel project?
- Run composer require wyrihaximus/phpstan-rules-wrapper in the same project as PHPStan. The package works out of the box when phpstan/extension-installer is present, so you do not need to add each bundled ruleset manually. Laravel needs no special service provider or bootstrap step. Make sure the project meets the PHP 8.4+ requirement enforced since v12.0.0.
- Which Laravel and PHP versions are supported by this PHPStan rules wrapper?
- The wrapper is not Laravel-version-specific; it is a PHPStan extension, so Laravel support depends mainly on your PHP and PHPStan versions. Since v12.0.0 it requires PHP 8.4+, which may mean upgrading if you are on an older Laravel 10.x setup that still runs PHP 8.2. Confirm your Laravel version, PHPStan version, and PHP runtime all satisfy their own constraints before adding it.
- Which PHPStan rulesets are included in wyrihaximus/phpstan-rules-wrapper?
- It bundles ergebnis/phpstan-rules, phpstan/phpstan-deprecation-rules, phpstan/phpstan-mockery, phpstan/phpstan-phpunit, phpstan/phpstan-strict-rules, shipmonk/dead-code-detector, shipmonk/phpstan-rules, symplify/phpstan-extensions, staabm/phpstan-psr3, tomasvotruba/type-coverage, and wyrihaximus/phpstan-no-safe. These are generic PHP and testing-oriented rule sets, not Laravel-specific checks. The exact resolved versions come from the wrapper's Composer constraints.
- Does this package work out of the box with phpstan/extension-installer?
- Yes, it is designed to work with minimal setup because phpstan/extension-installer automatically registers the bundled extensions. You generally only need to install the package and run PHPStan with your existing configuration. You can still add includes, levels, ignoreErrors, or excludes in phpstan.neon as needed. No Laravel-specific configuration is required by the wrapper.
- How do I disable or customize bundled PHPStan rules in a Laravel project?
- Customize rules through your PHPStan configuration rather than editing the package, using level settings, ignoreErrors, excludes, and rule-specific parameters where supported. Some bundled rules are disabled by default because of known conflicts, such as ergebnis/noPhpstanIgnore, so review the disabled rules list before assuming full coverage. For persistent exceptions, document them in phpstan.neon and revisit them during upgrades. Avoid forking the wrapper unless you need a rule set removed entirely.
- Does this wrapper include Laravel-specific PHPStan rules such as Larastan checks?
- The listed bundled rulesets do not include Laravel-specific checks such as hardcoded configuration detection or framework-aware model analysis. For Laravel-focused analysis you typically add a separate extension such as Larastan alongside this wrapper. This package remains useful for strict PHP, deprecation, dead-code, PHPUnit, Mockery, PSR-3, and type-coverage checks. Verify rule overlap and conflicts when combining extensions.
- How much does this PHPStan rules wrapper affect CI performance in a Laravel app?
- PHPStan static analysis adds CPU and memory use to CI, and bundling more rules can increase runtime on large Laravel codebases. Benchmark your current PHPStan run before and after enabling the wrapper, then use PHPStan's result cache and parallel execution if needed. The 14.10.1 release only bumps phpstan/phpstan-phpunit to ^2.1.1, so it does not materially change the analysis footprint by itself. New upstream checks can still surface new errors after a composer update.
- Is wyrihaximus/phpstan-rules-wrapper actively maintained and safe for production CI?
- The wrapper is actively maintained, with 14.10.1 released on 2026-06-08 as a dependency-only patch. Its high-frequency, bot-driven release cadence is good evidence of maintenance, but it also means rule behavior can shift through upstream dependencies. For production CI, pin a known-good version and review composer updates. Treat new PHPStan findings as part of the upgrade process rather than assuming the wrapper is stable by default.
- What are the alternatives to using a PHPStan rules wrapper versus installing rulesets manually?
- Installing the rulesets manually gives you direct control over each Composer constraint and avoids a single wrapper as a point of failure. This wrapper reduces dependency sprawl and setup work by bundling more than ten rule sets behind one require. The tradeoff is that the wrapper, not your composer.json, decides which upstream lines you resolve for bundled packages. Choose manual installation if you need to swap or version individual rule sets independently.
- How should I upgrade from version 13 to 14 and test this PHPStan wrapper safely?
- The assessment baseline was 13.1.0 and the current line is 14.x, with 14.10.1 changing only the phpstan-phpunit constraint; no breaking change was documented in that release note. Pin the wrapper to ^14 or an exact version, run composer update in a branch, and compare PHPStan output before merging. Watch for silent rule drift from upstream phpstan-phpunit updates that can create CI failures unrelated to your code. Re-evaluate the disabled-rules list and Laravel/PHPStan compatibility on every major bump.