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.

Why?

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 almost as much as the monochromatic output it generates.

There’s little choice in the matter – sometimes we simply need our vddd s. 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.

What is VarDumper?

Symfony VarDumper is a component designed to replace your var_dump s. It performs essentially the same functionality, but provides you with much, much more information in a much prettier format. It’s the var_dump you’ve always wanted.

As per their documentation, by using it, you’ll gain:

Per object and resource types specialized view to e.g. filter out Doctrine internals while dumping a single proxy entity, or get more insight on opened files with stream_get_meta_data;

Configurable output formats: HTML or colored command line output;

Ability to dump internal references, either soft ones (objects or resources) or hard ones (=& on arrays or objects properties). Repeated occurrences of the same object/array/resource won’t appear again and again anymore. Moreover, you’ll be able to inspect the reference structure of your data;

Ability to operate in the context of an output buffering handler.

Installing and Using

Let’s quickly install it into our Homestead Improved instance and run a couple of tests. If you’re not familiar with HI yet, please take 5 minutes to get it over with so you can follow along with the tests.

Installation

As with any decent modern PHP project, installing is as simple as running

composer require symfony/var-dumper

Usage examples

It’s used via the newly exposed dump function:

$var1 = "test" ; dump ( $var1 ) ;

Let’s try something more complex now.

$a = [ 'ak1' = > 'av1' , 'ak2' = > 'av2' , 'ak3' = > 'av3' , 'ak4' = > 'av4' , 'ak5' = > 'av5' , ] ; $b = [ 'bk1' = > 'bv1' , 'bk2' = > 'bv2' , 'bk3' = > 'bv3' , 'bk4' = > 'bv4' , 'bk5' = > 'bv5' , ] ; $object = new \ stdClass ( ) ; $object - > prop1 = 10 ; $object - > prop2 = 20 ; $object - > prop3 = 30 ; $object - > prop4 = 40 ; $c = [ 'a' = > & $a , 'b' = > $b , $object ] ; dump ( $c ) ;

As you can see, VarDumper wonderfully exports the variables we defined, declaring everything verbosely – all coupled with some practical CSS that not only syntax highlights everything but also allows us to expand and collapse various parts of the data dump. Hmm, but what are those plusses next to the properties of the stdObject ? Public properties? How does it display private ones, then? Does it at all? Let’s see.

class Test { public $prop1 = 10 ; private $prop2 = 20 ; protected $prop3 = 30 ; private $prop4 = 40 ; public function __construct ( $value ) { $this - > undefinedProp = $value ; } } $t = new Test ( 50 ) ; dump ( $t ) ;

So public properties are plusses, private ones are minuses, protected ones are hashes, neat. Not only that, but every dumped property also has a title hint which exposes more information when you hover your mouse over them:

What’s more, runtime added properties are specifically defined in both the hint, and visually – they’re surrounded by quotes.

What about runtime added methods? Let’s see.

class Test { public $m1 ; protected $m2 ; public function __construct ( ) { $this - > m2 = function ( ) { return "I'm method 2" ; } ; } public function buildFunction ( ) { $this - > m3 = function ( ) { return "I'm method 3" ; } ; } public function __call ( $method , $args ) { if ( isset ( $this - > $method ) ) { $func = $this - > $method ; return call_user_func_array ( $func , $args ) ; } } } $t = new Test ( ) ; $m1 = function ( ) { return "I'm method 1" ; } ; $t - > m1 = $m1 ; $t - > buildFunction ( ) ; $t - > m1 ( ) ; dump ( $t ) ;

You can see VarDumper exposes much more information about objects, using reflection, than the typical var_dump – even the lines of code where the methods are defined.

These are just some of the nifty tricks VarDumper has up its sleeve – for the rest, and screenshots of how they look, check the announcement post out.

Conclusion

VarDumper is a great tool for quick and dirty safety and sanity checks, and when used in conjunction with Symfony’s DebugBundle, it becomes even more powerful – in fact, it’s included by default in dev and debug versions of Symfony installations, from version 2.6 onward.

Some might argue that using it with a simple non namespaced dump() command has the potential to cause conflicts with other utility methods you might have in your project, and it obscures its source on first glance. While a changeable function name to call the utility might allay those worried minds, I believe we’re dealing with very rudimentary and production-insignificant functionality here, and thus this non-issue may be forgiven.

Now that you know about VarDumper, will you be adding it to your own projects for on-the-fly debugging purposes?