Phpstan Frankenphp Laravel Package

Technical Evaluation

Architecture fit. Unchanged by v1.3.2. The package is a PHPStan custom-rules extension, not a runtime library. That is the right shape: FrankenPHP worker mode breaks applications through persistent process state (static properties, globals, singletons, request-scoped container bindings, in-memory caches), and static analysis is the cheapest way to find those hazards before they become cross-request data leaks. The level-split design (classic-mode rules, then worker-mode rules) mirrors the migration sequence and supports ratcheting. Note that v1.3.2's docs/PSR.md change explicitly describes the extension as AST-only — this is not a runtime instrument, and it does not claim to be. Zero production footprint, zero container changes, still true.

Integration feasibility. Unchanged. require-dev, one includes: entry in phpstan.neon, level selector. Sub-day for a team already running PHPStan; a team not running PHPStan is buying a static-analysis program, not a package. New in v1.3.2: the demo application's composer.lock / symfony.lock are now tracked, which makes the reference demo reproducible — you can clone, run the demo, and verify rule behavior against a pinned dependency set rather than trusting the README. Use that as the pre-adoption smoke test.

Technical risk.

• Adoption risk (primary, unchanged). Still 0 stars, 0 dependents, single maintainer. v1.3.2 demonstrates the repo is actively maintained (good — abandonment risk ticks down slightly), but 1.3.x versioning with zero external consumers remains the anomaly. Treat the ruleset as a high-quality starting point you may need to own, not as a supported dependency.
• Rule correctness risk (unchanged). Worker-mode hazards are partially opinionated: long-lived DB connections, set_time_limit, exit, output buffering, $_SERVER mutation, register_shutdown_function, header(), container scoping all have legitimate exceptions. False positives remain the dominant complaint and the main driver of bypass behavior. v1.3.2 ships no rule-behavior changes, so no re-triage is required on upgrade from 1.3.x.
• Framework-blindness risk (now confirmed, not speculative). The AST-only design stated in docs/PSR.md means the rules do not resolve Laravel's scoped bindings, Octane-style Request lifecycle, facade state, or queue-worker vs. web-worker distinctions through the type system. They will catch syntactic hazards and miss container- and facade-mediated state. This promotes the previous "expect gaps" to "plan for gaps."
• API coupling risk. PHPStan's rule API moved between 1.x and 2.x; custom rules are directly exposed to that churn. v1.3.2 still states no PHPStan major compatibility policy — the single most important unresolved question.
• PHP floor ambiguity. The Rector config now targets PhpVersion::PHP_82 for the package's own toolchain. That is evidence of a PHP 8.2 floor for development, not a declared support matrix for consumers. Confirm against your application's PHP minor before integrating.
• Metadata anomaly (partially mitigated). The recorded last release date (2026-10-13) postdating the evaluation window is still unexplained, but v1.3.2 landing now is consistent with a live, actively released project rather than a stale index. Treat as an indexing quirk unless a tag/commit mismatch shows up, but still verify tags against commit history (v1.3.2 → 943010b) before adding to a dependency graph.

Key questions.

1. Which PHPStan major versions (1.x/2.x) and PHP versions are supported, and is that pinned or floating? (v1.3.2 narrows the PHP side to "≥8.2 for dev tooling" but does not declare a consumer support matrix.)
2. Does it ship a proper rules.neon, and can individual rules be disabled or parameterized (e.g., ignore set_time_limit in a CLI-only path)?
3. How does it behave under --generate-baseline? Is the intended workflow baselining legacy debt, and does it respect ignoreErrors with identifiers?
4. Does it resolve Laravel/Larastan types? Answered in v1.3.2: no — docs/PSR.md describes the extension as AST-only. Budget for gaps on container- and facade-mediated state.
5. What is the rule inventory per level, and are the demos executable fixtures in CI? Partially answered in v1.3.2: a Demo smoke workflow now runs on tags, weekly, and manually — so the demos are executed, but not on every PR. Per-PR rule regression coverage remains unproven.
6. Is worker-mode readiness scoped to per-request leakage only, or does it also cover graceful shutdown, preloading, and long-running-connection health?
7. Who maintains it, and is there a stated compatibility policy? Partially answered: docs/SECURITY.md now documents attack surface, threat model, dependency policy, and an AI security audit checklist — useful for security sign-off. Still no stated PHPStan compatibility policy or issue-response commitment.

Integration Approach

Stack fit. Unchanged: Laravel + PHPStan/Larastan + CI, as an additional ruleset in the existing analysis job. No application, autoload, or deploy-pipeline changes. The only stack prerequisite remains an existing PHPStan baseline — without one, pre-existing violations swamp the signal.

Migration path.

