[Feature] Support custom BeyondCode\DumpServer\Dumper binding

[bezhermoso]

Use-Case

We want to be add a custom caster for Illuminate\Foundation\Application since it tends to be rather noisy. In order to do that one would need to configure te Symfony\Component\VarDumper\Cloner\VarCloner, but there is currently no way to do that cleanly.

Proposal

Allow applications to optionally override what Dumper to use. This is the easiest, backwards-compatible mechanism I was able to come up with so far:

namespace App\Debug

use BeyondCode\DumpServer\Dumper as BaseDumper
use Symfony\Component\VarDumper\Cloner\VarCloner;

// My custom caster.
class AppCaster
{
    public static function castApplication($obj, array $array, Stub $stub, $isNested, $level = 0)
    {
          // Hide noisy contents of Illuminate\Foundation\Application instance if it's nested in what is being dumped.
          return $isNested ? [] : $array; 
    }
}

class Dumper extends BaseDumper
{
     protected function createVarCloner(): VarCloner
     {
           $cloner = parent::createVarCloner();
           // Register my custom caster:
           $cloner->addCasters([
                'Illuminate\Foundation\Application' => ['App\Debug\AppCaster', 'castApplication'],
            ]);
            return $cloner;
     }
}

With this patch, I'd be able to sub it in cleanly from my service provider:

use BeyondCode\DumpServer\Dumper;
use App\Debug\Dumper as MyDumper;

public function register()
{
     // Use my custom Dumper:
     if (class_exists(Dumper::class)) {
           $this->app->bind(Dumper:class, MyDumper::class);
     }
}

---

If you think this patch is acceptable, I'll be happy to add some test coverage.

[bezhermoso]

If you instead prefer to support something like:

// config/debug-server.php

return [
    'casters' => [
        'Illuminate\Foundation\Application' => ['App\Debug\AppCaster', 'castApplication'],
        ...
     ],
];

I guess that would work, too. Happy to implement that. But IMO the pattern of using the DI container is more potent e.g. we can consider abstracting the CliDumper vs HtmlDumper bit sometime the future if someone discovers a good use-case.

(To take it even further, perhaps Dumper#__construct(AbstractCloner $cloner, AbstractDumper $dumper, Connection $connection) is more favorable, but that breaks BC.)

[yuehlin]

👍

[mpociot]

Nice addition! Thank you!

And I also think that being able to use the container is more powerful. Great stuff