Event Bus Laravel Package

Product Decisions This Supports

• Build vs. buy for the eventing layer. This package is a candidate for the "buy" column when evaluating whether to hand-roll a domain-event dispatcher. In practice it forces the decision toward Laravel's native Illuminate\Contracts\Events\Dispatcher, which already ships with the framework, is queue-aware, and has first-class testing helpers (Event::fake()). The real product decision the evaluation surfaces is "do we need a third-party dispatcher at all?" — and the answer for a Laravel codebase is almost always no.
• Architecture direction: domain events vs. direct service calls. Reviewing a package like this is a prompt to decide whether the roadmap includes decoupling modules through events (order placed → inventory reserved → notification queued) or whether an explicit service-layer call graph is sufficient. The package's existence does not change that decision; the team's coupling pain does.
• Async/queue strategy. Any event bus decision is downstream of how work gets deferred. If the roadmap includes outbox patterns, retries, dead-letter handling, and ordering guarantees, the evaluation should compare Laravel Queues + Horizon, Symfony Messenger, or Ecotone — not a zero-adoption micro-library.
• Dependency policy and supply-chain posture. Zero stars, zero dependents, and an archived repository are concrete inputs into a "no unmaintained dependencies in production paths" policy. This is a governance decision, not a feature decision — and it is the most defensible outcome of this review.
• Reference design for internal conventions. Even without adoption, the package is useful as a reading input for how to shape explicit handler registration and immutable event objects. It can inform an internal RFC on naming, payload shape, and listener ownership without becoming a dependency.
• Non-decision to document. A short "evaluated and rejected" note in the architecture decision record prevents the same package being re-proposed six months later by someone who saw it on a list.

When to Consider This Package

Adoption criteria (all would need to hold simultaneously):

• The team is already inside the Innmind ecosystem and standardizing on its functional-PHP conventions — immutable data structures, explicit composition, minimal framework magic.
• The application is not Laravel-first, or the team has deliberately opted out of the framework's container and event dispatcher for the domain layer.
• There is a hard requirement for an explicit, container-free dispatcher where every listener is registered by hand and nothing is auto-discovered by string class name.
• Someone on the team is willing to fork and maintain it, accepting ownership of security patches and future PHP version compatibility.
• The scope is small and bounded — a handful of in-process domain events, no distributed semantics, no persistence requirements.

When to look elsewhere (the default position):

• Any Laravel application. Illuminate\Contracts\Events\Dispatcher already covers in-process dispatch, queueing via ShouldQueue, broadcasting, wildcard listeners, and test faking. Adding a second dispatcher creates two event systems, two mental models, and a class of bugs where events fire on one bus and listeners are registered on the other.
• The repository is archived. No security advisories, no PHP 8.3/8.4 compatibility commitments, no issue triage. An archived dependency in a production path is an unowned liability.
• You need anything beyond fire-and-forget in-process dispatch. Look at Laravel Queues + Horizon for deferred work, Symfony Messenger for transport abstraction with retries and failure transports, or Ecotone/Broadway if event sourcing or a persistent outbox is genuinely on the roadmap.
• You need observability. No maintained instrumentation story for tracing, metrics, or structured listener failure reporting.
• You need a community to hire from. Zero stars and zero dependents means zero answers on Stack Overflow and no candidate who has used it.

Verdict for the ADR: reject for adoption; retain as a design reference. The opportunity score (~19/100) and the archive flag are consistent with that reading — this is a library whose value has been absorbed by better-maintained, framework-native alternatives.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version: We evaluated innmind/event-bus as a possible component for decoupling parts of the product through events. Recommendation: do not adopt. It is a free, MIT-licensed library, but it is archived, has no downstream users, and duplicates functionality Laravel already provides out of the box. Adopting it would add a maintenance liability — someone internally would effectively own a dead open-source project — with no offsetting capability. The cost of not adopting is zero; the cost of adopting is a permanent, low-grade maintenance tax plus a second eventing model for engineers to learn. No budget or headcount is requested. We recommend standardizing on the framework's native event dispatcher and documenting this evaluation so it is not revisited.

For engineering leads — the technical summary: The library gives you an explicit, container-free dispatcher with hand-registered listeners. That is a legitimate design preference, but it is not one we can act on here: it belongs to the Innmind functional-PHP ecosystem, it is archived, and it has no dependents. In a Laravel codebase it would sit alongside Illuminate\Contracts\Events\Dispatcher, not replace it, giving us two dispatch paths and a predictable crop of "why didn't my listener fire" incidents. If what you actually want is explicit listener wiring, we can get 90% of it with a service provider that registers every listener by hand and a lint rule banning string-based auto-discovery — same architectural benefit, zero new dependencies. If what you want is async, retries, and dead-lettering, that is a different conversation: Symfony Messenger or Laravel Queues + Horizon, both of which we should scope properly rather than solve with a micro-library.

What we are asking for: sign-off on the no-adopt recommendation, and agreement that the underlying need — "our modules are too coupled" or "we need reliable async event handling" — gets its own ticket with a proper options analysis. The package is not the problem worth solving; the coupling is.