Laravel Event Visualizer Laravel Package

Getting Started

1. Install via Composer: composer require jonaspardon/laravel-event-visualizer --dev (dev dependency is recommended — this is a diagnostic tool, not production runtime code).
2. Publish any package assets/config if the package's service provider requires it (php artisan vendor:publish --tag="event-visualizer-config", verify the exact tag from the package README — tags are not always stable pre-1.0).
3. First use case: run the provided Artisan command (typically php artisan event:visualize or similar — check php artisan list after installation) to dump your event → listener → dispatched-event graph. This gives immediate value on legacy codebases where nobody remembers what fires when.
4. For a web view, hit the route the package registers (usually guarded to local/APP_DEBUG environments). Confirm your EventServiceProvider (or Laravel 11's auto-discovered listeners) is actually being scanned — an empty graph almost always means discovery isn't picking up your listeners, not that the package is broken.
5. Laravel 11 note: v0.4.4 added Laravel 11 support. If you were previously blocked on L11 (or had to alias the package), you can now use it on current Laravel. On L11, listeners are auto-discovered from app/Listeners, so make sure that directory convention is honored or the visualizer will show fewer nodes than you expect.

Implementation Patterns

• Debugging "why did this fire?" in a chain. Trace the event → listener → event → listener cascade visually before adding Log::info calls everywhere. This is the highest-leverage use: complex domain events with subscribers that dispatch further events.
• Pre-refactor mapping. Export/screenshot the event graph before decomposing a monolithic EventServiceProvider or migrating listeners to Laravel 11's auto-discovery. You get a before/after diff for free.
• CI-safe usage. Register it as a require-dev dependency and only invoke it locally. Don't wire it into production deploy steps.
• Onboarding docs. Use generated graph output in your team wiki ("here's how our checkout flow's events chain") rather than hand-maintaining diagrams that rot.
• Auditing listener coverage. Cross-reference the visualizer output against your event classes — orphaned events with no listeners and listeners registered on events that no longer exist are both common sources of silent bugs.

Gotchas and Tips

• Pre-1.0 API churn. At v0.4.4 the package is still 0.x. Command names, config keys, and route paths can change between minor versions. Pin a version range ("^0.4") and read the changelog before bumping.
• Discovery is the #1 failure mode. Empty or partial graphs mean the package isn't seeing your listeners. Check: are listeners in app/Listeners? Are manual registrations in a service provider you've customized? Are you using event subscribers (which discovery sometimes misses)?
• Performance on large apps. Visualizing thousands of events/listeners can be slow or produce an unreadable graph. Scope the output (filter by event or module) if the package supports it; otherwise test on a fresh install first.
• Environment exposure. If a web route is registered, verify it's gated to local/debug environments before deploying. Misconfigured dev tooling routes are a recurring security finding.
• Laravel 11 specifics. L11's streamlined app skeleton removes some default providers and relies on auto-discovery. If your app still has a custom EventServiceProvider, the visualizer may show a mix of discovered and manually registered listeners — good for debugging, but be aware the two registration paths are distinct.
• Extension point: the package typically allows a custom event/listener resolver or filter class via config. If your architecture uses non-standard dispatch patterns (e.g., custom event dispatchers, queued closures), you'll likely need to extend that resolver rather than expect the package to introspect it automatically.