Infection Static Analysis Plugin Laravel Package

Product Decisions This Supports

• Test-strategy investment: Decides whether to spend engineering time on mutation testing for high-risk PHP/Laravel domain code, especially where type signatures already express intent.
• Quality-gate design: Informs whether mutation score should become a CI/release gate for critical modules (billing, auth, pricing, permissions) versus a nightly signal.
• Build vs. buy for internal tooling: Offers a ready-made bridge between Infection mutation testing and Psalm static analysis, avoiding an internal build — but with known maintenance and compatibility trade-offs.
• Roadmap prioritization: Helps prioritize hardening of typed service/domain layers over writing tests that only catch mutants already invalid under static analysis.
• CI budget decisions: Supports decisions about running mutation testing on changed files or nightly rather than every pull request, because the plugin is explicitly slower than Infection alone.
• Upgrade planning: Surfaces a dependency-risk decision: the plugin pins specific Infection versions and lags behind upstream releases, so PHP/Infection upgrade timing must account for it.
• Laravel use-case targeting: Most valuable for Laravel applications with a strongly typed domain layer and Psalm annotations, not for framework glue, Blade views, or legacy untyped code.

When to Consider This Package

Consider it when:

• The team already uses infection/infection and wants higher-signal mutation results without writing tests for mutants that violate type declarations.
• The codebase has meaningful Psalm coverage and type annotations, particularly in extracted domain/services or reusable PHP packages.
• CI can absorb slower mutation runs, at least initially as a nightly or targeted job.
• The team accepts that the plugin is “hacky,” replaces vendor/bin/infection, and pins Infection to specific versions.
• You want a low-cost experiment to measure whether static-analysis-killed mutants reduce unnecessary test effort.
• You can tolerate upgrade lag and monitor compatibility with PHP, Infection, and Psalm releases.

Look elsewhere when:

• You are not using Infection, or your static analysis standard is PHPStan/Larastan only — current scope is Psalm-first.
• The codebase is mostly untyped Laravel glue code, legacy PHP, or tests where static analysis adds little mutation-killing value.
• CI runtime is already constrained and mutation testing is not an established practice.
• You need a stable, vendor-supported plugin API rather than a tool that relies on Infection internals.
• The team cannot own dependency pins, upgrade testing, and fallback to plain Infection.
• A native Infection plugin or a simpler static-analysis/mutation workflow becomes available.

How to Pitch It (Stakeholders)

Executive summary: This is a targeted engineering-quality tool, not a production dependency. It improves mutation-testing signal by treating type-invalid mutants as killed, which can reduce wasted test-writing effort and raise confidence in typed, high-risk Laravel/PHP modules. License cost is low (MIT), but adoption carries CI-time and maintenance costs. Given its maturity signals — modest adoption, no listed dependents, aggressive Infection integration, Psalm-only support, and version pinning — position it as a pilot for critical domain code, not a platform-wide mandate.

Engineering summary: Add roave/infection-static-analysis-plugin as a dev dependency, run vendor/bin/roave-infection-static-analysis-plugin instead of vendor/bin/infection, and provide --psalm-config. Start on a nightly or changed-files job, compare mutation score and escaped mutants before/after, and track CI minutes. Keep plain Infection as a fallback. The main risks are Infection version pinning, slower runs, and dependence on Psalm; the main benefit is fewer low-value tests for mutants that static analysis would reject anyway.

Stakeholder recommendation: Approve a time-boxed pilot on one or two business-critical, well-typed modules. Success criteria: measurable mutation-score improvement, reduced escaped mutants requiring new tests, acceptable CI cost, and no blocked PHP/Infection upgrades. If those hold, expand selectively; otherwise keep standard Infection/static-analysis practices and revisit when native plugin support exists.