Service Dumper Bundle Laravel Package

Getting Started

composer require --dev phpyh/service-dumper-bundle

Register it in config/bundles.php, scoped to the environments where you actually need it:

return [
    // ...
    Phpyh\ServiceDumperBundle\ServiceDumperBundle::class => ['dev' => true, 'test' => true],
];

Then find the entry point rather than guessing at it:

php bin/console list | grep -i dump
php bin/console list phpyh   # if the bundle namespaces its commands

The first use case is almost always the same: you added a third-party bundle, a compiler pass, or a services.yaml block, and you need to know what actually ended up in the container. Pick one service you care about (a mailer, a repository, a decorated handler) and dump it. Compare the class and constructor arguments in the dump against what you wrote in YAML — that gap is where autowiring surprises live.

If the bundle does nothing visible after install, it usually means the command is registered under debug: — php bin/console debug:container and debug:autowiring are Symfony's built-ins and remain the baseline you should know before layering this on top.

Implementation Patterns

Trace an autowired argument back to its source. When a service has a constructor parameter you didn't declare explicitly, dump the definition and read the arguments list. Symfony resolves it through _defaults: autowire: true plus type-hint matching; the dump shows you the concrete service id that was chosen, which is the only reliable way to spot that two services implement the same interface and the wrong one won.

Audit a compiler pass. Snapshot the container to a file before and after your pass:

php bin/console <dumper-command> > var/container-before.txt
# toggle your compiler pass
php bin/console cache:clear
php bin/console <dumper-command> > var/container-after.txt
diff -u var/container-before.txt var/container-after.txt

This is the highest-value workflow. Compiler passes are invisible in code review, and a textual diff of definitions makes their effect explicit — including which services they removed, re-tagged, or replaced with a ServiceLocator.

Find everything carrying a tag. Need to know who is registered as an event subscriber, a console command, or a kernel.reset service? Dump and grep for the tag name. This beats hunting through bundle source when a tag is added conditionally (for example, only when a feature flag or another bundle is present).

Inspect decoration chains. If you decorate a service, the dump should show your decorator with the original service id as an argument, and the original definition renamed (.inner). If the chain is longer than you expected, that's usually two bundles decorating the same thing — worth finding before you ship.

Pair with lint:container. The dumper shows you what the container contains; php bin/console lint:container tells you whether it will fail at runtime. Run both in CI. A definition can look perfect in the dump and still blow up on a missing argument at instantiation.

Keep a thin wrapper. Add a composer script so the invocation is one word, and dump to a gitignored directory:

"scripts": {
    "dump:container": "@php bin/console debug:container --show-arguments > var/container.txt"
}

Gotchas and Tips

• Dev-only, non-negotiable. Dumps render unresolved arguments, and depending on the implementation those can include DSNs, env-resolved values, and internal class names. Registering the bundle in prod also adds container compilation work and a different compiled container than the one you tested. Keep it in dev/test and be aware that your local container is then not identical to production — verify final behaviour against a prod-built container before you conclude a service is missing.
• The compiled container is cached. Definitions come from the compiled container, so any change to services.yaml, a compiler pass, or bundle config requires php bin/console cache:clear before the dump reflects reality. A stale dump is the single most common reason someone concludes "the bundle is broken."
• Closures, lazy services, and ServiceLocator arguments don't print usefully. You'll see Closure or a locator stub with no contents. Drop to debug:container --show-arguments or a targeted --env run in those cases; don't assume the dumper truncated your real arguments.
• %env(VAR)% placeholders vs. resolved values. Depending on how the dump is produced, you may see the placeholder string rather than the value. That's usually what you want — don't treat a %env()% you can't read as a misconfiguration.
• Output size. A mid-sized Symfony app has thousands of definitions. Always redirect to a file and grep -n it; scrolling the terminal will lose you the service you were looking at.
• Maintenance signal is weak. Last release December 2023 and a small star count means you should check the symfony/* version constraint in its composer.json before adopting it on Symfony 7+, and be prepared to drop it for the built-in debug:container / debug:autowiring commands if it lags. Because it's dev-only and read-only, removal cost is near zero — treat it as a convenience, not infrastructure.
• No meaningful extension points. This is a small inspection bundle; don't plan on hooking into it or subclassing its dumper. If you need custom formatting for a CI check, write your own command against the compiled ContainerBuilder — that's a twenty-line class and gives you full control over output stability.
• Cross-framework note for Laravel developers: the mental mapping is config/bundles.php ↔ config/app.php providers, service definitions ↔ container bindings, compiler passes ↔ provider register()/boot() logic. Nothing here transfers to php artisan; the equivalent introspection is app()->getBindings() in Tinker. Use this bundle only when you're actually inside a Symfony codebase, and expect the same "cached until you clear it" behaviour you know from php artisan config:cache.