- How do I install nowo-tech/phpstan-frankenphp in a Laravel application?
- Install it as a development dependency with composer require --dev nowo-tech/phpstan-frankenphp, then add the include entry documented in the README to your phpstan.neon. No service provider, config publish, or container change is required because the package is a PHPStan ruleset, not a runtime library. You then select the rule level that matches your migration stage, classic or worker mode.
- Which PHPStan versions does this FrankenPHP ruleset support?
- Custom PHPStan rules are exposed to the rule API changes between PHPStan 1.x and 2.x, so check the composer.json constraint before installing. Do not assume the package works identically across both major versions. Pin PHPStan, Larastan, and this ruleset together in CI and upgrade them as a pair.
- Does this package support Laravel 10, 11, or 12?
- Laravel version support is mostly indirect because this is a PHPStan extension rather than a runtime package. It has no service provider, migrations, or framework hooks that would restrict your Laravel version. Check the PHP version constraint in composer.json against your application and confirm your PHPStan and Larastan versions are compatible.
- What FrankenPHP worker-mode problems do these PHPStan rules catch?
- The rules target persistent process state that breaks under worker mode, such as static properties, globals, singletons, request-scoped container bindings, and in-memory caches surviving between requests. They also flag patterns like exit calls, set_time_limit, header manipulation, $_SERVER mutation, register_shutdown_function, and long-lived connection handling. The aim is to surface cross-request data leaks and shutdown hazards during static analysis instead of in production.
- Why am I getting false positives on exit() or set_time_limit in CLI commands?
- Worker-mode hazards are partly opinionated, and calls like exit, set_time_limit, or output buffering are legitimate in console commands and other non-request paths. Check whether individual rules can be disabled or parameterized, and use PHPStan ignoreErrors with rule identifiers for the exceptions you accept. Budget time for tuning the ruleset before enforcing it as a hard CI failure.
- Can I use --generate-baseline with this ruleset for existing violations?
- Yes, provided the rules emit identifiers so PHPStan can record them in the baseline. The practical workflow is to baseline legacy classic-mode debt while fixing worker-mode violations outright, because those are the ones that become cross-request leaks. Confirm the package respects ignoreErrors identifiers before relying on baselining across upgrades.
- What do the split-by-level rules mean for migration?
- The rules are grouped by migration stage: first rules that help you move from PHP-FPM to FrankenPHP classic mode, then rules for worker mode. That mirrors the real migration sequence and lets a team ratchet adoption level by level instead of enabling everything at once. Run the classic level while stabilizing the container switch, then enable worker-mode rules before turning on worker mode.
- Does nowo-tech/phpstan-frankenphp work alongside Larastan?
- It is intended as an additional ruleset in the same PHPStan analysis job as Larastan, not a replacement. The caveat is framework awareness: a generic ruleset may not fully understand Laravel scoped bindings, facade state, or queue-worker versus web-worker distinctions, so expect gaps and false positives around Laravel idioms. Treat its findings as a starting point that your team validates.
- Does this package add runtime overhead or affect production deployments?
- No. It is a require-dev PHPStan extension with zero production footprint, so nothing changes in your application autoload, container image, or deploy pipeline. The only prerequisite is an existing PHPStan or Larastan job in CI, because a red baseline with no static analysis program will swamp the signal from these rules.
- Is nowo-tech/phpstan-frankenphp production-ready and actively maintained?
- The domain expertise is credible and the rule categories match real FrankenPHP migration hazards, but the package shows zero stars, zero dependents, and a single maintainer with no evidence of production use. Treat it as a high-quality starting point you may need to own rather than a supported dependency. Also verify the recorded release date and tags against the repository commit history before adding it to a dependency graph.