it adds support for Tomas Votruba's
type-coverage 0.2.x output format (in addition to 0.1.x) and adds support for couting of deprecated functions and properties
We've had an internal linter for years, which is built on a PHP #symphony framework.
You run the linter you want and append --fix if you want it to resolve issues (if it can)
It lints things like #JS, #SCSS as well as #PHP (via #Rector and #phpstan), #Composer files and even #TYPO3 TypoScript files - all by using the open source libraries available.
It means all our developers can adhere to central linting conventions without having to update local config files.
Analyze your native type coverage and #PHPStan baselines over time. Generate #reports to make sure managment knows what you achieved or define future goals.
New plugin for #PHP#Pest to give you type coverage right in Pest. Simply composer require pestphp/pest-plugin-type-coverage —dev and then run Pest with pest —type-coverage -min=100 Perhaps you won’t need #PHPStan or #LaraStan anymore.
I've read (somewhere on the internet) that it's possible to run #phpstan at level 9 with #laravel. But after messing around with it most of an evening, getting a clean run has eluded me. Can get a clean run up to level 7.
Most of the issues come from Auth and Profile related controllers that I'm pretty sure were generated by Breeze and have to do with not being able to get a read on User models when they're the result of calling $request->user().
Fixer v3.21.2 is a technical release with maaaaany DX improvements 🙂. Kuba Werłos took #PHPStan's strict rules on the table and improved many parts of the code. There are also other enhancements, just look at the release notes:
We talk with Matt Glaman about PhpStan and they whys and hows of using it in your day-to-day Drupal development. We also touch on his Drupal 7 compatibility layer experiment and his current writing project(s).
it may also be helpful for you, in case you don‘t use fully fledged orm. It covers your database access layer with #phpstan type inference based on the database schema
If all goes according to plan, a future #phpstan release will be able to resolve the return type and validate the parameter-types of a callable used in call_user_func().
To make sure you will no be bitten like me by code passing message_type=2 to error_log() - which fatal errors on PHP8+ ... I made a small #PHPStan fix so it gets reported.
DrupalEasy Podcast S15E3 - Matt Glaman - PhpStan and Retrofit (www.drupaleasy.com)
We talk with Matt Glaman about PhpStan and they whys and hows of using it in your day-to-day Drupal development. We also touch on his Drupal 7 compatibility layer experiment and his current writing project(s).
Using RuleErrorBuilder to enrich reported errors in custom rules (phpstan.org)
When writing custom rules for PHPStan, developers can either return plain strings or RuleError instances.