Weave Code
Event Dispatcher Laravel Package
symfony/event-dispatcher
The EventDispatcher component lets application components communicate by dispatching events and listening to them. Register listeners on named events, control priority, and decouple your PHP code with a simple, standalone Symfony library.
Provides tools that allow your application components to communicate with each other by dispatching events and listening to them
Frequently asked questions about Event Dispatcher
- Is symfony/event-dispatcher a drop-in replacement for Laravel's event dispatcher?
- No. Laravel's illuminate/events dispatcher already provides the same core listener and subscriber model plus Laravel-specific features such as queued listeners, wildcard listeners, Eloquent model events, broadcasting integration, and Event::fake(). The Symfony component is excellent infrastructure, but it does not replace those capabilities. Use it for interop, package authoring, or as a PSR-14 contract, not as a swap for Laravel's dispatcher.
- How do I install symfony/event-dispatcher in a Laravel application?
- It is usually already present transitively through Symfony components in the laravel/framework dependency graph, so start with composer why symfony/event-dispatcher instead of composer require. Only add a direct requirement when you need to pin a version or depend on it explicitly in your own package. When you do, keep its constraint compatible with the other Symfony packages already resolved in your application.
- Which symfony/event-dispatcher version works with Laravel on PHP 8.2 or 8.3?
- Symfony 8.x requires PHP 8.4 or newer and enforces return types across components, so most Laravel applications on PHP 8.2 or 8.3 should target the 6.4 LTS or 7.4 LTS line instead. Hard-requiring ^8.1 while other Symfony packages resolve to ^6.4 or ^7.x can cause Composer solver deadlocks. Check the constraints already used by laravel/framework before choosing a version.
- Does symfony/event-dispatcher support Laravel model events, queued listeners, or Event::fake()?
- No. Those are Illuminate features tied to Laravel's dispatcher. The Symfony component is a synchronous PSR-14 dispatcher with listeners, subscribers, priorities, and stoppable event propagation, and it has no knowledge of Eloquent, queues, broadcasting, or Laravel test helpers. Do not expect Event::fake() to intercept events dispatched through the Symfony dispatcher.
- Can I use symfony/event-dispatcher alongside Laravel's event dispatcher in the same app?
- It is technically possible, but it creates a high-risk dual-bus architecture. Engineers must know which dispatcher to call, which one Octane and queue workers reset, and which one Event::fake() intercepts. Tests can pass while listeners registered on the other dispatcher never run. Introduce a second dispatcher only with explicit ownership and clear conventions.
- How do I register listeners for symfony/event-dispatcher in Laravel?
- Register listeners manually with addListener() or addSubscriber() in a service provider, and bind a single shared dispatcher instance where needed. The #[AsEventListener] attribute is discovered by Symfony FrameworkBundle's dependency injection pass, not by the component in isolation, so it is inert in a typical Laravel app unless you write your own registration pass. Do not assume attribute scanning works out of the box.
- Does TraceableEventDispatcher provide GDPR or HIPAA compliant audit logs?
- No. TraceableEventDispatcher is a debug and profiling wrapper that records which listeners ran and their timing inside the Symfony profiler. It is not persisted or tamper-evident, so it is not a compliance audit log. If you need audit trails, design a separate append-only store with domain events; this package is at most a hook point.
- Is symfony/event-dispatcher asynchronous or useful for high-throughput fan-out?
- No. The component is synchronous only and provides no async fan-out, backpressure, or throughput guarantees. Any work that needs queuing, retries, or background processing should go through Laravel queues or an external broker. The dispatcher can decouple code, but it does not make event handling asynchronous.
- How do I test symfony/event-dispatcher listeners in a Laravel application?
- Event::fake() only intercepts Laravel's dispatcher, so test the Symfony dispatcher directly with a real instance: register the listener, dispatch the event, and assert the resulting side effects. You can also use a mock listener to verify it was called. Make sure the test uses the same dispatcher instance that your application code would use, especially in dual-bus setups.
- When should a Laravel package require symfony/event-dispatcher instead of illuminate/events?
- Require it when the package must run outside Laravel, across Laravel and non-Laravel services, or when it needs PSR-14 interoperability with third-party Symfony-based libraries. Inside application code, prefer Laravel's dispatcher for model events, queues, and testing helpers. Depend on the PSR-14 interface where possible so domain code is not tied to either concrete dispatcher.
Weaver
How can I help you explore Laravel packages today?