Weave Code
Laravel Dumper Laravel Package
glhd/laravel-dumper
Improves Laravel's dump() and dd() output with richer, framework-aware context. This drop-in package adds custom casters for models, collections, requests, and more, making debugging faster and clearer without changing your workflow.
Upgrade dd() with Laravel-specific improvements
Frequently asked questions about Laravel Dumper
- How do I install glhd/laravel-dumper in a Laravel app?
- Run composer require --dev glhd/laravel-dumper and let Composer resolve the current 3.x release. The package registers itself through Laravel's package auto-discovery, so there is no service provider to add to config/app.php in a standard application. Commit the resulting composer.lock change so teammates get the same version. You can confirm the install by running dump() or dd() on an Eloquent model in Tinker and checking whether the output shows framework-aware context.
- What does glhd/laravel-dumper actually change about dd() and dump() output?
- It extends Symfony VarDumper with custom casters for objects Laravel developers debug most often, such as Eloquent models, collections, and requests. Instead of digging through nested arrays of internal properties, you get the attributes, relations, and framework context that matter. It is a drop-in enhancement, so you keep calling dump() and dd() exactly as before with no new API to learn. The goal is faster, clearer debugging in Eloquent-heavy code.
- Should glhd/laravel-dumper go in require or require-dev?
- Always require-dev. This is a developer-ergonomics utility that only affects debug output, so it has no place in a production dependency set. Putting it in require is the one realistic way to cause a severe problem, because you would be shipping a dumper to production. Enforce the require-dev placement with code review or a CI check on composer.json rather than relying on convention.
- Which Laravel and PHP versions does glhd/laravel-dumper support?
- The 3.x line targets modern PHP, typically 8.2 and newer, and recent Laravel releases. The 3.0.1 patch specifically adds Laravel 13 support, which is a compatibility release rather than a feature change. Because constraint ranges can widen or move between patches, check the require block in the package's composer.json before adopting it on an older Laravel version. Do not let the Laravel 13 claim drive a framework upgrade; consume it when your application actually moves.
- Does glhd/laravel-dumper conflict with Telescope, Ignition, or Clockwork?
- These tools all hook into Laravel's dumping and error-rendering pipeline, so interactions are possible even though they typically surface as confusing output rather than crashes. If the package swaps the dump()/dd() helper binding or the global VarDumper handler, it can compete with Telescope, Ignition, Clockwork, or a custom VarDumper::setHandler() call in AppServiceProvider. Test dump() and dd() with your existing debug tooling installed before rolling the package out broadly. Run the check once per project, since the combination of tools differs by application.
- Can I disable glhd/laravel-dumper or fall back to native VarDumper output?
- The simplest and most reliable fallback is to remove the package, which restores Laravel's default dump() and dd() behavior immediately. Because it is a convenience-tier tool, it must stay trivially removable, so avoid writing code that depends on its specific output format. If you need it only in some contexts, check whether the service provider can be conditionally registered per environment in your AppServiceProvider. Confirm whether any global handler override is disableable rather than assuming it is.
- Does glhd/laravel-dumper work in Tinker, PHPUnit tests, and Artisan commands?
- Yes, it operates on the dump() and dd() helpers, so it works anywhere those helpers run, including Tinker sessions, PHPUnit test runs, and custom Artisan commands. This makes it useful for ad-hoc debugging in a REPL as well as for inspecting model state inside a failing test. Verify the output in all three contexts during a pilot, since debug tooling active in each context may alter what you see. Note that dd() still halts execution, so it is not a substitute for assertions in tests.
- Is glhd/laravel-dumper safe to use in production?
- It should never be installed in production, because it is a debugging aid with no runtime value for end users. Keep it in require-dev so it is excluded from production installs made with composer install --no-dev. The only realistic severe failure mode is a dumper landing in production through a misplaced require entry, so guard against that with review and CI. There is no database, queue, cache, or HTTP middleware footprint to reason about when it is correctly scoped to development.
- How do I upgrade glhd/laravel-dumper from 2.x to 3.x?
- Treat 2.x to 3.x as a major upgrade: assume PHP and Laravel minimum version bumps and possible changes to output formatting. Validate in a single pilot repository before updating shared templates or scaffolding used by other teams. Upgrading within 3.x, such as 3.0.0 to 3.0.1, is a no-op patch that needs no code or test changes, so take it opportunistically on your next composer update. Review the changelog diff to confirm whether a release only widens constraints or also changes behavior.
- Is glhd/laravel-dumper actively maintained, and what are the alternatives?
- It is a small, single-maintainer open source utility, and the 3.0.1 Laravel 13 support release is a positive maintenance signal, but bus factor is worth noting for long-lived projects. The fallback path is Laravel's built-in Symfony VarDumper integration, which you get automatically by removing the package. That makes the risk of adoption low as long as you avoid depending on the package's specific output format. For teams that debug mostly Eloquent models and collections, the improved readability usually justifies the small dependency.
Weaver
How can I help you explore Laravel packages today?