Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Peststan Laravel Package

mrpunyapal/peststan

PHPStan extension for Pest PHP that adds type-safe expectations, proper $this binding in test closures, generic expect() inference, type-narrowing assertions, and accurate return types for all Pest functions. Requires PHP 8.2+, PHPStan 2, Pest 3-5.

View on GitHub
Deep Wiki
Context7

PhpStan support for Pest

Frequently asked questions about Peststan
What is PestStan and what problem does it solve for Laravel projects?
PestStan is a PHPStan 2 extension for Pest PHP that provides generic expect() inference, proper $this binding inside test closures, type-narrowing assertions, and accurate return types for Pest functions. It also registers custom rules for common Pest test issues. It improves static analysis signal for the test half of a Laravel codebase, which is often excluded or left untyped.
How do I install PestStan in a Laravel application?
Install it as a dev dependency with composer require --dev mrpunyapal/peststan. If phpstan/extension-installer is present, it registers automatically; otherwise add vendor/mrpunyapal/peststan/extension.neon to the includes section of phpstan.neon or phpstan.neon.dist. Confirm the package is excluded from production autoload and --no-dev deploys.
What PHP, PHPStan, and Pest versions does PestStan support?
PestStan requires PHP ^8.2, PHPStan ^2.0, and Pest ^3.0, ^4.0, or ^5.0. Teams still on PHPStan 1.x or Pest 2.x are out of scope. You should also account for PHPStan and Pest upgrade plans over the next 12 months, because future majors may require pinning or replacement.
Does PestStan affect production behaviour or runtime performance?
No. PestStan is a pure static-analysis extension with no runtime code, no service provider, and no config publish step. It sits entirely in the dev and CI layer, so it cannot affect production behaviour. Keep it in require-dev and verify it is not included in --no-dev production installs.
How does PestStan resolve $this inside Pest test closures?
It infers $this binding by reading uses(TestCase::class)->in('...') from tests/Pest.php and applying that information to matching test closures. This detection is heuristic and path-scoped, so monorepos or multiple test roots may produce mixed or unbound $this. Validate that per-directory uses() detection resolves correctly for your Laravel test tree before enforcing rules.
What custom PHPStan rules and error identifiers does PestStan register?
PestStan registers approximately 15 custom rules with stable identifiers such as pest.test.emptyClosure, pest.expectation.impossible, pest.lifecycle.beforeAllThisUsage, pest.expectation.redundant, and pest.test.staticClosure. These cover issues like empty closures, duplicate descriptions, impossible or redundant assertions, and $this usage in beforeAll. Identifiers are useful for targeted baselines and ignore entries.
Can I configure PestStan rule behaviour?
Yes, PestStan supports an optional parameters.peststan.* block in your PHPStan configuration for rule parameters. Most teams can start with the defaults and adjust only when a specific rule proves noisy. Prefer targeted configuration or identifier-level ignores over blanket ignoreErrors entries.
Should I enable PestStan on an existing Laravel test suite with a PHPStan baseline?
Expect remediation work rather than a simple config change. Start with a spike branch, capture the full diagnostic delta against main, and count new errors by identifier and directory before deciding to adopt. Then commit the config without enforcing, generate baselines scoped per identifier, and ratchet gradually.
PestStan is archived; is it still safe to adopt or is there a maintained fork?
The package is archived, has zero dependents, and has low social proof, so there is no community safety net. It relies on PHPStan extension and custom-rule APIs that can change across majors, meaning PHPStan 3.x or Pest 6.x could break it silently with nobody upstream fixing it. The README points to the official Pest PHPStan plugin, so evaluate that and check for a maintained fork before committing long term.
What are the alternatives to PestStan for analysing Pest tests with PHPStan?
The README recommends checking the official Pest PHPStan plugin, which is the primary alternative to evaluate. You can also rely on native Pest and PHPStan support where available, or write your own stubs and custom rules for expect() and $this binding. Compare maintenance status, rule coverage, and compatibility with your planned PHPStan and Pest versions before choosing.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
socialdept/tenant-domains
tautvydasr/blade-class-names
socialdept/color-scales
maherelgamil/controller
coleus/widgets
coleus/table
coleus/users
coleus/music
coleus/health
coleus/calendar
coleus/notes
coleus/support
coleus/settings
coleus/apps
seampact/laravel
emmyconceptng/laravel-ng-postcode
jjsquady/round-robin
skyraptor/chatter
edlugz/sasapay
abbasudo/artisan-route