- What does wyrihaximus/phpstan-react do?
- It is a PHPStan extension for ReactPHP codebases. It flags blocking PHP functions such as fopen, file_get_contents, file_put_contents, fclose, and file_exists, and points to async replacements from react/filesystem and react/socket. Version 3.0 also encodes ReactPHP event-loop idioms and analyzes async/await usage through closures and call graphs. It adds no runtime behavior; it only reports issues during static analysis.
- Does this extension work in a standard Laravel application?
- It can be installed, but it adds little value in a conventional Laravel request/response app because there is no ReactPHP event loop or blocking-I/O pattern to replace. Its rules bind to ReactPHP code, so a standard Laravel app mostly pays extra analysis time. Use it only where a Laravel codebase contains an isolated ReactPHP worker or async subsystem. Laravel Octane uses Swoole or RoadRunner, not ReactPHP, so Octane alone is not a reason to add it.
- How do I install wyrihaximus/phpstan-react?
- Install it as a dev dependency with composer require --dev wyrihaximus/phpstan-react. If phpstan/extension-installer is installed, PHPStan loads the extension automatically. Otherwise add vendor/wyrihaximus/phpstan-react/extension.neon to the includes section of your phpstan.neon file. Version 3.0 corrected the documented include path, so older examples may be wrong.
- Which PHP and PHPStan versions does version 3.0 require?
- Version 3.0 requires PHP 8.4 or newer and an existing PHPStan setup with a NEON configuration surface. Because this is a PHPStan extension, it must also be compatible with the PHPStan major and minor version you run. Check the composer.json constraint before upgrading, since 3.0 may raise the PHPStan floor beyond what you use today. Re-verify release metadata on Packagist if version or date consistency matters to your team.
- How do I disable or tune specific rules from this ReactPHP PHPStan extension?
- In version 3.0 all rules ship enabled by default but can be tuned individually under parameters.wyrihaximus.reactphp.rules in your NEON config. That lets you adopt or suppress event-loop rules separately from async rules without dropping the package. For partial adoption, scope PHPStan paths to the async directories instead of enabling the extension globally. Prefer narrow, commented suppressions over disabling entire rule categories.
- Why does it report LoopInterface injection as an error?
- Version 3.0 encodes the ReactPHP idiom that the event loop is a global runtime concern rather than a constructor dependency. It forbids injecting, passing, or storing LoopInterface, rejects Loop::get() indirection, and detects promoted properties or traits that hold loop references in domain models. This is an opinionated architectural boundary and can conflict with adapters, test doubles, or libraries that accept a loop for dependency injection. Expect to suppress those legitimate cases explicitly.
- Will upgrading from 2.x to 3.0 break my existing PHPStan baseline?
- It likely will surface new errors, because 3.0 adds rules that are enabled by default. Teams pinned to ^2 are insulated until they choose to upgrade; teams on a floating constraint are not. Run 3.0 in CI first, then generate a baseline or tune rule categories before merging. Pin the major version in composer.json and upgrade deliberately rather than floating.
- Does wyrihaximus/phpstan-react support Laravel Octane?
- No. Laravel Octane runs on Swoole or RoadRunner and does not use ReactPHP, so this extension's event-loop and blocking-I/O rules do not apply. It will not improve static analysis for Octane applications. Use it only for actual ReactPHP services, long-running workers, or libraries from the ReactPHP and clue ecosystem.
- How do I avoid false positives when I intentionally inject a loop for testing?
- Tune or disable the specific rule under parameters.wyrihaximus.reactphp.rules, or add targeted ignoreErrors entries in phpstan.neon. Prefer narrow suppressions with comments over turning off the whole extension. For adapters and testing doubles, scope rules to application paths rather than test or vendor code. Review each suppression because the default rule set is intentionally strict.
- Is wyrihaximus/phpstan-react actively maintained and safe for production CI?
- Maintenance is thin: there are two contributors, most pull requests are Renovate dependency and QA tooling updates, and there is effectively one human maintainer. Adoption signals are limited, so defect discovery will largely be your own. Alternatives include PHPStan's built-in checks, custom PHPStan rules for your own ReactPHP conventions, or other community ReactPHP rules, though coverage may differ. Pin a version and run it in CI before relying on it broadly.