Weave Code
Service Dumper Bundle Laravel Package
phpyh/service-dumper-bundle
A Symfony bundle that dumps the services registered in your DI container, making it easy to inspect definitions, tags, and dependencies during development. Useful for debugging container configuration and understanding how services are wired together.
Symfony console command to dump dependency injection services
Frequently asked questions about Service Dumper Bundle
- Is phpyh/service-dumper-bundle a Laravel package or a Symfony bundle?
- It is a Symfony bundle, not a Laravel package. It hooks into Symfony's ContainerBuilder and compiler-pass machinery and is registered through config/bundles.php, so there is nothing to install into a Laravel application. Laravel's container has no bundles and no Symfony-style compiler passes, so this is not integrable on a Laravel stack. If your project is Laravel, treat this evaluation as a no-go.
- How do I install and register the service dumper bundle?
- Install it as a dev dependency with composer require --dev phpyh/service-dumper-bundle, then register the bundle in config/bundles.php. Guard the registration so it only loads in development or test, for example by checking that the environment is dev or test. Because it is a diagnostics-only tool, keeping it out of prod bundles avoids any runtime footprint.
- Which PHP and Symfony versions does it support?
- Check the php and symfony/* constraints in the package's composer.json rather than inferring them from the release date. The last tagged release was December 2023, so compatibility with the newest Symfony 7.x and 8.x branches is unverified until you confirm the constraints yourself. On a pinned Symfony version outside those constraints you risk a hard boot failure rather than a graceful degradation.
- How do I run the service dump from the command line?
- Once the bundle is registered in the dev environment, it exposes a console command that you run with bin/console; the exact command name and available options are documented in the repository README. The output is a human-readable listing of registered services with their definitions and metadata. Run it in the same environment you are debugging, since the container is compiled per environment and per debug flag.
- Does this bundle replace Symfony's debug:container command?
- No, it complements the built-in tooling rather than replacing it. FrameworkBundle already provides debug:container with --show-arguments, debug:container --tag=..., debug:autowiring, and lint:container. The value here is a compact, whole-container, human-readable dump, so evaluate whether that output actually closes a gap your team hits with the core commands. If it does not, you can skip the extra dependency.
- Will this bundle affect my production application?
- Not if you install it with --dev and register it only for dev and test environments. It is a developer diagnostic, not a runtime dependency, so the production footprint and the uninstall cost are both effectively zero. The caveat is that a compiler pass which throws will break container compilation for every developer on the team, so pin the version and test after upgrades.
- Is it safe to paste the dump output into tickets or chat?
- Be careful, because container dumps can contain sensitive values. Environment variables usually appear as placeholders, but literal arguments such as DSNs and API tokens, factory arguments, and inline definitions can print in cleartext. Scrub the output before sharing it in issues, chat, or CI logs.
- Does the dump show the final resolved container or an earlier snapshot?
- Compiled containers discard Definition objects, so tools like this typically capture definitions in a compiler pass and render them later, which means the output is a snapshot at that pass's position in the order. Late passes such as RemoveUnusedDefinitionsPass and RemovePrivateAliasesPass mutate or delete definitions afterwards. Check where the pass is registered relative to the remove passes, because an early capture can list services that no longer exist or miss decoration and inlining results.
- How does it handle decoration, tagged iterators, service locators and circular references?
- These are exactly the constructs where container-dumping tools tend to break, so verify them against your own container before relying on the output. Look for correct recursive rendering of Reference and AbstractArgument, correct handling of tagged iterators and service locators, and inline or synthetic definitions. Also confirm that circular reference graphs do not cause infinite recursion or silent truncation.
- Is the bundle actively maintained, and what are the alternatives?
- The maintenance signal is thin: a small star count, a single small consultancy as maintainer, and a last release in December 2023. Treat it as a low-risk trial rather than a long-term platform bet, and pin the version. Alternatives worth comparing first are Symfony's debug:container, debug:autowiring and lint:container commands, plus the Symfony profiler's container panel.
Weaver
How can I help you explore Laravel packages today?