Event Dispatcher Laravel Package

Technical Evaluation

• Architecture fit: Low for Laravel as a primary event system. Laravel already provides a mature dispatcher with listeners, subscribers, queues, broadcasting, wildcard listeners, testing fakes, and container integration. yiisoft/event-dispatcher is a narrow PSR-14 dispatcher and does not supply Laravel service providers, facades, queue integration, or framework lifecycle hooks. Its fit is limited to a deliberate PSR-14 interoperability boundary, especially if a Yii or other PSR-14 dependency must exchange events with Laravel.
• Integration feasibility: Technically feasible via Composer, but not turnkey. The TPM should expect custom adapter work: register the dispatcher as a singleton, implement a listener provider that resolves listeners through Laravel’s container, and bridge Laravel events to PSR-14 events only where needed. Avoid running two independent event buses for the same domain events.
• Technical risk: Code/spec risk is relatively low because PSR-14 is a small, stable contract and the BSD-3-Clause license is permissive. Sustainability risk is higher: the repository is unknown, stars are low at 73, and the last release was 2022-10-27. That implies limited community support, uncertain PHP/Laravel compatibility testing, and no clear patch cadence. Treat it as a small utility rather than a strategic platform dependency.
• Key questions: Is there a real PSR-14 consumer/producer requirement, or can Laravel’s dispatcher satisfy the need? Which dependency mandates PSR-14? Who owns the adapter and its tests? What PHP and Laravel versions must be supported? How will listeners be resolved, queued, retried, and observed? What is the exit plan if the package becomes stale?

Integration Approach

• Stack fit: Keep Laravel’s Illuminate\Contracts\Events\Dispatcher as the application’s primary event backbone. Use yiisoft/event-dispatcher only at the PSR-14 boundary, such as exposing selected domain events to a non-Laravel package or consuming PSR-14 events from a Yii component. Do not replace Laravel events for framework lifecycle, auth, queue, or broadcasting use cases.
• Migration path: Start with an inventory of existing Laravel events and any PSR-14 dependencies. Define a small boundary contract, install the package, implement a container-aware listener provider, and write adapter tests for event identity, listener ordering, exception behavior, and payload immutability. Introduce behind a feature flag in one module before broader use.
• Compatibility: Verify Composer constraints against the target Laravel and PHP versions before commitment. Confirm the required psr/event-dispatcher version and whether the package’s transitive constraints conflict with Laravel or other dependencies. Since there is no Laravel package auto-discovery, integration wiring and documentation are internal responsibilities.
• Sequencing: Sequence as: proof of concept in a non-critical module; adapter and contract tests; observability and failure handling; documentation; limited production rollout; then decide whether to retain, fork, or replace. A TPM should gate broader adoption on demonstrated need and a clear owner for the adapter layer.

Operational Impact

• Maintenance: Expect low upstream activity and limited support. Pin the version, monitor advisories, and maintain an internal fork/replacement option. BSD-3-Clause reduces licensing friction but does not remove the need for ownership.
• Support: Community support is likely thin given the unknown repository and low adoption. The team must own runbooks, upgrade testing, and incident response. Vendor support should not be assumed.
• Scaling: The dispatcher is in-process and synchronous by design. Scaling depends entirely on listener implementation; it does not provide queueing, retries, backoff, or async execution. For high-volume or failure-sensitive workflows, Laravel’s queued events or a dedicated message bus remain better fits.
• Failure modes: Listener exceptions can propagate into request or worker execution unless caught by the adapter. Dual-dispatch designs can cause duplicate handling or drift between Laravel and PSR-14 listeners. Container resolution failures, listener ordering assumptions, stale PHP compatibility, and memory growth in long-running workers are the main operational risks.
• Ramp-up: PHP developers familiar with PSR-14 can learn the package quickly. Laravel-centric teams will need guidance on the difference between Laravel events and PSR-14, plus adapter ownership. The TPM should budget a small pilot and explicit documentation rather than assume framework-native ergonomics.