Dummy Provider Laravel Package

Getting Started

Install (dev only):

composer require --dev yiisoft/dummy-provider

Where to look first: the package is essentially a single class implementing Yii's ProviderInterface (the contract with getDefinitions() and getExtensions()), each returning an empty array. Read that class before anything else — it's tiny, and confirms the contract is a pure no-op.

First use case: you have a test (or scaffolding step) for a class whose constructor type-hints a provider, and you want zero registrations — no bindings, no extensions, no side effects. Pass new DummyProvider() instead of a real ConfigProvider:

$service = new SomeService(new DummyProvider());

Important framing for a Laravel developer: this is a Yii contract, not a Laravel one. The direct dependency only pays off when you are testing Yii-shaped code — a ported package, a Yii/ Laravel monorepo, or code that was originally written against Yii DI. For pure Laravel work the day-to-day value is the pattern (null-object provider), not the package.

Implementation Patterns

1. Null-object injection in unit tests. The primary pattern: replace a provider dependency with the dummy so the test exercises the subject without dragging in any real service definitions. This keeps tests explicit and free of unrelated container state.

2. Isolating config from bindings. When a class both accepts providers and receives definitions, using the dummy proves the code path under test doesn't secretly depend on registered definitions — a useful regression guard.

3. Decorate/spy variant. Because the concrete is small, subclass it when you need light instrumentation:

final class SpyProvider extends DummyProvider
{
    public int $calls = 0;
    public function getDefinitions(): array { $this->calls++; return []; }
}

4. Yii config wiring. In a Yii config, list the dummy in the providers array to keep the array shape explicit while registering nothing — handy in scaffolded configs and example apps.

5. The Laravel analogue. In Laravel code you don't require this; you reproduce the pattern with a bare service-provider subclass or a container binding:

// tests/Support/NullServiceProvider.php
final class NullServiceProvider extends ServiceProvider {
    public function register(): void {}
    public function boot(): void {}
}
// or bind a no-op implementation to an interface
$this->app->instance(FooContract::class, new NullFoo());

6. Package-author testing. If you maintain a package that accepts a provider to stay framework-agnostic, use the dummy in your own test suite so consumers don't have to ship fixture config just to instantiate your classes.

Integration tip: keep it in require-dev and out of production autoloaders. If your CI matrix covers both Yii and Laravel projects, isolate the Yii-specific tests behind a guard so the dependency doesn't leak into Laravel suites.

Gotchas and Tips

• Silent emptiness. It registers nothing, so failures surface as missing definitions later, not as an obvious "you used the dummy" error. Tests can pass vacuously — assert behavior, not just construction.
• It is not a mock. There is no expects() API. If you need interaction assertions ("getDefinitions() was called exactly once"), use Mockery against the real interface or a hand-rolled spy (pattern 3).
• Interface mismatch. It satisfies a Yii contract; it will not satisfy Illuminate\Support\ServiceProvider type hints. Do not type-hint it in Laravel application code — bind an implementation of your interface instead.
• Empty array vs. null. If downstream code distinguishes "no definitions" from "null," verify the exact return shape before relying on branch behavior in tests.
• Low bus factor. Seven stars, zero dependents, a single 2025 release. The class is roughly ten lines — if long-term supply-chain comfort matters, vendor it or reimplement rather than take the dependency.
• Lifecycle differences. A bare Laravel ServiceProvider subclass still participates in register()/boot() ordering; a Yii dummy provider is a true null object. Don't conflate the two when porting tests across frameworks.
• Extension points: subclass for spies, or wrap a real provider in a decorator that delegates to the dummy for specific methods when you only want to neutralize part of the registration surface.
• Pin the version in composer.json and re-read the class after any bump — the package's whole contract is small enough that an update is worth a two-minute diff.