Placeholder Phpunit Laravel Package

Product Decisions This Supports

• Packaging / dependency architecture (build vs. buy-adjacent): This package lets us expose PHPUnit-shaped extension points — a base TestCase, custom constraints, listeners, data-provider helpers, assertion traits — from a library's production source without putting phpunit/phpunit in our require block. It directly informs the require vs. require-dev split for any library we ship.
• Whether to invest in a testing-integration surface at all. If we're deciding to add PHPUnit plugins/extensions or a "test helpers" companion package to our product, this is part of the "how do we ship it without bloating consumer installs" decision.
• Interop and compatibility roadmap. It forces an explicit answer to "which PHPUnit majors do we support?" — a real roadmap/compatibility commitment (PHPUnit 9 vs. 10 vs. 11 differ in namespaces, return types, static-ness, and attributes).
• Not a feature decision. This creates zero end-user value. It is a supply-chain/developer-experience tactic, and should be evaluated against engineering time, not against customer outcomes.

When to Consider This Package

Consider it when all of the following hold:

• We maintain a library or SDK, not an application, and consumers install us into production.
• Our non-test source must reference PHPUnit symbols — e.g. a trait that returns a MockObject, a base class extending TestCase, or a factory typed against a PHPUnit interface.
• We explicitly want composer require our/package to stay dependency-light for the majority of consumers who never run tests.
• We can afford to pin and CI-test against specific PHPUnit majors and re-verify on every PHPUnit release.

Look elsewhere when:

• We're building an application, not a distributable — just require-dev PHPUnit and be done.
• PHPUnit is already a hard runtime dependency anywhere in the tree; the placeholder then adds only collision risk (duplicate symbol definitions / autoload order surprises).
• We need behavior, not just signatures — placeholders provide no runner, no assertions, no mocks.
• Maintenance signal matters: this repository has no stars, no dependents, and effectively a bus factor of one. It is not a load-bearing dependency for anything important.
• A lower-risk alternative fits: PHPStan/IDE stub files, suggest + conflict entries in composer.json, or simply defining our own narrow interfaces and keeping PHPUnit at the boundary. These avoid the sync burden this package imposes on us.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost packaging decision, not a roadmap item and not a customer-facing feature. It's about keeping our library's install footprint small so non-test users aren't forced to download PHPUnit. Cost is a few hours of engineering plus a recurring compatibility check; upside is a cleaner dependency story and fewer "why is PHPUnit in my production tree" complaints. Risk is contained because it affects only test-time code paths — but the project we'd depend on is unmaintained, so we should treat it as a pattern to adopt, not a vendor to trust.

To engineering: We can publish PHPUnit extension points without a hard production dependency on PHPUnit, and without forcing every consumer to install it. The tradeoff is that we own keeping the placeholder's signatures in sync with PHPUnit's real API — a mismatch is a fatal error at class declaration time, and a co-installed real PHPUnit can collide on autoload. Gate this behind a CI matrix across the PHPUnit majors we claim to support, pin the placeholder version exactly, and keep it out of anything on the critical path. If the sync burden proves annoying after one release cycle, the fallback is PHPStan stubs plus our own narrow interfaces.