Symfony Message Flow Visualizer Laravel Package

Getting Started

Install the package in a Symfony application (or a Laravel app that already runs Symfony Messenger) with Composer:

composer require michallkanak/symfony-message-flow-visualizer

The 0.1.3 release only adds Symfony 8 compatibility, so existing Symfony 6/7 setups should continue to work. Since this is a Symfony bundle rather than a Laravel package, there is no Laravel auto-discovery or php artisan command. In a Laravel codebase you will typically use it only if you have deliberately integrated Symfony Messenger; otherwise treat it as a reference tool for Symfony services.

First steps:

1. Read the package README and inspect composer.json for the supported Symfony/PHP constraint matrix.
2. Register the bundle in config/bundles.php if it is not auto-registered.
3. Run bin/console list and look for the package’s command namespace (likely messenger or flow).
4. Generate a diagram for one bus or transport first, rather than the whole application.

The best first use case is documenting an existing Messenger setup: dispatch a single message through its bus and confirm the generated diagram shows the expected middleware, handler, and transport path. That validates both the package and your mental model of the flow.

Implementation Patterns

CI documentation artifact. Add a Composer script or Makefile target that runs the visualizer and writes Mermaid or Graphviz output to docs/. Upload the result as a CI artifact so message-flow changes are reviewable in pull requests.

Local debugging aid. When a message is handled by an unexpected handler, or middleware ordering is unclear, generate the flow for the relevant bus and compare it with config/packages/messenger.yaml. This is faster than tracing HandleMessageMiddleware by hand.

Architecture reviews. Generate one diagram per bounded context or transport. Commit the output alongside the Messenger configuration so reviewers can see routing changes without running the application.

Laravel integration. If you use Symfony Messenger inside Laravel through a bridge or standalone container, register the bundle/service manually and invoke the Symfony console command from a custom Artisan command. Do not assume Laravel’s queue system is represented; the package models Messenger buses, middleware, handlers, and transports, not Laravel jobs and events.

Incremental adoption. Start with a single bus and a small set of messages. Once the output is trusted, expand to all buses and add the generation step to CI. This keeps early-version noise and false positives contained.

Gotchas and Tips

• This is a 0.1.x Symfony bundle. Expect API and output-format changes. Pin the version in composer.json and read the changelog before upgrading.
• Symfony 8 compatibility is the only change in 0.1.3. If you are on Symfony 6 or 7, there is no functional reason to rush the upgrade; if you are testing Symfony 8, this release is the first compatible version.
• Check PHP and dependency constraints. Symfony 8 compatibility can pull newer PHP requirements or conflict with older packages. Run composer why-not if installation fails.
• Do not expect Laravel auto-discovery. There is no FlowVisualizerServiceProvider or Artisan command unless the package explicitly ships one. In Laravel, you must wire it into the container yourself.
• Static diagrams have limits. Dynamic dispatch, service locators, runtime routing, and some attribute-based handler registration may not be represented. Treat the diagram as a map, not a runtime trace.
• Clear caches after configuration changes. Messenger routing is compiled into the container; stale caches can produce diagrams that do not match messenger.yaml.
• Filter large applications. Full-application diagrams become unreadable quickly. Prefer per-bus or per-transport output.
• Graphviz may be required. If the package emits .dot files, install Graphviz in CI and locally; Mermaid output avoids that dependency.
• Debug with verbosity. Run the command with -vvv and check Symfony logs if no diagram or an empty diagram is produced. Confirm the command is reading the expected bus name.
• Watch for extension points. Early versions often expose formatters or renderers; check the package source for interfaces before forking. If none exist, keep output post-processing outside the package.