Dummy Provider Laravel Package

Technical Evaluation

Architecture fit. The first thing a TPM needs to surface is a framework mismatch: this is a Yii 3 (yiisoft) package, not a Laravel package. It implements the Yiisoft provider/"definitions" contract and registers nothing, so a container can be constructed with an explicit but empty set of service definitions. Laravel's equivalent primitive is Illuminate\Support\ServiceProvider, whose register() and boot() methods are already no-ops by default. Architecturally, the package solves a problem Laravel does not have — a no-op Laravel provider is roughly ten lines of code we would own outright. Fit for our stack: essentially zero.

Integration feasibility. Composer will install it fine (BSD-3-Clause, PHP-only, no extension requirements), but doing so drags Yiisoft DI contracts into a Laravel codebase for no functional gain. There is no adapter path where a Yiisoft provider participates in Laravel's container lifecycle without bespoke bridging code that costs more than the problem it solves. Realistically this is a read-and-reimplement candidate, not an adopt candidate.

Technical risk. Intrinsic risk is low — the description is honest about being a tiny side-effect-free test double, with no runtime overhead. The risk that matters is portfolio and supply-chain: 7 stars, 0 dependents, a composite score of 0.095, and an opportunity score of 38.83 all point to a package with almost no production signal. There is no evidence of downstream validation, which for a testing utility means we cannot lean on community burn-in. An abandoned micro-dependency is not catastrophic, but it is noise in a dependency manifest and a puzzle for the next engineer who audits it.

Key questions. (1) Do we operate any Yii 3 services at all, or is this an evaluation artefact? (2) Is the actual need "a provider that registers nothing in tests," and if so why isn't a local stub sufficient? (3) Who owns the decision to add a cross-framework dependency, and is there a policy on single-digit-star packages? (4) Does the team's test strategy already cover this via Laravel's container-swap and mocking facilities?

Integration Approach

Stack fit. Poor for Laravel, adequate for Yii 3. In Yii the value is real: tests and scaffolding can inject an explicit empty provider instead of a partially configured one, which keeps setup honest. In Laravel the same intent is expressed with $this->app->instance(...), $this->mock(...), or an empty ServiceProvider subclass. Our existing test suite already covers this ground.

Migration path. There is nothing to migrate from unless we have legacy Yii components. If we do, adopt it there and keep it out of Laravel services. If we do not, the correct migration is a pattern port: create an internal NullServiceProvider (or a documented testing convention) in our own test-support package, cite this repository as prior art, and move on.

Compatibility. PHP-level compatibility is likely fine against Laravel 10/11/12 runtimes, but contract-level compatibility is not — the provider interface belongs to the Yiisoft DI world and has no Laravel counterpart. Version pinning would be arbitrary since no other package constrains it.

Sequencing. (1) Confirm whether any Yii footprint exists in the estate — this is a one-hour spike. (2) If no, close the evaluation with a written "not adopted, pattern borrowed" note so the assessment is reusable. (3) If yes, confine adoption to those Yii services behind the existing Composer boundary and record the rationale. (4) In parallel, add the internal no-op provider convention to the platform testing guide so the need does not resurface per team.

Operational Impact

Maintenance. Trivial in isolation — the code surface is minimal and BSD-3-Clause is commercially safe with no copyleft obligations. The maintenance cost is not in the package but in the cognitive tax: every future reader of composer.json has to determine why a Yii package is present in a Laravel service. That question recurs at every audit, upgrade, and onboarding.

Support. Yiisoft is a community organisation with no commercial SLA. For a package with 7 stars and no dependents, expect best-effort responsiveness at most. We should assume we are effectively self-supporting and must be comfortable patching a fork if needed.

Scaling. Irrelevant — the package does no work at runtime, so it neither helps nor hinders throughput, cold-start, or container warm-up. Its only scaling dimension is organisational: how many teams copy the pattern versus import the dependency.

Failure modes. The realistic failures are not runtime crashes: (a) architectural drift, where a Yii dependency becomes a precedent for further cross-framework imports; (b) false confidence, where an empty provider masks a misconfigured test that should have failed loudly; (c) abandonment, leaving an unmaintained pin in the manifest; (d) version friction during a PHP or framework upgrade with no upstream incentive to support our combination. None are severe, all are avoidable by not taking the dependency.

Ramp-up. Near-zero for anyone who understands DI; the description is accurate and the concept is one sentence. That is precisely the argument against adoption — the learning cost of the package is not lower than the cost of writing the stub, and the stub keeps ownership, licensing, and framework alignment internal. Recommendation: do not adopt; borrow the pattern.