Eloquent Dumper Laravel Package

Product Decisions This Supports

• Build vs. buy for internal tooling. This is a decision about developer experience spend, not a customer-facing capability. It replaces ad-hoc dd($query->toSql()) calls and one-off helper functions with a single dev dependency — a small, reversible bet on team velocity rather than a platform commitment.
• Diagnosis speed for query-heavy work. Supports triage of N+1s, broken relationship chains, misapplied scopes, and conditional where clauses by exposing generated SQL with bound parameters. The measurable outcome is time-to-diagnose on bug tickets and PR review cycles, not product metrics.
• Support and escalation workflow. Gives support/on-call engineers a repeatable way to capture the exact SQL a customer scenario produces, which shortens back-and-forth with engineering.
• Not a feature enabler. No revenue path, no user-facing surface, no roadmap dependency. It should never appear on a roadmap as a deliverable — at most it's a line item in a DX/tech-debt budget.
• Tooling consolidation decision. Forces an explicit answer to "what is our standard query-debugging tool?" — this package, Telescope, Debugbar, Ray, or nothing. The worst outcome is three overlapping dev tools installed across services.

When to Consider This Package

Consider it when:

• The team writes complex Eloquent/query-builder chains (polymorphic relations, stacked scopes, dynamic conditionals) where the generated SQL is genuinely non-obvious.
• Existing observability is either absent in the dev environment or perceived as too heavy for a quick "what did this actually run?" check.
• You want a zero-config, require-dev-only dependency: no migrations, no service, no production footprint, no credentials.
• You treat it as disposable. Trial cost is hours; removal is one line in composer.json.

Look elsewhere when:

• You need query profiling over time, in production, or shared across a team — that's Telescope, Debugbar, or APM. This package is point-in-time and local.
• You need vendor accountability. 29 stars, a single maintainer, and no release since March 2024 means no support SLA and no security-patch commitment. Do not build CI gates, runbooks, or internal tooling on top of its output.
• Its main hook (dump SQL with bindings) is already 80% covered by ->toSql() + ->getBindings() or a dd(). Then the value is formatting convenience only, and the honest answer may be "don't add the dependency."
• Laravel/PHP version support can't be verified against our lockfile. Even dev-only packages can block a composer update — check resolution in a throwaway branch before committing, and pin the version.
• Adoption would create a second debugging convention alongside an existing standard. Pick one and document it.

How to Pitch It (Stakeholders)

For executives: This is a development-only utility — no production surface, no customer data, no schema changes, MIT licensed. Cost is a single dev dependency plus a short review; removing it takes minutes. The upside is faster diagnosis of slow or incorrect queries, which shows up as less engineering time per bug, not as a new feature. The honest cap: it's a single-maintainer package with modest adoption and no recent release, so we treat it as a convenience, not a platform commitment, and we keep it out of production and CI.

For engineering: Add it under require-dev only. Verify composer resolution against our lockfile on a scratch branch first (framework-version coupling is the realistic failure mode, even for a dev tool), pin the version, and use it for ad-hoc inspection during development and code review. Do not wrap it in internal tooling or depend on its output format. If we standardize on Telescope or Debugbar, this is redundant — decide which one we're keeping and write it down so the next service doesn't install a third.