Dumps Laravel Package

Getting Started

The package is a dev-only convenience: it gives you a php artisan dumps command that opens a listener in your terminal and routes dump() output from your Laravel app to that terminal instead of to the HTTP response or a log file.

composer require --dev soloterm/dumps
php artisan dumps

Leave that command running in one terminal (or a dedicated pane/tab), then trigger a request, queue job, or artisan command that calls dump():

public function show(Order $order)
{
    dump($order->id, $order->status); // appears in the `dumps` terminal

    return view('orders.show', compact('order'));
}

Where to look first:

1. The startup output of php artisan dumps — it prints the address/port the listener binds to, which is what the app points at.
2. The package's config after publishing (php artisan vendor:publish), which is where you'd override the host/port or any filtering behavior.
3. Your composer.json — confirm symfony/var-dumper is present, since dump() is VarDumper underneath.

The first realistic use case is a JSON API or XHR endpoint where you can't see dump output in the browser without wrecking the response. Run dumps, hit the endpoint from Postman or your frontend, and read the payloads in the terminal cleanly.

Implementation Patterns

Split-pane workflow. The intended ergonomics are a two-pane setup: browser/frontend on one side, php artisan dumps on the other. In tmux, an IDE terminal split, or a second tab it becomes muscle memory — you sprinkle dump() calls, watch them stream in, and delete them when done.

Dump-and-continue instead of die-and-debug. The big win over dd() is that the request completes. That means you can:

• Inspect a value and still see the rendered page/response.
• Trace a Blade partial without blanking the page.
• Watch a loop across iterations (dump() inside a foreach) and see every pass rather than only the first.

foreach ($payload['items'] as $index => $item) {
    dump("item {$index}", $item);
}

Multi-context instrumentation. Because it's a network listener, dumps from queue workers, scheduled commands, and event listeners all land in the same terminal. This is genuinely useful for debugging jobs where you have no browser at all — start the listener, run php artisan queue:work, dispatch a job, and read the output.

Label your dumps. With many values streaming in, bare dump($x) gets noisy fast. Prefer dump('after-mutation', $model->getAttributes()) or dump(['total' => $total, 'count' => $count]) so the terminal stream stays readable.

Keep it out of shared code. Since it's a --dev dependency, the command won't exist in production, which is good — but a committed dump() call still runs against a missing server and can produce warnings or dropped connections. Treat dump() calls as scratch work and strip them before committing, or gate them behind a debug flag.

Pairing with a debugger. This isn't a replacement for Xdebug; it's for the 80% case where you just want to see a value now. Reach for the debugger when you need the full call stack.

Gotchas and Tips

dd() still kills the process. Interception applies to dump(). If you use dd(), the request dies and the response never completes — you'll debug the resulting blank page instead of your data.

Docker/Sail networking is the #1 failure mode. The listener binds on the host; requests inside a container reach 127.0.0.1 as the container itself. If nothing appears, that's almost always why. Check the address printed at startup and confirm the port is forwarded, or point the app at host.docker.internal. Same story for VMs, remote dev boxes, and anything behind a firewall.

Port collision with another dump server. Symfony's VarDumper server, ray, and this package can all want the same channel. If the command fails to bind or dumps go to the wrong consumer, kill the other listener first. Related: confirm nothing is overriding VarDumper's server setting in your env.

Large payloads get truncated or flood the terminal. Big Eloquent models, request bags, and recursive structures are painful to read. Dump scalar fields, use ->toArray() on a selected subset, or raise VarDumper's depth/limit settings if you need more.

Queue workers cache their bootstrap. After changing config, ports, or env, restart queue:work and octane:reload/restart the server — otherwise dumps silently keep going to the old destination.

No output but no error? Walk this checklist in order: is php artisan dumps actually running; did the request hit the app at all (check storage/logs/laravel.log); is symfony/var-dumper installed; is the app process able to open a TCP connection to the listener (test with nc from inside the container).

Extension points are thin, and that's fine. Beyond the config file and the command itself there isn't much surface area. If you need conditional dumping, write your own tiny helper (if (app()->isLocal()) dump(...)) rather than expecting the package to filter for you. Custom VarDumper casters registered in a service provider will still apply, since the dump pipeline is VarDumper's.

Treat it as a personal productivity tool, not infrastructure. At ~127 stars it's a small, focused package — great day-to-day, but don't build team tooling, CI assertions, or on-call diagnostics on top of it.