Dumper Laravel Package

Product Decisions This Supports

• Framework-upgrade business case (the primary leverage). For a PM, this package's value is not as a dependency but as a data point. An archived Symfony 2.6 DebugBundle backport that still circulates in package indexes is a concrete artifact of framework debt. It gives you something to point at when arguing that funding a Laravel/Symfony upgrade is cheaper than an indefinite tail of backports, forks, and one-off dev tools. Attach it to the roadmap item "retire legacy PHP 5.x/7.x services" as supporting evidence, not as a work item.
• Dependency governance policy — a worked example. Archived status, 85 stars, zero dependents, no maintainer, no security-response path, and a repository/package-name mismatch (patchwork/dumper vs. tchwork/debug-bundle). That is an ideal reference case for a written adoption gate: maintained? supported PHP/Laravel versions? nonzero downstream usage? CVE path? A single documented "no" here makes the gate credible across every future package review.
• Build vs. buy vs. standardize for developer tooling. Debugging and inspection is never a differentiator. This package argues against both building and buying: Laravel already ships symfony/var-dumper with dump()/dd(), php artisan dump-server, plus Telescope, Ignition, and Xdebug. The decision it supports is "do not staff a debugging-tooling workstream; standardize on maintained defaults and budget a small DX line instead."
• DX and onboarding roadmap. Debugging visibility affects ramp time and incident MTTR. The relevant product decision is whether to invest in first-class local inspection and structured logging — a small, measurable investment — rather than reviving abandoned bundles. Frame it as a DX budget ask, not a package decision.
• Vendor-risk and SBOM posture. Zero dependents means zero field validation: adopting makes you the first real user, with no Stack Overflow corpus, no peer teams, and no upgrade path. If compliance or procurement flags unmaintained dependencies, this package is the trigger to formalize that rule.
• Use cases it does not support: production error surfacing, log correlation, performance profiling, customer-facing diagnostics, or anything in a reliability/observability narrative. Dumpers are a local-development affordance only.

When to Consider This Package

• Effectively never for a Laravel product. This is a Symfony bundle (or, depending on which artifact you believe, a standalone global-function dumper). Either way the idiom mismatch is total: no service provider, no config surface, and global helper functions that collide with Laravel's own dump()/dd() — a real risk of a fatal Cannot redeclare that breaks the app and CI.
• Only if you maintain a Symfony 2.3–2.6 application that genuinely needs DebugBundle behavior the framework version lacks — and the work is explicitly time-boxed, require-dev only, confined to a locked-down local container, with a named owner and a removal ticket tied to the migration.
• As a reference implementation, not a dependency: engineers can read how Symfony-era bundles wire dumpers into the kernel, and that knowledge transfers to modern tooling.
• During a migration freeze window, where a controlled fork is cheaper than unblocking a team — again with an exit criterion and an owner.

Look elsewhere when:

• The target is Laravel, on any supported version and any PHP 8.x runtime. Use symfony/var-dumper (dump()/dd()), php artisan dump-server, Telescope, Ignition, Clockwork, or Xdebug. These are already installed or one Composer line away.
• You need maintained releases, PHP 8 compatibility, security patching, or any support SLA — none exist, and the archive flag is permanent. Reflection against enums, readonly classes, typed properties, and lazy-loading Eloquent proxies is unverified and likely to fail.
• The package metadata is inconsistent. It is: the name and the repository describe different artifacts. Any score (0.53 here, with an opportunity score around 1.34–1.44) may be describing something you would not actually install. Require a composer package name and commit SHA before spending another hour.
• Your compliance, procurement, or SBOM policy flags unmaintained transitive dependencies.
• The need is production diagnostics. A dumper left enabled outside local exposes env vars, config, request internals, and route structure — a well-documented class of production incident.
• The team is small. Even a free package costs ownership, upgrade friction, and tribal-knowledge onboarding — a poor trade against a one-line requirement for a maintained equivalent.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a 2014-era backport of a Symfony debugging component: archived, unmaintained, with no downstream users and metadata that doesn't even match its own repository. It is not an adoption candidate and carries no product value on its own. Its usefulness to us is as evidence — it shows where legacy framework debt accumulates and why a funded upgrade path is cheaper than indefinite backporting. Recommendation: no investment, no trial, no procurement. Treat it as a documented "no" and cite it in our dependency policy.

To engineering leadership: Do not add this to any Laravel service. Laravel already ships the entire capability set — symfony/var-dumper with dump()/dd(), artisan dump-server, Telescope, Ignition, Xdebug — maintained and PHP 8-compatible. Installing this risks a fatal helper redeclaration against Laravel's own globals, and would convert a zero-effort dev dependency into internally-owned fork maintenance. If a legacy Symfony 2.x service truly needs it, cap the work at a time-boxed, require-dev-only fork with a named owner and a removal ticket tied to the migration. Otherwise standardize on the maintained defaults and spend the saved time on the upgrade.

To the engineering team: If you're reaching for this, the real problem is the framework version, not the missing dumper. Check dump()/dd() and php artisan dump-server first; if there's still a gap, open a Telescope/Clockwork/spatie/laravel-ray evaluation or write a thin wrapper over symfony/var-dumper. Read the bundle's source if you want a clean example of kernel-level debug wiring — that transfers. Don't install it.

The ask: Approve two cheap things — (1) a dependency-adoption gate requiring a maintained status, supported runtimes, a security response path, and nonzero downstream usage; and (2) a small DX budget for maintained tooling (Telescope, Xdebug, structured logging). Together they prevent this exact situation recurring across the estate, and both cost less than a single week of forked-package maintenance.