Krumo Bundle Laravel Package

Product Decisions This Supports

• Developer tooling / DX standards: Informs whether to standardize debugging and data-inspection tooling across teams — specifically, it argues against niche dumpers and for first-party framework tooling (Laravel dd()/dump(), Telescope, Debugbar, Ray).
• Build vs. buy vs. adopt: With 0 stars, 0 dependents, and a 0.03 quality score, this is a clear "don't adopt" data point. Anything we'd get from it, we already get from maintained tooling.
• Legacy estate triage: Relevant only as an inventory item in a Symfony 2.x maintenance or decommissioning workstream — a candidate for removal, not investment.
• Risk register / dependency hygiene: Flags an unmaintained, single-purpose, Symfony2-era dependency that would need a named owner, fork policy, or replacement plan if it appears in any dependency tree.
• Not a product feature: This package delivers no customer-facing capability and should never appear on a customer-facing roadmap. Its only legitimate home is a dev-experience or legacy-maintenance workstream.
• Framework-fit signals: Reinforces that our Laravel roadmap cannot assume Symfony bundle conventions (no service provider, facade, auto-discovery, or config publishing). Useful as a concrete example when socializing "check framework fit before evaluation" as a gate in intake.

When to Consider This Package

Consider it only under narrow, time-boxed conditions:

• You are actively maintaining a Symfony 2.x application that already depends on Krumo for structured dumps, and removal would break an existing debugging workflow mid-initiative.
• Your team is already standardized on Krumo output and there is a short, bounded migration window to Symfony's VarDumper.
• You need a dev-only diagnostic aid and can guarantee exclusion from production builds and autoload paths.

Look elsewhere in essentially every other case:

• Wrong framework: This is a Symfony2 bundle, not a Laravel package. For Laravel, use dd()/dump(), Telescope, Debugbar, Ignition, or Ray.
• Ecosystem support: Zero stars and zero dependents means no security response, no issue triage, and no upgrade path. Treat it as abandoned.
• Modern Symfony: Built-in VarDumper and the Web Profiler supersede Krumo with better output and native integration.
• Production use: Never. Debug dumpers leak internals and secrets and disrupt the response lifecycle; any adoption must be strictly require-dev and environment-guarded.
• Team onboarding: New hires won't know this tool, and it won't appear in modern docs or tutorials.
• If Krumo's output format is genuinely required: evaluate the standalone Krumo library in dev-only scope rather than adopting this bundle — the bundle's value is Symfony DI glue we don't need.

How to Pitch It (Stakeholders)

Executives: This is not a product capability — it's an internal developer convenience library. It has zero adoption, no meaningful maintainer base, and targets a framework generation we're retiring. There's no business case to adopt it and no customer or revenue impact either way. Recommendation: do not onboard; if it already exists in our estate, treat it as technical debt with a scheduled exit.

Engineering: Recognize what this actually is — a Symfony2 bundle wrapping Krumo, a legacy variable dumper. It doesn't fit Laravel (no service provider, no auto-discovery, no config surface) and it doesn't fit supported Symfony versions. It's unmaintained with no dependents, and it carries supply-chain, knowledge-silo, and debug-leakage risk for zero benefit over dd()/dump(), VarDumper, Telescope, Debugbar, or Ray.

If we want the capability — expandable, collapsible inspection of deeply nested payloads — the sensible path in Laravel is the standalone mmucklo/krumo library, or simply leaning on existing tooling. If the bundle is encountered, note it as a rejected dependency in our architecture decision record, replace it during the next adjacent refactor rather than opening a standalone project, and keep any residual Krumo usage strictly dev-only and out of production dependency graphs until then.