Dumper Laravel Package

Getting Started

First, a reality check before you type composer require. The metadata you're looking at is internally inconsistent: patchwork/dumper is a framework-agnostic variable dumper, while the linked repo (tchwork/debug-bundle) is a Symfony 2.6 DebugBundle backported to Symfony 2.3+. These are different artifacts with different maintainers. Neither is archived-friendly for a Laravel app, and both predate PHP 7.4, let alone 8.x. Confirm which artifact you actually mean (composer package name + commit SHA) before installing anything.

Where to look first if you're on Laravel: you're already done. Laravel ships symfony/var-dumper and exposes:

• dump($var) — inspect without halting
• dd($var) — inspect and die
• php artisan dump-server — render dumps in your terminal instead of the browser
• illuminate/support helpers already loaded via composer.json autoload files

That is the exact capability set this package exists to provide, maintained, PHP 8-compatible, and already installed. The first "use case" for patchwork/dumper in a Laravel context is: recognize you don't have one, and go read dump()/dd() docs instead.

If you genuinely maintain a Symfony 2.3–2.6 service and need DebugBundle behavior the framework version lacks:

1. composer require --dev tchwork/debug-bundle (pin an exact version; commit the lockfile).
2. Register the bundle in app/AppKernel.php under the dev environment only.
3. Set debug: true in config_dev.yml.
4. First exercise: replace a var_dump($entity) in a controller with the bundle's dump helper and confirm HTML rendering in the profiler/debug toolbar.

Treat that as a time-boxed exception with a removal ticket, not a starting point.

Implementation Patterns

The substitution pattern (what you should actually do day-to-day). Map every claimed capability to native tooling and close the gap that way:

This mapping is the workflow. If a real residual gap survives it, write a thin first-party wrapper over symfony/var-dumper — don't resurrect an archived fork.

Depth and size limiting (if you're inside the legacy Symfony context). The dumper is recursion-safe but the safeguards are tuned for PHP 5.x object models, not Eloquent proxies or lazy-loaded relationships. Configure explicit depth and item limits per call rather than relying on defaults; you will otherwise hit memory exhaustion on large Collection instances or deeply nested graphs.

Environment gating, always. Debug output belongs in the local/dev code path and nowhere else. The clean pattern is a guard so the helper can never execute in staging or production:

if (app()->environment('local')) {
    dump($payload); // or dumper call
}

Better: don't guard-call a debug dumper in application code at all — use the debugger or Telescope. Dumps left in committed code are how debug surfaces leak into production responses.

Custom dumper/handler wiring (Symfony 2.x only). The bundle exposes configurable dumpers and handlers via bundle config. If you're extending it, define them as services in a services.yml scoped to the dev container. This is the one genuinely transferable piece of knowledge here: reading how Symfony-era bundles wire dumpers into the kernel teaches you how modern profilers hook in.

Dependency-policy pattern. Record this evaluation as a worked "no" in your adoption gate: maintained? PHP 8 / Laravel 10–11 support? nonzero dependents? security-response path? It fails all four. Use it as the reference case for the next package review.

Gotchas and Tips

• Fatal helper redeclaration. The package exposes global dump()/dd()-style helpers. Laravel's foundation helpers are autoloaded via a files entry in composer.json. Load both and you get Cannot redeclare function — a fatal that takes the whole app down, including CI. This is the primary install blocker; mitigating it means conditional function_exists guards or a vendor fork, i.e., you now own internal code.

• PHP 8 incompatibility is unverified, not merely untested. The reflection traversal predates typed properties, enums, readonly classes, and attribute-based reflection. Expect incomplete output or hard fatals when the dumper introspects a modern object graph. Don't attempt this without a dedicated PHP 5.6/7.x Docker image.

• Production exposure is the high-severity failure mode. A debug bundle or dumper left enabled outside local exposes env vars, config, request internals, and route structure. This is a documented incident class and the single strongest argument for archive status being disqualifying. If you prototype, isolate it to a throwaway local container that never touches CI or shared infra.

• Reflection against Eloquent proxies. Lazy-loading proxies, queued closures, and large collections are likely to produce incomplete output or blow recursion/memory limits. The tool has no safeguards calibrated for modern PHP object models.

• Silent JSON corruption. A dump() call left in an API/JSON response path corrupts output without necessarily erroring. Grep for debug helpers before merge; add a lint check if you ever adopt anything like this.

• No community to consult. 85 stars, zero dependents, no maintainer, no Stack Overflow corpus, no recent coverage. Failure diagnosis is entirely first-party and ramp-up documentation must be written from source.

• Extension points are a dead end. The configurable dumpers/handlers and the kernel-level wiring are architecturally clean, but extending them means forking an archived package — which converts a --dev dependency into maintained-internal code with no upstream fixes, no PHP-version work, and no security advisories.

• Bottom line for day-to-day leverage: there isn't a legitimate one in a Laravel codebase. Reach for dump()/dd()/dump-server/Telescope/Xdebug, and if you're tempted by this package, escalate the framework-version problem instead — the missing dumper is a symptom, not the need.