Technical Evaluation

Architecture fit: This is a dev-only PHPStan extension, not a runtime Laravel package. It fits as a static-analysis quality gate for teams already using PHPStan/Larastan and the companion php-language-extensions attributes. Best fit is domain/service code where explicit contracts such as purity, immutability, or visibility are valuable; weaker fit for framework-heavy code that relies on Eloquent magic, facades, and container resolution.
Integration feasibility: High for PHPStan-enabled repositories: add as a require-dev Composer dependency, include the extension in phpstan.neon, and run in CI. No production runtime, database, queue, or infrastructure changes. Feasibility drops sharply if PHPStan/Larastan is not already established.
Technical risk: Blast radius is limited to CI because the package does not execute in production. Primary risks are version coupling to PHPStan internals and the companion attribute package, single-maintainer/low-adoption maturity signals, false positives against Laravel dynamic patterns, and annotation churn if rules are enabled broadly before baselining.
Key questions: Which rules are opt-in versus default? What PHP, PHPStan, Larastan, and php-language-extensions versions are supported? Does it support baselines and per-path excludes? How noisy is it on Laravel/Eloquent code? What is the CI performance cost? Is the companion package required in production or only for analysis? What is the release and compatibility policy?

Integration Approach

Stack fit: Use only where PHPStan/Larastan is already part of the engineering workflow. Treat this as an additional static-analysis rule set, not a replacement for tests, Pint, Psalm, or runtime validation. Keep it in require-dev and out of production images.
Migration path: Pilot on one bounded module or new code path. Add the package and companion attributes, configure the PHPStan include, generate a baseline for existing violations, and enable rules incrementally. Document attribute conventions and review examples before expanding.
Compatibility: Pin PHPStan, Larastan, and php-language-extensions versions in composer.lock; validate against the project’s PHP version and CI matrix. Avoid floating major versions. Confirm the extension’s supported PHPStan range before each platform upgrade.
Sequencing: First confirm a clean PHPStan baseline. Then add the extension in non-blocking CI mode for a pilot module. Triage false positives and establish exclusions. Make it blocking for new/changed code, then expand to additional modules. Review dependency compatibility quarterly and after PHPStan/Laravel upgrades.

Maintenance: Low runtime maintenance but non-zero dependency maintenance. It must be upgraded alongside PHPStan/Larastan and the companion attribute package. Assign an internal owner for version bumps and rule configuration.
Support: MIT-licensed community package with low adoption and no commercial SLA. Expect best-effort upstream support. Mitigate with pinned versions, a documented fallback path, and the ability to disable the extension in CI without affecting production.
Scaling: Scales with CI capacity rather than application traffic. PHPStan result caching and parallel CI jobs matter more than the extension itself. Rule rollout should scale by module and code ownership, not by enabling all rules at once.
Failure modes: PHPStan upgrades breaking extension compatibility; false positives blocking builds; misconfigured includes silently doing nothing; missing companion attributes; Composer version conflicts; developers suppressing rules via baselines. All are CI-quality failures, not production outages.
Ramp-up: Low for teams fluent in PHPStan and static analysis; moderate for teams new to attribute-driven contracts. Provide onboarding examples, rule rationale, baseline policy, and code-review guidance. Expect initial annotation effort in existing code before steady-state value.