Debug Statements Fixers Laravel Package

Product Decisions This Supports

• Release-readiness / quality gate: Informs whether to add an automated "no debug statements in shipped code" check to CI — a cheap, deterministic guardrail that catches var_dump, print_r, dd, dump, and similar leftovers before they reach customers.
• Build vs. buy vs. write-in-house: A 22-star, zero-dependent package last released in April 2018 is a reference implementation, not a dependency. The decision it most supports is "adopt the rule, not the package" — replicate the check inside tooling the team already runs.
• Roadmap placement of code-hygiene work: Useful data for sequencing linting/static-analysis maturity. This is a low-effort, low-risk item that rides along with existing PHP-CS-Fixer/Pint/PHPStan adoption rather than earning its own initiative.
• Incident prevention and blast-radius control: Debug output can leak internal paths, query strings, or PII fragments, and can corrupt JSON/API contracts and CLI output. A PM can justify a small investment here on security/compliance grounds, not just code style.
• Onboarding and developer experience: Shapes the decision between pre-commit hooks vs. CI-only enforcement — a tradeoff between developer friction, review noise, and how fast new contributors ship.
• Tooling consolidation: Input into "how many linters do we run?" — argues for folding this rule into the formatter/analyzer already in the pipeline instead of adding another binary to maintain.

When to Consider This Package

Consider it — or, more precisely, the pattern it encodes — when:

• You have a PHP 7.x-era codebase already standardized on PHP-CS-Fixer 2.x, where lifting the fixer definitions into existing config is a few hours of work.
• You need a narrow, single-purpose check and the pipeline has no static analysis at all; this is the cheapest credible first step.
• You want a readable reference list of banned functions (including Laravel-specific dd/dump misuse) to hand to engineering, whether or not the package is installed.
• Your risk profile is high-severity, low-frequency — one leaked dump in an auth or payment flow is enough — and any deterministic check beats human review.

Look elsewhere — or write the rule yourself — when:

• You're on PHP 8.x or a modern PHP-CS-Fixer/Pint/Rector/PHPStan stack. An April 2018 release predates essentially all of it; compatibility and security patching are unverifiable, and there is no maintainer signal (0 dependents, low stars).
• You need framework-aware coverage: Laravel dd, dump, ray(), VarDumper, Blade templates, and tinker artifacts. A generic fixer list misses the cases that actually bite Laravel teams.
• You require supply-chain diligence. An unmaintained dev-dependency with one historical release is hard to defend in a security review when the same outcome is ~30 lines of configuration in a tool you already trust.
• You want policy flexibility — allowlists for legitimate error_log usage, per-directory exceptions, autofix vs. fail-the-build — which a stale package won't provide.
• Your goal is broader code hygiene: bundle this into a consolidated Rector/PHPStan/Pint rollout instead of shipping a point solution.

Also verify Packagist provenance for the drew/... package name against the upstream akovalyov/DebugStatementsFixers repository before adding any dependency — the namespace mismatch is a supply-chain question, not a formality.

How to Pitch It (Stakeholders)

One-liner: A whole class of trivial-but-embarrassing production bugs comes from leftover debug statements; the fix is a one-line CI check, and we should implement it in tooling we already maintain rather than adopt this specific 2018 package.

For executives: Low cost, immediate risk reduction. It prevents internal paths, query fragments, or user data from leaking through stray var_dump/dd calls, and prevents debug output from silently corrupting API responses. Delivered as a pipeline rule, it costs roughly one engineering day and has zero recurring spend.

For engineering: The upstream package is a reference, not a dependency — last release 2018, 22 stars, no dependents, no maintainer activity, and no demonstrated PHP 8 support. Recommendation: port the banned-function list into PHP-CS-Fixer/Pint (autofix in local hooks, hard-fail in CI), extend it with Laravel-specific offenders, and cover Blade and console entry points. Track it under the existing static-analysis workstream, not as a standalone project.

Ask: One engineer-day to land the rule plus hook, measured by (a) zero debug-statement findings in CI over 30 days and (b) no measurable increase in local commit friction. Revisit only if richer policy control is later needed, at which point Rector or a custom PHPStan rule is the better home.