Symfony has even more debugging tools. The easiest way to get all of them is to find your terminal and run:

composer require debug --dev

Find your browser, surf back to and search for "debug". Ah, so the debug alias will actually install a package called symfony/debug-pack. So... what's a pack?

Click to look at the package details, and then go to its GitHub repository.

Whoa! It's just a single file: composer.json! Inside, it requires six other libraries!

Sometimes, you're going to want to install several packages at once related to one feature. To make that easy, Symfony has a number of "packs", and their whole purpose is give you one easy package that actually installs several other libraries.

In this case, composer require debug will install Monolog - a logging library, phpunit-bridge - for testing, and even the profiler-pack that we already installed earlier.

If you go back to the terminal... yep! It downloaded all those libraries and configured a few recipes.

And... check this out! Refresh! Hey! Our Twig dump() got prettier! The debug-pack integrated everything together even better.

Unpacking the Pack!

Go back to your Twig template and remove that dump. Then, open composer.json. We just installed two packs: the debug-pack and the profiler-pack:

67 lines composer.json
... lines 2 - 15
"require-dev": {
... line 17
"symfony/debug-pack": "^1.0",
... line 19
"symfony/profiler-pack": "^1.0"
... lines 22 - 65

And we now know that the debug-pack is actually a collection of about 6 libraries.

But, packs have a disadvantage... a "dark side". What if you wanted to control the version of just one of these libraries? Or what if you wanted most of these libraries, but you didn't want, for example, the phpunit-bridge. Well... right now, there's no way to do that: all we have is this one debug-pack line.

Don't worry brave space traveler! Just... unpack the pack! Yep, at your terminal, run:

composer unpack debug

The unpack command comes from Symfony flex. And... interesting! All it says is "removing symfony/debug-pack". But if you look at your composer.json:

71 lines composer.json
... lines 2 - 15
"require-dev": {
"easycorp/easy-log-handler": "^1.0.2",
... line 18
"symfony/debug-bundle": "^3.3|^4.0",
... line 20
"symfony/monolog-bundle": "^3.0",
"symfony/phpunit-bridge": "^3.3|^4.0",
"symfony/profiler-pack": "^1.0",
"symfony/var-dumper": "^3.3|^4.0"
... lines 26 - 69

Ah! It did remove symfony/debug-pack, but it replaced it with the 6 libraries from that pack! We can now control the versions or even remove individual libraries if we don't want them.

That is the power of packs!

Leave a comment!

  • 2018-01-17 weaverryan

    It all makes sense then! So, you definitely found a bug in Symfony - nice work! It's quite difficult to do :). When you have time to change the order of the bundles, it will fix the problem. But in the future (when the bug fix is merged), it won't make a difference thanks to your report!


  • 2018-01-17 Thomas Talbot

    I can't change the order of these bundles for now.
    I'll do it tomorrow. ;)

    Hmm, actually, I did not exactly do what you did after symfony/skeleton... :-s
    Anyway, thanks you very much for your help. :)

    bundles.php :
    return [
    Symfony\Bundle\FrameworkBundle\FrameworkBundle::class => ['all' => true],
    Doctrine\Bundle\DoctrineCacheBundle\DoctrineCacheBundle::class => ['all' => true],
    Doctrine\Bundle\DoctrineBundle\DoctrineBundle::class => ['all' => true],
    Doctrine\Bundle\MigrationsBundle\DoctrineMigrationsBundle::class => ['all' => true],
    Symfony\Bundle\DebugBundle\DebugBundle::class => ['dev' => true, 'test' => true],
    Symfony\Bundle\MonologBundle\MonologBundle::class => ['all' => true],
    Symfony\Bundle\WebProfilerBundle\WebProfilerBundle::class => ['dev' => true, 'test' => true],
    Symfony\Bundle\TwigBundle\TwigBundle::class => ['all' => true],
    Symfony\Bundle\SecurityBundle\SecurityBundle::class => ['all' => true],
    Nelmio\Alice\Bridge\Symfony\NelmioAliceBundle::class => ['dev' => true, 'test' => true],
    Fidry\AliceDataFixtures\Bridge\Symfony\FidryAliceDataFixturesBundle::class => ['dev' => true, 'test' => true],
    Hautelook\AliceBundle\HautelookAliceBundle::class => ['dev' => true, 'test' => true],
    Sensio\Bundle\FrameworkExtraBundle\SensioFrameworkExtraBundle::class => ['all' => true],
    Omines\DataTablesBundle\DataTablesBundle::class => ['all' => true],
    Symfony\Bundle\SwiftmailerBundle\SwiftmailerBundle::class => ['all' => true],

  • 2018-01-17 weaverryan

    ... and here's the pull request to fix the bug :).

    What's interesting is that you should NOT have hit this bug if you installed the packages in the same order that I did. Did you install in a different order? That would explain it :).


  • 2018-01-17 weaverryan

    Hey Thomas Talbot!

    Indeed... I believe you are correct that the core dump() function is winning! And I think I've found the problem. Would you mind posting your config/bundles.php file here? I believe if you change the order of TwigBundle and DebugBundle in this file, it will fix it :). I'm going to open an issue or PR on Symfony's repo about this!


  • 2018-01-17 Thomas Talbot

    Thanks for the explanation. It was about what I thought. :)
    Perhaps the twig-bridge's one is overriden by twig/twig ? weird...

    Here the output of bin/console debug:container --show-private twig.extension.dump :

    Information for Service "twig.extension.dump"

    ---------------- ---------------------------------------------
    Option Value
    ---------------- ---------------------------------------------
    Service ID twig.extension.dump
    Class Symfony\Bridge\Twig\Extension\DumpExtension
    Tags twig.extension
    Public no
    Synthetic no
    Lazy no
    Shared yes
    Abstract no
    Autowired no
    Autoconfigured no
    ---------------- ---------------------------------------------

  • 2018-01-17 weaverryan

    Hey Thomas Talbot!

    Ah, so it gets more interesting :). Well, in case it helps, let me show you how it works behind the scenes. When the DebugBundle is activated, it registers this service: This activates a dump() function ( that should OVERRIDE the one from core Twig:

    Phew! So, you should *not* see the twig_var_dump in your compiled HTML. A few things to check:

    1) Clear your cache, just in case
    2) Try bin/console debug:container --show-private twig.extension.dump - does it show that this service exists?


  • 2018-01-17 Thomas Talbot

    My bad, I'v forgotten to say that I installed it via debug-pack.

    So, I have this problem with symfony/debug-bundle installed. :/

  • 2018-01-17 weaverryan

    Hey Thomas!

    Yes, I know this! Actually, you did a very similar thing to what I did in the previous chapter. When I installed the profiler, that installed the var-dumper, which gave us the pretty dump() function in PHP. But in Twig, my dump() was ALSO "ugly" until THIS chapter, when I ran composer require debug. I believe the missing piece is Symfony's DebugBundle (which comes with the debug "pack"): this adds the integration between TwigBundle and VarDumper. So if you install that, or just install "debug" to get the debug pack, it should get pretty in Twig :).


  • 2018-01-17 Thomas Talbot

    Hi Ryan,

    Thanks a lot for this course. :)

    When you added symfony/var-dumper, your `{{ dump() }}` got prettier. :)
    I have the symfony/var-dumper and symfony/twig-bundle... but it outputs with xdebug not VarDumper component.

    In the var/cache/dev/twig/xxx.php, I have :
    `echo twig_var_dump($this->env, $context);`
    This is the dump function in the twig/twig.

    Have you already seen this problem ?