Event Bus Laravel Package

Technical Evaluation

What we are evaluating. innmind/event-bus is a small, framework-agnostic event dispatcher from the Innmind functional-PHP ecosystem (Baptiste Langlade). It is MIT licensed, has zero stars, zero dependents, and is archived. The supplied score of 0 with an opportunity score of 19.28 is consistent with a package that has failed an automated health gate: no adoption signal, no maintenance signal, no upstream support path.

Architecture fit. Poor for a Laravel application, for three structural reasons:

1. Duplicate eventing spine. Laravel already ships a first-class dispatcher (Illuminate\Events\Dispatcher, Illuminate\Contracts\Bus\Dispatcher) wired into the container, queues, broadcasting, model events, subscribers, and testing helpers (Event::fake()). Introducing a second bus means two registration mechanisms, two dispatch paths, and an ambiguous answer to "where does this listener live?" That is a durable source of production defects, not a stylistic preference.
2. Non-idiomatic abstraction model. Innmind libraries are built around immutable collections and monadic types (Sequence, Set, Maybe, Either) rather than Laravel's container-resolved, type-hinted listeners. Interop requires a hand-written adapter layer: mapping native events into Innmind value objects, resolving listeners from the Laravel container, and translating error states back into exceptions the framework's handler can see.
3. No persistence or transport story of its own. An in-process dispatcher gives you synchronous, same-request fan-out. Anything beyond that — queues, retries, dead-lettering — must be supplied by us, at which point the package is contributing very little relative to the integration cost.

The one defensible fit: a framework-agnostic domain layer inside a larger monorepo where every bounded context already uses Innmind conventions. That is not our codebase.

Technical risk.

Key questions to resolve before any further work.

• Is there an active fork or successor project under a different namespace? (Check Innmind's org for a replacement before assuming abandonment is terminal.)
• What PHP versions and dependency constraints does the final release declare, and does it install cleanly on our current PHP runtime?
• Does it support asynchronous delivery through any adapter (AMQP, filesystem, OS process), or is it strictly in-process?
• What are its guarantees on listener ordering, exception propagation, and partial-failure semantics? These determine whether it is usable for anything transactional.
• Is any existing internal code already depending on it transitively? (composer why innmind/event-bus)
• Who would own a fork, and is there a business case for that ownership versus a maintained alternative?

Integration Approach

Stack fit. Ranked against realistic alternatives for our Laravel services:

Recommendation. Do not take a runtime dependency. Use the package as a design reference: it is a compact, readable example of a dispatcher contract, and reviewing its interface is a legitimate half-day exercise for an engineer designing our own port. Zero stars and an archived status mean there is no reputational or support cost to skipping it, and no community expectation to honor.

Migration path (if a team has already prototyped with it).

1. Inventory every event class and listener registered outside Laravel's dispatcher. This is the real cost driver and should be timeboxed to two days.
2. Define an internal port — a narrow DomainEventBus interface owned by us (dispatch(object $event): void), with no Innmind types in the signature. Every call site depends on this, never on the package.
3. Implement the port against Laravel's dispatcher, with ShouldQueue listeners for anything doing I/O.
4. Adapter, not rewrite — if a prototype must keep running, write a thin adapter implementing the port over the package, clearly marked temporary.
5. Pilot one bounded context, run it for a release cycle, compare listener-failure behavior and trace coverage against the native path.
6. Retire the adapter once the pilot is clean; delete the dependency from composer.json so composer audit and abandoned-package checks stay green.

Compatibility. Verify PHP constraint satisfaction and PSR-4 autoloading on our target runtime. Because the package is archived, assume the declared constraints reflect PHP 8.0–8.1 era tooling; a composer update on a future PHP minor is a likely break. Any adoption must include a lockfile pin plus a CI job that installs from a clean cache.

Sequencing. Architecture decision record first (1 week), port definition second (1 week), pilot third (1 sprint), rollout per bounded context afterward. Do not sequence this ahead of any work that depends on the event contract being stable — the contract, not the library, is the deliverable.

Operational Impact

Maintenance. Archived status transfers all maintenance to us. Realistically that means vendoring the source into the repo or forking it, which converts a "free" dependency into an owned asset with an assigned maintainer, a patch process, and a review obligation on every PHP upgrade. Budget roughly 2–5 engineer-days per year for a stable fork, materially more if we extend it. That is the true cost against which the "it's free and MIT" framing should be judged.

Support. No upstream issues, no CVE feed, no documentation beyond source, no community. Any incident is debugged from first principles by whoever is on call. For a payments-adjacent or customer-facing path this alone should disqualify it; for an internal tool it is survivable but still a tax.

Scaling. A pure in-process dispatcher scales only with the request lifecycle: fan-out cost is paid synchronously inside the user's request, so latency and failure blast radius both grow with listener count. Horizontal scaling of the app does nothing for listener throughput. Any real async requirement — retries, backpressure, isolation — must be built on top, at which point Laravel's queue-backed listeners or Symfony Messenger deliver more for less.

Failure modes to design against.

• Listener exception aborts dispatch mid-fan-out, leaving later listeners unrun with no record of who was skipped.
• No retry or dead-letter semantics; a failed side effect is simply lost unless we add persistence.
• Silent listener misregistration — no container integration means typos fail quietly at runtime rather than at boot.
• Ordering guarantees unknown; do not build state machines on top without verifying.
• Duplicate delivery risk if we later layer a transport underneath, since no idempotency key notion exists in the contract.
• Memory growth on large event payloads held in immutable collections during synchronous fan-out.

Ramp-up. The functional idioms (Sequence, Maybe/Either, immutability) are unfamiliar to most Laravel engineers. Expect 2–4 weeks before a mid-level developer is productive and, more importantly, expect review friction: the code will not look like the rest of the codebase, and reviewers cannot pattern-match against existing services. This is a recurring cost, not a one-time one.

Bottom line. This is a reference implementation, not a dependency. The event contract is worth owning; this package is not. Recommend closing the evaluation with a "no-adopt, reference-only" decision recorded in the ADR, and redirecting the effort toward the internal DomainEventBus port plus Laravel's native dispatcher.