Phpstan Rule Test Helper Laravel Package

Product Decisions This Supports

• Build vs. buy for the internal lint layer. If your team is deciding whether to encode architectural conventions as custom PHPStan rules (e.g., "no Eloquent calls from controllers," "every Job must implement ShouldQueue," "no env() outside config"), this package directly affects the cost side of that equation. Writing a rule is the easy half; keeping it correct as the codebase evolves is the expensive half, and rule tests are what make a rule library sustainable rather than a source of false positives that engineers learn to ignore.
• Investment in static analysis as a platform, not a one-off config. Most Laravel teams stop at Larastan plus a strict ruleset. The step beyond that — a repo of org-specific rules — is a genuine platform investment. This helper is a small enabling piece of that roadmap: it lowers the per-rule maintenance cost from "bespoke container wiring every time" to "one test assertion per fixture."
• Feature-level quality gates. When a PM asks "can we guarantee new code in this module doesn't reach into another module's models?" the honest answer is either code review discipline (unreliable, unmeasurable) or an automated rule (reliable, testable). This package makes the automated answer cheaper to ship and defend.
• CI reliability and false-positive budget. Every custom rule is a new way CI can fail on valid code. Tested rules are the mechanism for keeping the false-positive rate near zero, which is the difference between a lint rule that survives six months and one that gets @phpstan-ignore'd into oblivion.
• Onboarding and documentation. Rule tests double as executable specifications of your conventions, which is more durable than a Confluence page nobody reads.

When to Consider This Package

Adopt it only if all of the following hold:

• You already run PHPStan (or Larastan) at a level where you have, or are about to have, custom rules in your own codebase — not just a shared config.
• You have more than a handful of custom rules, or expect to. For one or two rules, PHPStan's own RuleTestCase plus inline container setup is a few dozen lines you can write once and copy.
• You have a named owner for static analysis tooling, because a single-maintainer micro-dependency needs someone accountable for it.

Look elsewhere — or simply vendor the code — if:

• You don't write custom PHPStan rules. This is a no-op for you. Nothing here helps with Larastan configuration, baseline management, or CI wiring.
• You want ecosystem safety. One star, zero dependents, a single maintainer, and a very low overall assessment score. It is a thin convenience wrapper around PHPStan's own testing API. The pragmatic move for most teams is to read the source, copy the ~small surface you need into a tests/Support directory, and carry zero supply-chain or abandonment risk.
• You're on a team that treats dependencies as a reviewed budget. A dependency whose entire value is deleting twenty lines of boilerplate per test file rarely clears the bar unless it's used broadly.
• You expect PHPStan's testing API to keep moving. Any wrapper over RuleTestCase is inherently coupled to PHPStan internals; a low-traffic package is unlikely to keep pace as promptly as your PHPStan upgrade cadence requires.
• You're evaluating this as a Laravel-specific tool. It isn't. It's framework-agnostic PHPStan tooling, and the decision should be made by whoever owns static analysis, not by the Laravel application team.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small, free, MIT-licensed utility for testing the custom static-analysis rules we write ourselves. It doesn't touch the product or the customer experience; it reduces the engineering cost of enforcing our own code conventions automatically. It is not a strategic dependency, and the sensible default is to copy its few dozen lines of logic into our own test suite rather than take it on as a third-party package — we get the same productivity benefit with no maintenance or supply-chain exposure. Recommend: no formal adoption; treat it as reference material if we build out a custom rule library.

To engineering leadership: The real decision isn't this package, it's whether we're going to maintain a set of homegrown PHPStan rules. If yes, rule tests are non-negotiable and this helper removes friction — but it's a one-maintainer, near-zero-adoption wrapper over PHPStan's RuleTestCase. Either accept it as a low-stakes dev dependency with an owner, or vendor it and move on. If no, close the ticket.

To the engineering team: Useful if you're already fighting PHPStan's rule-testing boilerplate. Read the source first — it's small — and decide whether a dependency or a local copy is the better trade. Don't let it become an implicit commitment to building a rule library nobody has agreed to staff.