Laravel Dumper Laravel Package

Getting Started

glhd/laravel-dumper is a dev-only upgrade to Laravel's dump()/dd() experience: instead of dumping into the HTTP response (which corrupts JSON/API responses, breaks redirects, and mangles Blade output), dumps are collected and rendered in a dedicated viewer you keep open in a terminal or browser tab.

Minimal steps:

1. composer require --dev glhd/laravel-dumper
2. Publish the config if you want to change defaults: php artisan vendor:publish and look for the package's config file (typically config/dumper.php). Most projects can skip this and run on defaults.
3. Start the viewer the package provides (a long-running artisan command or a browser route, depending on which driver you configure), then trigger dump()/dd() from your app as usual.

Where to look first:

• The package config file — it controls the output driver (terminal vs. browser), the port/route, and which environments are enabled.
• The service provider, to confirm how it registers itself into Laravel's VarDumper handler. That registration is why your existing dump() calls start working differently with no code changes.
• Your composer.json — it should land in require-dev, not require.

First use case to try: debugging a controller that returns JSON. Put a dump($payload) before the return response()->json(...) and confirm you get the payload out-of-band while the response still parses cleanly on the client.

Implementation Patterns

Drop-in replacement for core helpers. Because the package swaps out the dumper handler, the highest-value pattern is not rewriting your debug statements — just install it and keep using dump()/dd(). Reserve the package's own helper(s) for cases where you need to target the dumper explicitly (e.g. you want a dump that survives when the default handler is disabled).

Out-of-band debugging of non-HTML responses. This is the package's whole reason to exist. API endpoints, Inertia/JSON responses, file downloads, and streamed responses all keep working while you dump in the middle of them.

Pair it with a request-scoped trace. A cheap workflow: dump a labelled array at the top of the request (dump(['user' => auth()->id(), 'route' => request()->route()->getName()])) so successive dumps in a busy viewer stay attributable. The viewer is a shared stream across requests, so labels matter more here than they do with in-page dumps.

Use it as a dd() discipline tool. dd() still halts the request, which is fine for the dumper but fatal for anything downstream (queues, transactions, feature tests). Prefer dump() + let the request finish, then read the viewer; keep dd() for the "I just need to know if this line runs" case.

Team workflow. Since dumps no longer appear in the page, a teammate running the app without the viewer sees nothing at all. Document the start command in your README/onboarding notes, or add a Composer script (e.g. composer dump-server) so the viewer is one command away.

CI and production hygiene. It must stay in require-dev. Production images built with composer install --no-dev won't ship it; make sure your deploy pipeline actually uses --no-dev so the service provider never registers in prod.

Gotchas and Tips

• Nothing shows until the viewer is running. This is the single most common "it's broken" report. If dumps vanish, check the viewer process/route before you touch any application code.
• Don't dump into a response you also expect to parse. If another handler is still attached (or the package is disabled in the current env), dump() falls back to in-page output and will corrupt JSON silently. When a response mysteriously fails to parse, suspect a stray dump().
• Environment gating. Config files usually restrict the dumper to local/development. A dump that works in local and silently disappears in testing or a staging env is expected behaviour — check the enabled-environments setting rather than assuming a bug.
• Long-running processes. Under Octane, queue workers, or artisan serve, config and handler changes need a worker/process restart before they take effect. Queue dumps from a worker are notoriously easy to miss if the viewer was started in a different terminal context.
• Payload size. Dumping full Eloquent models with eager-loaded relations is slow and floods the viewer. Dump $model->toArray(), ->only([...]), or $query->toRawSql() instead; a large dump can look like a hang.
• dd() inside a transaction still kills the request — the transaction rolls back. Use dump() when you're mid-transaction.
• View/route caching. php artisan view:cache or route:cache executing a dump() is a classic accidental dump in a Blade partial; it'll fire on every build and confuse you. Grep for dump(/dd( before shipping and consider a pre-commit hook.
• Version pinning. 3.0.1 is a patch that adds Laravel 13 support with no API changes — ^3.0 is the right constraint and 3.0.0 users can upgrade freely. If you're on Laravel 13, 3.0.1 is the minimum; if you're on Laravel ≤10, check the constraint resolution rather than assuming 3.x supports it.
• Extension points. The config's driver/output setting is the main lever (terminal vs. browser sink); the service provider is the place to look if you need to attach a custom dumper or disable the default handler per-environment. Read the provider before hacking around it.