Event Laravel Package

Product Decisions This Supports

• Build vs. buy vs. reuse for an event/dispatch layer. This package is a small, MIT-licensed dispatcher: listener registration, priorities, subscriber objects, and event propagation. It answers the question "do we write our own event bus for a decoupled module system?" with "read this first, then probably use a mainstream alternative."
• Plugin/hook architecture decisions. If the roadmap includes third-party extensions, admin-configurable hooks, or a modular monolith where modules must not import each other directly, a dispatcher is the right seam. This package demonstrates the minimal surface area such a seam needs.
• Framework boundary decisions. Useful as a reference point when deciding whether a component should depend on the framework's event system (Laravel's Dispatcher, Symfony's EventDispatcher) or on a framework-agnostic contract (PSR-14). Its standalone design is the argument for keeping domain events out of framework coupling.
• Priority/ordering as a product requirement. If stakeholders care about deterministic listener order (e.g., "audit logging always runs before notifications"), this package's priority-based listener model is a concrete way to specify that requirement in a ticket.
• Roadmap deprioritization. With 0 stars, 0 dependents, and a [READ ONLY] mirror flag, this should not appear on a dependency roadmap as a strategic bet. The decision it best supports is "explicitly not adopting this," documented so it isn't re-litigated.

When to Consider This Package

Adopt only if all of the following hold:

• You are already inside the Windwalker ecosystem (the package is a read-only split of the framework monorepo, so real maintenance and issue tracking live upstream, not here).
• You need a tiny, dependency-light dispatcher with listener priorities and subscriber registration, and you want something smaller than symfony/event-dispatcher.
• You have read and accepted the source yourself — at this adoption level you are effectively vendoring code, not consuming a supported library.

Look elsewhere when:

• You are on Laravel. Use the built-in Illuminate\Events\Dispatcher with Events/Listeners, ShouldQueue for async, and event discovery. Adding a second dispatcher creates two mental models for the same concept. This is a hard no for a Laravel codebase.
• You need ecosystem guarantees. Zero stars, zero dependents, and a mirror-only repo mean no security response process, no downstream bug surface, and no hiring pool that knows the API. For anything on a revenue path, choose symfony/event-dispatcher or league/event (both PSR-14 aligned, widely depended on).
• You need async, queues, retries, or dead-letter handling. A bare dispatcher gives you synchronous in-process calls; the operational concerns are yours to build.
• You need framework integration (service provider auto-registration, facades, Octane safety, testing helpers).
• Licensing or provenance review is strict. MIT is fine, but a read-only mirror requires confirming the upstream license and maintenance status before legal sign-off.

How to Pitch It (Stakeholders)

To executives: This is a small, free, MIT-licensed event dispatcher maintained as part of the Windwalker PHP framework. It costs nothing to evaluate and carries no licensing risk. However, it has essentially no independent adoption (zero stars, zero downstream dependents) and is published as a read-only mirror, so we should treat it as a reference implementation rather than a dependency. Recommendation: do not add it to our stack; it informs our design of an event-driven module boundary but is not a strategic component. No budget, no procurement, no vendor risk — just a decision to reuse what we already have.

To engineering: Read the source for a compact example of listener priorities, subscriber objects, and event propagation — it is a clean ~1-file-per-concept design worth 30 minutes. Do not adopt it: on Laravel we already have a battle-tested dispatcher with queueing, fakes, and event discovery; off Laravel, use symfony/event-dispatcher or league/event for PSR-14 compatibility and a real support surface. If we build a plugin/hook layer, copy the pattern (priority-ordered listeners, subscriber registration, stoppable propagation) and bind it to PSR-14 interfaces so we can swap implementations later without touching call sites.