- What is shipmonk/phpstan-rules and what does it add to PHPStan?
- shipmonk/phpstan-rules is a Composer package containing about 40 extra-strict PHPStan rules that ShipMonk uses to fill gaps left by native PHPStan strictness. It targets issues such as unsafe comparisons, unsafe casts, and risky array key handling. The rules are opinionated but modular, so you can disable or reconfigure any rule that does not fit your project.
- How do I install shipmonk/phpstan-rules in a Laravel project?
- Install it as a dev dependency with composer require --dev shipmonk/phpstan-rules, then either use PHPStan's official extension-installer or manually include vendor/shipmonk/phpstan-rules/rules.neon in your phpstan.neon file. The setup requires minimal configuration changes. Pinning to ^4.4.1 picks up recent callable-resolution and nested-exception fixes.
- Does shipmonk/phpstan-rules support Laravel applications?
- It is a framework-agnostic PHPStan extension, so it works in Laravel codebases, but it does not ship built-in Laravel-specific rules for Eloquent models, Blade templates, or service container bindings. You configure it like any other PHPStan extension and manually extend rules where needed. It still targets patterns common in Laravel code, such as loose array handling and checked exceptions in closures used by queues and jobs.
- How do I disable or reconfigure a ShipMonk PHPStan rule?
- Under the parameters section and the shipmonkRules key, set a rule's enabled option to false or adjust its options, such as reportMixed: false for forbidUnsafeArrayKey. To disable all rules and enable only selected ones, set enableAllRules: false and enable individual rules. When overriding default arrays, use the exclamation mark syntax if you want to replace the defaults instead of merging with them.
- Which PHP versions are required for shipmonk/phpstan-rules?
- Most rules can run with PHPStan's supported PHP versions, but some rules are PHP 8.2+ only, such as enforceReadonlyPublicProperty. In projects running older PHP versions, disable those rules or gate them by version. Check the rule documentation and your PHPStan configuration before enabling the full rule set.
- Will shipmonk/phpstan-rules slow down my Laravel CI pipeline?
- About 40 additional rules can add overhead to PHPStan runs, especially in large legacy codebases. Mitigate this by parallelizing PHPStan runs, excluding tests and vendor directories, and phasing rules in gradually. Version 4.4.1 reduces false-positive noise for two high-friction rules, but you should still monitor CI duration after enabling the full set.
- Does shipmonk/phpstan-rules work with Laravel Pint and PestPHP?
- It is compatible alongside Laravel Pint and PestPHP, but there is no native integration with either tool. PHPStan runs separately from formatting and testing, typically in CI or through IDE plugins for PHPStorm and VS Code. Treat it as an additional static-analysis layer rather than a replacement for Pint or Pest.
- What false positives does shipmonk/phpstan-rules 4.4.1 fix?
- Version 4.4.1 fixes forbidCheckedExceptionInCallable by resolving the static-call caller type from expressions, which reduces incorrect reports around Laravel facades, static helpers, and container make or resolve patterns. It also fixes requirePreviousExceptionPass so exceptions passed to nested calls are accepted, reducing noise in rethrow and job-retry code. Some residual risk remains for rules such as enforceEnumMatch and forbidCast, which can be mitigated with blacklist exceptions or targeted disabling.
- Is shipmonk/phpstan-rules a replacement for native PHPStan strict rules?
- No. It is designed to complement native PHPStan strictness and fill missing gaps rather than replace PHPStan's built-in rules or baseline workflow. You still need a normal PHPStan setup, and you should expect to disable or tune opinionated rules that do not fit your team. It also does not provide Laravel-specific analysis out of the box.
- How should I maintain shipmonk/phpstan-rules in a legacy Laravel codebase?
- Pin to ^4.4.1 to receive the recent false-positive fixes, then phase strict rules in gradually, starting with warn-only behavior where possible. Monitor PHPStan version compatibility and custom stub files, because some rules depend on PHPStan internals or manual stub management. Revisit old mitigations after upgrades, since fixes in 4.4.1 may make some allowed-exception configuration unnecessary.