Phpstan Extension Laravel Package

Technical Evaluation

Architecture fit: This is a developer-tooling package, not a Laravel runtime dependency. Its architecture fits teams that already standardize on PHPStan/Larastan and want to encode static-analysis metadata through PHP attributes. Because it plugs into PHPStan’s extension model, it should have minimal application-architecture impact and no production runtime footprint. Its fit is narrow: if the team does not already use custom static-analysis attributes, the package adds little value.

Integration feasibility: Feasible as a require-dev Composer dependency plus a PHPStan config include. The main integration work is validating PHPStan/PHP version compatibility, confirming behavior with Larastan, and ensuring attribute autoloading and extension ordering are correct. No database, queue, or Laravel service-provider changes should be required.

Technical risk: Runtime risk is low because the package is CI/dev-only. The larger risks are supply-chain and maintainability: the repository is unknown, adoption is very low (15 stars), and the package appears niche. Compatibility risk is concentrated around PHPStan major versions and Larastan interaction. There is also a semantic risk: if attributes are not well documented or enforced consistently, teams may get false confidence from static analysis.

Key questions:

• Which PHP and PHPStan versions are supported, and is Larastan explicitly tested?
• What exact attributes are recognized, and what analysis behavior do they change?
• Who maintains the package, and what is the release/security policy?
• Does it require custom bootstrap/autoload configuration in Laravel projects?
• Can it be adopted incrementally without creating noisy CI failures?
• What is the performance impact on a medium-to-large Laravel codebase?
• Is the implementation small enough to fork or internalize if abandoned?

Integration Approach

Stack fit: Reasonable for Laravel teams using PHPStan, especially with Larastan in CI. It should be treated as an optional analysis-quality enhancement, not a platform dependency. The package is not Laravel-specific, so its value is determined by the team’s static-analysis conventions rather than the framework version.

Migration path: Start with a proof of concept in a non-blocking CI job or a single module. Add the package under require-dev, include its PHPStan extension config, and compare findings against the existing baseline. If useful, introduce attributes for a small set of domain invariants and expand only after documenting semantics and ownership.

Compatibility: Pin the package version and validate against the project’s PHPStan, Larastan, PHP, and Composer platform constraints. Test extension include order with existing PHPStan configuration. Avoid adopting during a PHPStan major-version upgrade; isolate variables.

Sequencing:

1. Inventory current PHPStan/Larastan versions and CI analysis gates.
2. Run a time-boxed proof of concept on one bounded Laravel module.
3. Confirm supported attributes and expected findings with maintainers/source.
4. Add require-dev dependency and PHPStan config include behind a pinned version.
5. Establish a baseline and document attribute conventions.
6. Promote to a blocking CI gate only after false-positive/noise review.
7. Monitor upstream releases and maintain an internal fork contingency.

Operational Impact

Maintenance: Low code footprint but elevated stewardship risk due to unknown repository provenance and low adoption. Pin versions, review changelogs, and assign an internal owner. If the package becomes important, plan to fork or vendor it.

Support: Expect community-only support with no SLA. Internal documentation should capture supported attributes, configuration, and upgrade steps. Avoid making it a critical-path dependency without a named maintainer.

Scaling: Static analysis scales with codebase size and PHPStan configuration more than with this extension. Attribute usage can proliferate and become inconsistent, so establish naming, scope, and review rules. Monitor CI duration after adoption.

Failure modes: PHPStan/Larastan version incompatibility, silent non-recognition of attributes, false positives/negatives, CI breakage after Composer updates, abandoned upstream maintenance, and config include-order conflicts. Mitigate with pinned versions, a canary CI job, baseline comparison, and a fork/removal plan.

Ramp-up: Low for teams already fluent in PHPStan; moderate for teams new to static-analysis attributes. A proof of concept should take days, with broader rollout over one sprint. Training should focus on attribute semantics and when not to use them.