Dummy Provider Laravel Package

Product Decisions This Supports

• Test strategy / test-double architecture. This package backs a specific decision: instead of mocking a DI provider with a mocking framework, you inject a real object that satisfies the provider contract and registers nothing. That keeps tests typed, refactor-safe, and free of framework-mocking ceremony. It supports a decision to prefer fakes over mocks for infrastructure contracts.
• Build vs. buy (and the answer here is "build"). With 7 stars, 0 dependents, and a surface area that amounts to a no-op implementation of one interface, this is not a dependency decision — it's a pattern decision. The rational product call is to copy the pattern into your own tests/Support folder in ~20 lines and avoid a third-party dependency entirely.
• Package/library API design. If your team publishes internal PHP packages that accept a provider, logger, or config interface, shipping a no-op default alongside it is a genuine DX win: consumers can instantiate your package in a test or a scaffold without wiring real bindings. This informs whether your own interfaces should have documented null-object implementations.
• Scaffolding and starter templates (roadmap input). Null-object providers make good defaults in generated project skeletons and in "add this package" recipes, because they keep setup explicit and side-effect free — no accidental service registration, no order-dependent config.
• Framework-mismatch triage. This is a Yii 3 (yiisoft/*) package, not Laravel. For a Laravel codebase the direct value is essentially zero; the transferable asset is the null-object provider idiom, which Laravel already approximates via empty service providers, $this->instance() bindings, and container fakes. Frame any adoption proposal as "pattern, not package."
• Dependency-surface hygiene. Given 0 dependents and a single-maintainer, low-traffic repo, this is a candidate for an explicit "do not vendor" note in your engineering standards — useful precedent when teams reflexively composer require trivial utilities.

When to Consider This Package

Consider it (or, more accurately, consider its pattern) when all of the following hold:

• The codebase is on Yii 3 / yiisoft/* and the target code type-hints the framework's provider contract. Outside that ecosystem, the class will not satisfy your container's expected interface without an adapter, at which point writing your own is cheaper.
• You are contract-testing a family of provider implementations and need a neutral, do-nothing member of that family to prove the consumer handles "provider that registers nothing" correctly.
• You are authoring a package that requires a provider instance and want a discoverable, dependency-free default for downstream test suites.
• You want zero runtime overhead and no config side effects — the package registers nothing by design, so it cannot perturb ordering or bindings.
• You are comfortable that the BSD-3-Clause license and a July 2025 release are the only maintenance signals available.

Look elsewhere — i.e., write your own stub — when:

• You are on Laravel or Symfony. There is no first-class fit; use framework-native fakes ($this->instance(), empty service providers, Mail::fake()-style doubles) or a two-line anonymous class implementing the interface.
• You need community support, security response, or a maintenance guarantee. 7 stars and 0 dependents means no downstream pressure to fix anything; you are the maintainer in practice.
• The interface you need to satisfy is your own, not Yii's — a local null object is clearer to reviewers than a transitive Yii dependency in a non-Yii project.
• Your org has a dependency-approval bar (license review, SBOM, supply-chain checks) that costs more than the utility delivers. This package will fail any reasonable cost/benefit test.

How to Pitch It (Stakeholders)

To executives — recommendation: do not adopt as a dependency; adopt the pattern.

This is a very small, permissively licensed (BSD-3-Clause) Yii utility that provides a deliberate no-op implementation for testing. It carries essentially no runtime risk — it registers nothing and adds no overhead — but also negligible strategic value: 7 GitHub stars, zero dependent projects, and a code surface small enough to reimplement in an afternoon. The correct decision is to standardize the null-object provider idiom in our own test scaffolding and internal package templates, and decline the third-party dependency. Net cost: near zero. Net benefit: cleaner test isolation and fewer brittle mocks in DI-adjacent code. The main caveat for the room: this is a Yii package, not Laravel — for our Laravel services the deliverable is a convention in our engineering guidelines, not a Composer require.

To engineering — the actionable takeaway.

• Do not add yiisoft/dummy-provider to Laravel services. No compatible contract, no dependents, no maintainer leverage if it breaks.
• Do add a NullProvider (or equivalent) to the shared test-support namespace: implements your provider interface, registers nothing, documented as "safe default for tests and scaffolds." Roughly 20 lines, fully under our control.
• Use it where you currently mock a container/provider: it removes mock-framework coupling, survives interface refactors, and makes "this consumer tolerates an empty provider" an explicit, asserted contract.
• Pair it with a contract test so every real provider and the null provider share one test suite. That's where the actual quality gain is; the package is just evidence the pattern is idiomatic in the wider PHP ecosystem.
• Revisit only if we migrate to Yii 3, where the upstream type would then match ours directly.