Pest Plugin Phpstan Laravel Package

Technical Evaluation

Architecture fit Pest is a testing framework layered over PHPUnit that exposes a plugin contract for registering console options and commands. This package is a thin adapter: it surfaces PHPStan as an additional entrypoint inside the Pest binary (e.g. pest --phpstan), delegating the actual analysis to PHPStan's own application. It does not reimplement rules, config discovery, or reporting — PHPStan remains the source of truth. That is the correct separation of concerns, and it fits teams that have standardized on a single ./vendor/bin/pest quality-gate command.

Integration feasibility High. It is a require-dev Composer package, autodiscovered by Pest's plugin mechanism, requiring no application code changes. PHPStan must be installed separately — the plugin is glue, not a bundle. Realistic effort is hours, not days: install, confirm the flag runs, wire CI.

Technical risk Code-surface risk is low (single-purpose adapter). The material risks are coupling and maturity signals:

• The plugin must track two independent moving APIs — Pest's plugin contract (which shifted across Pest 2 → 3) and PHPStan's CLI surface (1.x → 2.x).
• 11 stars and a 0.365 composite score are weak provenance signals, partially offset by the pestphp vendor namespace. Repository metadata is reported as unknown, which blocks basic due diligence (commit recency, issue responsiveness, CI status).
• Worst case, the plugin is trivially replaceable by a direct vendor/bin/phpstan invocation, so blast radius is bounded.

Key questions

• What is the supported compatibility matrix — Pest 2/3, PHPStan 1/2, PHP versions?
• Does it honor phpstan.neon / .dist discovery and --configuration, --level, --baseline, --memory-limit, --error-format?
• Are exit codes propagated faithfully so CI gating is trustworthy?
• Does it compose cleanly with Larastan and with Pest's parallel/architecture-testing plugins?
• Is the plugin itself covered by CI, and what is the release cadence relative to Pest majors?

Integration Approach

Stack fit Native for any Composer-based PHP or Laravel codebase already on Pest. Zero runtime footprint — dev-only, never shipped. Pairs naturally with Larastan (Laravel rules) and with Pest's architecture testing to form a combined static + structural + behavioral gate.

Migration path Additive, not a migration. Existing vendor/bin/phpstan analyse CI steps keep working unchanged; the plugin adds an alternate entrypoint. Adoption can be staged: individual developer, then CI job, then team convention.

Compatibility Pin explicitly and validate the Pest major + PHPStan major + PHP version triple in a throwaway branch before merging. Confirm the plugin's Composer constraints do not conflict with locked PHPUnit/Pest versions.

Sequencing

1. Install and configure standalone PHPStan; establish a clean baseline at the target level.
2. Add the plugin; verify the Pest entrypoint produces analysis results identical to the direct CLI run.
3. Add an explicit, exit-code-gated CI step.
4. Only then fold it into the default local pest invocation — developer friction is the primary adoption killer.

Operational Impact

Maintenance Three things to keep aligned: Pest, PHPStan, and the glue. Budget a dependency-review pass whenever either major bumps. Because the package is thin, the fallback (direct CLI, or vendoring an equivalent adapter) should be documented up front.

Support MIT, community-maintained under an official-org namespace, no commercial backing. Low star count means few eyes on regressions — treat it as convenience, not critical path. Keep a direct PHPStan CI job as a safety net so a plugin regression cannot silently disable static analysis.

Scaling Analysis cost belongs to PHPStan, not the plugin. It grows with codebase size and rule level. Mitigate with PHPStan's result cache, tuned --memory-limit, path-scoped analysis on PRs, and full-repo analysis nightly.

Failure modes

• Pest upgrade breaks plugin registration → unknown-option error or silently absent flag. Catch with a CI smoke test.
• PHPStan major changes CLI args → unsupported flags passed through.
• Memory exhaustion on large repos → opaque failure if stderr is not surfaced.
• Exit code not propagated → green build despite analysis failures. This is the highest-severity mode; verify it explicitly rather than assuming.
• Abandonment: plugin stops tracking Pest releases. Mitigated by the direct-CLI fallback.

Ramp-up Near zero for developers already fluent in Pest and PHPStan — the only new surface is one flag. For the TPM: a half-day spike to validate the version matrix and exit-code behavior, then a one-line CI addition.