Krumo Bundle Laravel Package

Getting Started

Know what you're holding first. oodle/krumo-bundle is a Symfony2 bundle — DI registration glue around the standalone Krumo library. There is no Laravel service provider, no facade, no auto-discovery, no config/krumo.php. In a Laravel codebase you will not install the bundle; you install the underlying library (mmucklo/krumo or vendor the single class.krumo.php) and write your own thin glue. The bundle is only relevant if you are triaging a legacy Symfony 2.x app.

Minimal steps — Laravel (the realistic path):

1. composer require mmucklo/krumo in require-dev, or drop class.krumo.php into app/Support/.
2. Add one buffering helper (see Implementation Patterns) — Krumo echoes, it does not return.
3. Call it from Tinker, an Artisan command, or a guarded debug route and inspect the output.

Minimal steps — legacy Symfony 2.x only:

1. composer require oodle/krumo-bundle (expect Symfony 2.x / PHP 5.x constraints).
2. Register in app/AppKernel.php under $bundles, in the dev environment block only.
3. Call krumo($value) from a controller and load the route. Add krumo::includes() to your base template so the skin CSS/JS loads.

Where to look first. There is nothing in this package to read beyond registration code — read the Krumo library itself (skins, krumo::setConfig, expansion defaults). That is where all behavior lives.

First use case worth the effort. Deeply nested structures — a decoded webhook payload, a large config() subtree, a multi-level Eloquent toArray() graph — where dd() is a wall of text and Krumo gives you collapsible nodes with type, class, and array-length annotations. If that isn't your problem, stop: dump(), dd(), or Telescope already win on every other axis.

Implementation Patterns

Always buffer echo output. Krumo writes directly to output, which collides with Laravel's response lifecycle. One helper, used everywhere:

function krumo_capture($value): string {
    ob_start();
    krumo($value);
    return ob_get_clean();
}

Return response(krumo_capture($data)) from a throwaway route, or pass it to Blade as {!! $dump !!}.

Single guarded debug route. Do not sprinkle krumo() through controllers. One route, environment-gated:

Route::get('/_debug/{topic}', function ($topic) {
    abort_unless(app()->environment('local'), 404);
    $data = match ($topic) {
        'session' => session()->all(),
        'config'  => config('services'),
        'user'    => auth()->user()?->load('roles')->toArray(),
    };
    return response(krumo_capture($data));
});

Tinker is the primary day-to-day workflow. php artisan tinker, then file_put_contents('dump.html', krumo_capture($thing)); and open it in a browser. This is the most defensible routine use — HTML dump to a file, no response interference, no assets to wire up.

Normalize before dumping. Call ->toArray(), json_decode(json_encode($obj), true), or $collection->take(5) first. Krumo will happily walk an entire model graph including lazy relations otherwise.

Symfony 2.x survival pattern. Gate the bundle on %kernel.debug%, load krumo::includes() in the base template once, and call krumo() only in controller actions you're actively debugging. Treat it as a poor-man's toolbar.

Blade partial for reusable dumps. A resources/views/debug/dump.blade.php with {!! $dump !!} and an inline <style> block for the skin. Cheaper than trying to publish Krumo assets through Laravel's pipeline.

Gotchas and Tips

• Echo, not return. Any krumo() call in a controller returning JSON, a redirect, or a Response corrupts the body or triggers "headers already sent." Always buffer.
• Streamed and downloaded responses break. Krumo emits inline <script> and <style>. File downloads and streamed responses become garbage — never call it in those paths.
• Install will probably fail. Zero stars, zero dependents, Symfony2-era constraints. Composer will likely refuse on PHP 8 / modern Symfony. Plan to vendor the standalone class by hand and skip the bundle entirely.
• No Laravel integration surface. No container binding, no config publishing, no auto-registered helper. You write the glue — put it in one place and stop.
• Assets are the usual breakage. The bundle assumes Symfony's asset pipeline. In Laravel, inline the skin CSS in your debug view or copy skins/ into public/vendor/krumo/.
• Recursion and memory. Dumping framework container internals or full model graphs can blow memory or produce an unreadable thousand-node tree. Cap depth by slicing data before you hand it over.
• Lazy-loading side effects. Introspecting a model can trigger relation queries. Watch the query count in Debugbar — dumping is not free.
• Security. Never enable a Krumo route outside local. It exposes session contents, service config, and model internals with no auth layer.
• Extension points are thin. You can adjust Krumo's own static config (skin, expansion depth, CSS paths) and wrap or subclass it, but the bundle adds nothing beyond registration. If you need query logs, timelines, mail previews, or request inspection, Laravel Debugbar, Telescope, or Ray cover the ground this tool never will.