Null Laravel Package

Product Decisions This Supports

• Async/messaging architecture sequencing. This is a null transport — a mock implementation of the Queue Interop contract that discards messages by design. It supports the decision to build async features against an interface first (notifications, exports, webhooks, report generation) and defer broker selection (Redis, RabbitMQ, SQS) until volume and reliability requirements are proven.
• Build vs. buy the messaging seam. It is not a queue product; it's a test double. The real decision it informs is whether to abstract queue producers/consumers behind Queue Interop (Enqueue) versus coupling directly to Laravel's queue API — a portability and vendor-lock-in call.
• Testing and CI strategy. Enables deterministic unit/integration tests and broker-free CI pipelines, reducing flaky tests caused by Redis/RabbitMQ availability and container orchestration.
• Roadmap phasing for MVPs. Lets you ship job-producing features early with "jobs appear to execute" behavior, then promote to a real broker by changing configuration/transport wiring rather than job logic.
• Feature-flag and dry-run use cases. Useful where work should be acknowledged but not persisted (smoke tests, demo environments, canary validation of job wiring).

Caveat for the roadmap: it is a development/testing utility, not a production messaging component. Treat it as a low-cost enabler of later decisions, not as the messaging platform itself.

When to Consider This Package

Adopt when:

• Your codebase already targets Enqueue / Queue Interop (or you intend to), so the null transport plugs into the same Context/TransportFactory abstraction used in production.
• You need a repeatable, zero-infrastructure test double for producers/consumers in unit tests and CI.
• You are running a multi-framework or polyglot stack where a broker-agnostic contract matters more than framework-native ergonomics.
• You are migrating brokers and want a stable no-broker baseline to keep the test suite green during transition.

Look elsewhere if:

• You are Laravel-only. Laravel ships sync and null queue drivers. In most Laravel apps the framework-native driver is simpler, better documented, and avoids pulling in an interop layer for a mock. The claim that this is a "drop-in Laravel queue driver" should be validated against your version before committing — it implements Queue Interop, not Laravel's Illuminate\Contracts\Queue factory.
• You need production messaging — persistence, retries, dead-letter queues, delayed delivery, monitoring, or distributed workers. This transport silently drops messages.
• You need observability or failure semantics in tests (timeouts, backoff, DLQ behavior); pair with a containerized real broker instead.
• Project maturity is a gate. The repository is a development monorepo with readme-level maturity and low dependent counts; weigh Bus Factor and long-term support against a lighter, in-house mock if your team is small or risk-averse.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed testing component, not a messaging platform purchase. It lets engineering build and validate background-job features — notifications, exports, integrations — without standing up or paying for a message broker in testing and CI. The strategic value is optionality: we can prove out async workflows cheaply now, then choose a production broker when usage justifies it, without rewriting job logic.

For engineering: enqueue/null is a mock Queue Interop transport that accepts and discards messages. Use it as the test/local transport inside the Enqueue abstraction so producers and consumers are exercised without a broker. Benefits: zero broker infrastructure in CI, deterministic tests, and interface parity with real transports so swapping to Redis/RabbitMQ/SQS is a wiring change. Guardrails: it is dev/test only — add an environment check so it cannot be deployed to production, and keep at least one integration suite running against a real broker to catch retry/DLQ/TTL assumptions. If we stay Laravel-native, compare against the built-in sync/null drivers first; adopt this only if the Queue Interop abstraction is a deliberate architectural choice.