- How do I install laravel-event-visualizer in a Laravel app?
- Install it as a development dependency with composer require --dev jonaspardon/laravel-event-visualizer. The package is a service provider with auto-discovery, so no manual registration is needed in most setups. If you want to adjust defaults, publish the package's config and assets with the vendor:publish command, then run the visualization command or open the UI route to generate the graph.
- Which Laravel and PHP versions does laravel-event-visualizer support?
- The package targets Laravel 9, 10 and 11 on PHP 8.1 and above; version 0.4.4 specifically added Laravel 11 support, which also covers the new bootstrap/app.php application skeleton. It is a Laravel-only package, so Lumen and standalone Symfony applications are not supported. Before rolling it out, confirm the framework constraint against your pinned laravel/framework version and your exact PHP minor, including 8.2 and 8.3.
- Is it safe to leave laravel-event-visualizer installed in production?
- It is a development-time introspection tool, so it belongs in require-dev and should never appear in your production require block. The package registers a route to serve its UI, which enumerates your internal event architecture, so gate that route to local or development environments and verify nothing is reachable from staging or production. Treat the environment gating as a configuration review item on every upgrade rather than assuming a safe default.
- Does the visualizer include closure and wildcard listeners in the graph?
- Visualizers of this type typically reflect the listeners registered on the dispatcher at the time the graph is built, so closure listeners, wildcard listeners, and listeners registered dynamically by third-party packages may render incompletely or in a misleading way. Events dispatched through non-standard dispatchers are another common gap. Validate the rendered map against a module whose event topology you already know before treating the graph as authoritative documentation.
- Can laravel-event-visualizer show queued jobs and chained event flows?
- Yes, the package maps events to their handlers and also covers jobs, which lets you see how queued work chains events together across your application. That is the main reason to use it over a plain listener listing: you get an end-to-end view of dispatch chains instead of isolated event-listener pairs. It is especially useful in modular monoliths and domain-event-driven services where the flow crosses several jobs.
- Does the package add runtime overhead to my Laravel application?
- No. It is a service-provider package that introspects the event dispatcher when you invoke it; it adds no database schema, no runtime coupling, and no production traffic path. Keeping it in require-dev ensures it is not installed in production builds at all. The practical cost is only the time it takes to render the graph, which matters on very large event topologies.
- Does it work with Laravel event discovery and cached events (event:cache)?
- Event discovery and event:cache change which listeners are registered and when, so the graph you see may differ depending on whether those workflows have run. Confirm that the visualization reflects the same listener set your application actually uses in the environment you are inspecting. If your output looks incomplete, clear the cached event and route manifests and regenerate before drawing conclusions.
- Is the graph still usable in a large Laravel app with hundreds of events?
- Large applications with 100 or more events can produce graphs that are technically correct but hard to read as a communication artifact. The tool is most effective when you scope it to one representative module or bounded context at a time rather than rendering the whole application at once. Memory and time characteristics on apps with several hundred listeners are worth measuring during a pilot.
- Is laravel-event-visualizer stable enough to depend on long term?
- It is pre-1.0 software, currently in the 0.4.x line, so semver does not guarantee that a 0.5.0 or 1.0.0 release will preserve config keys, routes, or command signatures. Pin an exact version, review the changelog on every bump, and keep it out of any CI gate that other teams rely on. It is also a single-maintainer open source project with no vendor SLA, which is acceptable for a dev-only introspection tool but should be factored into your risk assessment.
- Does laravel-event-visualizer send telemetry or make outbound network requests?
- The package works by inspecting your application's own event dispatcher and rendering a local UI, and no telemetry or outbound calls are documented in its release notes. Because it is a pre-1.0 package from a single maintainer with no formal security-response process, verify this yourself by reviewing the source or running it behind network monitoring before adopting it in a restricted environment. Also confirm the visualization route is environment-gated so the UI is never exposed publicly.