No More var_dump - Introducing Symfony VarDumper!



Originally published at:

Recently, Symfony went from Zend-like bloat and rigidity to extreme decoupling and modularity. With the new Developer Experience initiative, Symfony has done a Laravel-style 180° and dove right into making its components more end-user friendly, its docs more complete, and its AppBundles unbundled, simplifying entry and further development almost exponentially. Considering user friendliness, it’s a long way from “best pals friendly” but it’s definitely no longer hostile. One factor that contributes to this factor a lot is their continuous pushing out of new components that are incredibly useful outside of Symfony’s context. One such component is the new VarDumper.



You’re developing a feature. You either don’t feel like writing tests, or what you’re developing needs some variable testing in the middle of a function – something you can’t quite cover with a test. Inevitably, you resort to something like die(var_dump($var));. Even if you’ve abstracted it into a shorthand method like vddd($var), it’s still clumsy and unreadable, and tends to leave debugging snippets around your code, either as comments or, even worse, as code that can actually be triggered.

There’s little choice in the matter – sometimes we simply need our vddds. And sure, if you’re an Xdebug user, you’re probably used to a slightly better looking output than the raw PHP prints. Still, few good solutions existed that beautified this output for us enough to make it worth installing a dev dependency. Until VarDumper.

Continue reading this article on SitePoint


This is a long missing feature. Tried in my Silex application:

use Symfony\VarDumper;




You should encourage people to use proper tools for this kind of work, like xdebug.
From mine experience south debugging code often ends up on the production.
Using debugger one could inspect every variable (see value and type), check execution path or find places where some code is being invoked (breakpoints + call stack -> very useful for reverse-engineering)


Performance hits and installation of extensions (shared hosting friendly, I guess?)

Also, in small throwaway projects, sometimes setting up Xdebug properly isn't worth the time and effort. If I'm testing a tutorial demo and checking for bugs, I'll have a throwaway vagrant box defined which I can scratch after I'm done. The entire ordeal probably wouldn't take more than 20 minutes, which is far too short to set up Xdebug anyway.


That's true, especially performance hit. I usually turn on xdebug extension only for debugging sessions.

Does any IDE has support for build-in php 5.6 debugger ?


Yes, PhpStorm.


So... it makes a pretty var_dump. Doesnt remove any code (in fact, adds a line).

If your dump is several layers deep, you've got to click around and open all the layers to find what you're looking for. Assuming you actually know what you're looking for ahead of time.

Or... i could just View Source a var_dump.


Interesting package. I've added it to a laravel app, but a dump() of a eloquent collection with 150 over items only has the 1st five expandable. The rest were truncated with ....
Any idea how to configure VarDumper to show all details instead of truncating them?


Hmm, not right now. Let us know if you find an easy way.


Maybe something along these settings might help. You might have to find a way to feed it the configuration, though, since this applies only to when it's used within the DebugBundle.


Disclaimer: author of Kint here.

I'd just like to encourage those who have not heard of it, check Kint out:

It's been in the works for years, has tons of useful features like keyboard navigation, plain text alternative, trace output and so on, and most importantly - it's effortless to install and use. Composer support is there, but highly optional - and Kint even supports PHP5.2 when you're stuck with terrible old projects. Needless to say, every later major version is supported and provides more functionality.


Looks good, thanks for chiming in! A "battle of the vardumpers" article might not be a bad idea smile


As the main author of the VarDumper component, thank you for this article!
If you really plan to write a "battle of the vardumpers", let me know smile
One main example with all other dumpers is how (hard) references are dumped: with VarDumper, you can inspect/read them. With others, they are at best replaced by a recursion warning.

VarDumper is focused on extracting the highest possible accuracy about any PHP variable. It never fails with highly complex structures nor in any layer of your PHP app (try e.g. dumping in a PHP output buffering handler).

VarDumper is also highly modular so you could build more than one dumper (I would even encourage LadyBug/Kint to build theirs on the state extraction mechanism of VarDumper).

Debugging can't be done efficiently without robust tools. The xdebug vs dumpers discussion will never end imho because both serve different use cases / group of users (I personally use the two of them).

For Silex integration, you should try
And for the ellipsis that show up too fast, I've raised the default 250 items limit to 2500, that should help.


Thanks for chiming in! I actually am planning to do a battle of the VarDumpers, for real smile Just need a good scenario that tests them all. Ideas welcome smile


Regardless of the debugger you choose, loading the debug library with the php auto prepend file directive is highly useful. I know of no community frameworks that make use of that directive and in ten years I've only seen one custom program use it.

This approach insures you won't accidentally push debug code live since the two are segregated.


+1 for Kint, it's awesome, thank you for taking the time to create it Raveren


Guys, i think this tool and this article mainly wrote for Symfony2 developers as using the native var_dump() against Symfony2 Objects is horrible, so they tried to fix this and address it to us in a political way.

anyways i really helps when developing using Symfony2


Topic is quite old but I would like to clarify. PhpStorm - as any other PHP IDE - does not support phpdbg yet. But development is ongoing


@swader don't forget Tracy for the VarDumpers battle wink


Thanks, I'll keep it in mind!