Event Dispatcher Laravel Package

Product Decisions This Supports

• Build vs. buy for eventing plumbing. This is commodity infrastructure with 8.5k stars, an MIT license, a decade of production use, and three maintained release lines (5.4, 6.4, 7.x, 8.x). The decision it should settle is "stop writing our own dispatcher," not "is this good enough" — it is.
• Clarifying what we already own in Laravel. Laravel ships illuminate/events (dispatcher, listeners, subscribers, queued listeners, wildcards). For a pure Laravel app, this package is not a capability upgrade. It becomes a real decision only in three cases: we consume third-party libraries that type-hint Symfony\Contracts\EventDispatcher\EventDispatcherInterface; we publish a package that must run on both Laravel and Symfony; or we want PSR-14 interop so listeners are portable across frameworks. Frame the decision as interop and dependency hygiene, not as a feature bet.
• Dependency-surface roadmapping. There are two adoption tiers worth putting in front of engineering: symfony/event-dispatcher-contracts (interfaces only, near-zero footprint) versus the full component (dispatcher, priorities, stoppable events, immutable and traceable decorators). Choosing the contracts-only tier now keeps the option open without paying for it.
• Extensibility and plugin strategy. If the roadmap includes customer-specific hooks, partner integrations, or a marketplace/add-on model, typed events plus priority-ordered listeners let third parties and internal teams extend behavior without forking core code. This is the strongest product argument for the component.
• Cross-cutting concerns without core churn. Logging, audit trails, notifications, rate limiting, and enrichment belong in listeners, not in service methods. This lets us ship policy changes (e.g., new audit requirements) as isolated, reviewable, individually disableable units.
• Team-scaling at module boundaries. Introducing events at seams (order placed, inventory changed, user verified) lets two teams work on either side of a boundary without coordinating method signatures — a prerequisite for later service extraction, if that ever becomes a roadmap item.
• Debug and support investment. TraceableEventDispatcher gives event-flow visibility and is the same tooling the Symfony profiler uses. Note for planning: recent patch releases fixed a memory leak in it for long-running processes and a reset-during-dispatch bug — relevant if we run queue workers, Octane, or long-lived CLI jobs.
• Platform baseline as a roadmap input. Symfony 8 requires PHP 8.4; 6.4 and 7.x remain supported. Picking a line is a PHP-version-policy decision that affects hiring, hosting, and library compatibility downstream — worth an explicit call rather than an accidental one.
• Commodity signal from the scoring. Opportunity score ~53 with a mid-50s composite says "ubiquitous, low differentiation." Treat it as a standards decision owned by the platform team, not an innovation item on the product roadmap.

When to Consider This Package

Adopt (or standardize on the contracts) when:

• You have direct, hard-coded calls between more than a handful of services and the coupling is measurably slowing delivery — new behavior requires edits in three or more unrelated classes.
• You consume Symfony-ecosystem libraries or want listeners that survive a future framework change; PSR-14 compliance is the concrete reason.
• You ship a library or internal platform package that must be framework-agnostic.
• You need decorators Laravel doesn't offer out of the box: an immutable dispatcher for sandboxed or test contexts, or a traceable dispatcher for debugging and profiling.
• You want attribute-based (#[AsEventListener]) typed listeners with priorities and stoppable propagation, and the team already has Symfony muscle memory.
• You want to avoid rebuilding an event bus — a real multi-month cost if done properly, though near zero in a Laravel app that already has one.

Look elsewhere when:

• The workload is trivial — a few listeners, or you're only using Laravel's built-in events. Adding a parallel dispatcher creates two event systems and confusion about which to use. That's a net negative.
• You need durable, cross-process messaging. This component is an in-process dispatcher. Deliverability, retries, ordering, and dead-letter handling belong to the queue (Laravel queues/Horizon) or a broker (RabbitMQ, Kafka, SNS/SQS). Don't let "event dispatcher" naming blur that line in a roadmap doc — it is the single most common scoping error here.
• You need low-latency or high-fanout pub/sub — Redis Pub/Sub, NATS, or Kafka.
• You already run a dedicated event bus and this would add a layer with no new capability.
• The codebase can't do constructor injection or is below PHP 8.1.
• You want managed support with SLAs. This is a volunteer-maintained Symfony monorepo subtree split: issues and PRs live in symfony/symfony, not in this repo, so support means community channels plus commercial Symfony vendors.

Data caveats before you commit to a slide: the "0 dependents" figure in the snapshot is almost certainly an artifact — this is among the most-depended-on PHP packages in the ecosystem — and the changelog is dominated by "no significant changes," which reads as stability, not stagnation. Re-verify both before quoting them.

How to Pitch It (Stakeholders)

To executives — one paragraph: "This is mature, MIT-licensed plumbing that lets parts of our application broadcast 'this happened' and lets other parts react without being wired directly together. It's the same component underneath Symfony and a large share of the PHP ecosystem, so the risk of adopting it is close to zero and the cost is close to zero. The honest caveat: our Laravel app already has an equivalent built in, so this isn't new capability — it's a standards decision. It pays off if we want extension points for partners or customers, if we plan to share code with Symfony-based systems, or if we want to avoid a future rewrite. It does not replace our queue system for background or cross-service messaging, and I'd push back on anyone framing it that way."

To engineering: "Small, stable API surface — dispatch, listeners with priorities, subscribers, stoppable propagation, plus immutable and traceable decorators. PSR-14 compliant. Actively patched, including memory-leak and dispatch-reset fixes that matter for workers and long-running processes. Choose your tier deliberately: contracts-only if you just want portable interfaces, full component if you want the dispatcher. Pin the Symfony line to match our PHP baseline — 8.x requires PHP 8.4; 6.4 and 7.x are the conservative options. Expect a short spike, not a project."

What to promise, and what not to: promise decoupling, extensibility, and a lower long-term maintenance bill than a bespoke bus. Do not promise hard percentage savings, compliance certification, or a drop-in swap for Laravel's events — those claims won't survive a design review, and the credibility cost is worse than the modest, real benefit. Propose a bounded pilot in the module with the highest change frequency and the most direct cross-service calls, with the success criterion being "new behavior added without editing existing service classes."