1. Baseline first. Ensure PHPStan/Larastan is green (or baselined) at the current level. Adding a ruleset to a red baseline teaches the team to ignore it.
2. Validate locally against the pinned demo. New in v1.3.2: the demo's lockfiles are tracked, so you can reproduce the maintainer's environment exactly and confirm which rules fire on known-bad code before committing to a version. Do this once, record the rule count and output, and keep that transcript as your "is it actually running?" assertion for later.
3. Container switch precedes rules. Move staging to the FrankenPHP image in classic mode — behaviorally close to PHP-FPM, so expect Caddy-specific surprises (.htaccess ignored, $_SERVER key differences, DOCUMENT_ROOT/SCRIPT_FILENAME paths, getallheaders) rather than application logic failures.
4. Classic-mode rules as advisory. Run non-blocking for 2–4 weeks, triage false positives, file or fork fixes.
5. Worker-mode rules as blocking, per-directory. Enable level-by-level and path-by-path, using ignoreErrors with identifiers for justified exceptions, then burn down the baseline.
6. Only then enable worker mode in staging, with a concurrent-request load test to catch state bleed the AST-only rules cannot see.

Compatibility. No breaking changes in v1.3.2 and no rule behavior changes, so upgrading from 1.3.x is low-risk. The release does not resolve the PHPStan-major question — verify against your exact PHPStan major, Larastan version, and PHP minor before committing, and pin rather than float. Watch for duplicated or contradictory diagnostics when stacking other community rulesets; PHPStan does not always attribute the source cleanly.

Sequencing recommendation. Unchanged. Pilot on one non-critical service with a single owner. Gate go/no-go on two numbers: false-positive rate per 1k findings, and percentage of worker-mode hazards found by the rules that manual review also found (recall proxy). Given the confirmed AST-only design, set the recall expectation lower for Laravel-heavy code and plan the fork decision in advance — MIT license makes it cheap.

Operational Impact

Maintenance. Dev-only dependency; zero production runtime, no image or memory changes. Ongoing cost is small and predictable: pin the version, re-validate on every PHPStan major, budget a few hours per PHPStan upgrade cycle. v1.3.2 adds a small amount of your maintenance surface — a new Cursor rule file and extra docs — but nothing that runs. The tracked demo lockfiles slightly reduce triage time, because you can reproduce maintainer behavior instead of reasoning from README prose.

Support. Still the weakest dimension. Zero community, zero dependents, no vendor. The docs/SECURITY.md addition is a genuine improvement for internal security review — it gives you a documented threat model and dependency policy to cite — but it is a document about the project, not a support commitment from the project. There will still be no upstream fix for your false positive on a Tuesday. Mitigation is unchanged and explicit: either (a) accept ownership and fork, budgeting ~1–2 engineer-days per quarter for rule upkeep, or (b) restrict to the subset of rules with clear-cut semantics and hand-write the Laravel-specific ones.

Scaling. Analysis cost scales with PHPStan, not the package — incremental-cached and parallelizable, seconds to low minutes on a mid-size Laravel monolith. CI-time cost, not a production-scaling concern. The scaling pressure that matters is organizational: each additional blocking rule increases the chance someone adds a suppression to ship. Track suppression count as a leading indicator.

Failure modes.

• False negatives (highest severity). Confirmed AST-only, so container- and facade-mediated state is structurally out of reach. A missed leak in worker mode is a cross-request data exposure — a security incident, not a bug. Rules cannot be the only control; pair with a concurrent-request load test and state-focused code review.
• False positives (highest frequency). CI friction leads to blanket ignores, converting the tool into theater. Curate the baseline actively; use the demo lockfiles to distinguish "our code is odd" from "the rule is wrong."
• Abandonment. Maintainer goes quiet, PHPStan ships a breaking change, rules stop loading mid-migration. Pin and vendor.
• Silent misconfiguration. A ruleset that fails to load or is scoped to the wrong paths produces a green build that checks nothing. Assert the rule count against a known-bad fixture in your own CI — do not rely on the upstream demos, which now run only on tags, weekly, and manual dispatch, so a regression can land on main and sit until the next scheduled run.
• Framework drift. Laravel or FrankenPHP changes worker semantics; the rules encode yesterday's model. Re-review at each major framework upgrade — especially given AST-only analysis, which will not infer new lifecycle behavior.

Ramp-up. Low for developers: per-case demos remain the right documentation format, now with a reproducible pinned environment, and PHPStan output is already familiar. Under a day to a first useful run. The real ramp-up cost sits with whoever owns the migration: interpreting worker-mode findings, judging which are real, and sequencing remediation. Allocate roughly one sprint for the pilot plus triage, and name a single owner before adoption — with no community behind the package, an unowned ruleset in CI is a future red build with no one to call.