Null Laravel Package

Product Decisions This Supports

• Marginal build-vs-buy call for test doubles. The package supplies a no-op QueueInterface implementation for the PSR queue draft. Its only real job is to absorb push() calls without side effects — a job our test suite already solves with Queue::fake() and PHPUnit mocks.
• Interop/ports-and-adapters decisions, not product decisions. This is useful only if we deliberately adopt PSR queue interfaces as our domain boundary (e.g., a hexagonal MessageBus port with a production adapter and a null adapter). That is an architecture decision we would make first; the package is a downstream consequence.
• Not a roadmap input. With zero stars, zero dependents, last release Feb 2024, and MIT-only maintenance surface, it does not signal ecosystem direction. It tells us nothing about where the market is going, so it should not influence prioritization.
• Use cases it could serve if we ever need them: smoke-testing a consumer pipeline end-to-end without a broker; seeding an in-memory queue for integration tests of worker loops; providing a "black hole" queue in preview/staging environments where we want the app to boot but not dispatch.
• Feature decision it does clarify: our own dispatching should stay behind a thin port. If dispatching is behind an interface, swapping in a null adapter is a five-line class we own — which removes the reason to take a dependency at all.

When to Consider This Package

Consider it only when all of the following hold:

• The codebase targets PSR queue interfaces rather than Illuminate\Contracts\Queue\Factory. Laravel's queue system does not implement PSR queue, so in a standard Laravel app this package has no natural insertion point.
• We are writing tests that exercise a PSR-typed collaborator and want a dependency-free stub instead of an in-test anonymous class.
• We accept ownership risk on an unmaintained single-purpose package — the realistic mitigation is vendoring the ~1 class rather than requiring it.

Look elsewhere (or just don't) when:

• Any standard Laravel queue need. Use the built-in null queue driver for "pretend to dispatch," the sync driver for inline execution, and Queue::fake() / Bus::fake() for assertions. These are first-party, documented, and covered by our existing test conventions.
• We need a real fake with assertions (did we dispatch? with what payload?) — Queue::fake() + Queue::assertPushed() is strictly more capable than a null sink.
• The need is broker-free integration testing. A real in-memory transport (e.g., sync or a database queue with SQLite) gives us failure modes; a null queue gives us silence and will happily hide dropped jobs.
• Maintenance or security posture matters — no release cadence, no dependents, no signal of a maintainer response to issues.

Adoption cost is low in absolute terms, but so is the benefit; the honest verdict is build the five-line null adapter in-repo if the need appears, and skip the dependency.

How to Pitch It (Stakeholders)

To executives: This is a tiny test utility that makes a queue silently discard messages. We are not recommending adoption — it doesn't reduce engineering time, doesn't de-risk anything, and adds a third-party dependency for behavior Laravel already provides for free. No budget, no roadmap impact. Flagging it as "reviewed and declined" so the evaluation isn't repeated.

To engineering: If you want a no-op queue, use Laravel's null driver or Queue::fake(). Reach for this package only if we ever commit to PSR queue as an internal interface — and even then, write the stub ourselves rather than depending on a zero-star, single-class package whose entire content we could own in a few lines. The real takeaway is architectural: keep dispatching behind our own port so swapping in a null or synchronous adapter stays trivial and vendor-neutral.