Extended Dump Bundle Laravel Package

Getting Started

Install the bundle with Composer and confirm which Symfony branch you are on—the package targets Symfony 4, 5, and 6, so pin your dev tooling accordingly:

composer require --dev szczyglis/extended-dump-bundle

For Symfony 5.4+/6.x with Flex and symfony/framework-bundle auto-registration, the bundle is enabled automatically. On Symfony 4 or non-Flex projects, register it manually in config/bundles.php:

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

Where to look first: open the package’s README.md and src/DependencyInjection/Configuration.php (or the extension class) to see what config keys it exposes. This bundle’s whole value proposition is enhancing Symfony’s dump()/dd() output, so the config tree tells you exactly what behavior you can toggle. Then check config/packages/dev/ for a recommended YAML snippet—most dump-enhancement bundles expect something like:

# config/packages/dev/extended_dump.yaml
extended_dump:
    enabled: true

First use case: drop a dump($order) inside a controller action, load the page, and compare the browser output against stock var-dumper. That is your baseline to confirm the enhancement is actually kicking in. If nothing changes, the bundle is not registered or the dev config is missing—do this sanity check before wiring it anywhere else.

Implementation Patterns

Controller-level debugging. Keep the standard Symfony\Component\VarDumper\VarDumper::dump() / helper dump() calls and let the bundle decorate the output. This means you can add/remove the package without rewriting call sites—prefer helpers (dump(), dd()) over instantiating VarDumper directly so the bundle can hook the renderer.

Twig debugging. If the bundle registers a Twig extension or a dumper decorator, {{ dump(variable) }} in dev templates will pick up the enhanced output. Verify in the profiler that the Twig dump extension remains wired after installation; if the bundle replaces the default dumper, check config/packages/twig.yaml for a debug flag.

Console debugging. For commands and migrations, the CLI dumper uses the same CliDumper path. Test a dd($dto) inside a console command with -vvv—bundles that enhance browser output sometimes assume HTTP context and degrade silently on CLI.

Environment gating. Only enable in dev and test. If you ship a config/packages/extended_dump.yaml at project root with enabled: true, you risk running the bundle in production where the overhead and potential output leakage are unacceptable. Mirror the dump server var pattern Symfony uses: gate on when@dev blocks in YAML or a per-environment config file.

Integration tips. If you use PHPUnit with symfony/phpunit-bridge, add the bundle to the test kernel’s bundle list only if you actually dump during tests—otherwise skip it to keep test boots lean. If you have a custom DumperInterface or a PSR logger bridge that captures dumps, confirm the bundle doesn’t override the dumper factory in the container; a decorator should compose, not replace, so check debug.dump_handler / var_dumper.dumper service definitions after install.

Gotchas and Tips

Production exposure. The single biggest pitfall with dump-enhancement bundles is accidental registration in prod. dump() leaking into an HTTP response is an information-disclosure bug. Double-check bundles.php uses ['dev' => true] and not a bare true, and set APP_ENV=prod locally once to confirm the bundle is inert.

Cache after install. Symfony’s container and Twig caches will not rebuild the new services automatically in every workflow. Run php bin/console cache:clear (and cache:warmup for prod parity) after registering. If dumps still look stock, clear the Symfony var-dumper cache under var/cache/dev/ too—some bundles ship compiled assets.

Dumper conflicts. symfony/var-dumper registers VarDumper::setHandler() at bootstrap. If the bundle also sets a handler, ordering matters. If you see raw var_dump output instead of the styled dumper, a boot-order issue is the likely cause; check your Kernel::registerBundles() order and any _preload / prepend extension logic.

Large object graphs. Enhanced dumpers often add recursion depth, stack-trace, or class-meta data. Dumping Doctrine entities with lazy-loaded collections can balloon memory or trigger extra queries during serialization. Use dump() on scalar snapshots or dump($entity->getId()) first, then widen scope; if it hangs, dump() may be traversing a proxy that lazily initializes relationships.

CLI vs browser formatting. HTML dumper output in a terminal is unreadable. Ensure the bundle respects CliDumper context—if not, wrap with a check (if ('cli' === PHP_SAPI)), or set VAR_DUMPER_FORMAT=cli / html as appropriate for CI log capture.

Extension points. If the bundle exposes a compiler pass or a DumperInterface tag, prefer defining your own dumper as a service tagged with data_collector.dump (or whatever tag the bundle documents) rather than subclassing the bundle class. That keeps you upgrade-safe across the Symfony 4→6 range this package supports. Finally, with zero dependents and a 2024-08-26 release, treat the package as unmaintained-ish: pin the exact version in composer.json and be ready to swap back to plain symfony/var-dumper if a Symfony upgrade breaks it.