Debug Statements Fixers Laravel Package

Technical Evaluation

Architecture fit. drew/debug-statements-fixers is not a runtime library. It is a thin collection of custom fixers for friendsofphp/php-cs-fixer that strips var_dump, print_r, dd, dump, die/exit and similar artefacts during a static-analysis pass. Architecturally that is a good fit for us: it lives entirely in the dev/CI lane, has no production code path, no service container binding, no Laravel provider, and no runtime coupling. It is a lint rule wearing a package costume.

Integration feasibility. The blocker is era, not design. Last release 2018-04-19 predates php-cs-fixer 3.x, which changed the FixerInterface contract (notably getName() removal and supports() semantics). Any modern Laravel app on PHP 8.x will almost certainly resolve to a dependency conflict at install time. Because MIT-licensed fixers are individually small (roughly 30–80 lines each), the realistic path is vendor-and-port rather than composer require. Two days of work, not two hours, because each ported fixer needs a regression test to prove it still matches what it claims to match.

Technical risk. Supply-chain risk is low (dev-only, MIT, no transitive runtime deps beyond php-cs-fixer). The real risks are: (1) abandonment — no upstream fixes, no compatibility work, we inherit ownership permanently; (2) install fragility — a composer update on php-cs-fixer can silently disable the fixers, which is worse than not having them, because the team believes it has a guardrail it does not have; (3) false positives on legitimate exit/die in artisan commands, queue workers, or CLI scripts, and on dump() inside test helpers or intentionally-broken fixtures.

Key questions. Does it support php-cs-fixer 3.x at all, or only ^2.x? Which PHP version constraints are pinned? Does it cover dd, dump, ray, ddd, var_export, and error_log, or only the 2018-era set? Are the fixers token-aware, or regex-based on raw content (the latter mangles strings and comments)? Do they operate on Blade/PHP templates and Pest/PHPUnit files? Is there a @debug/@phpstan-ignore suppression convention? Who owns the port if we adopt?

Integration Approach

Stack fit. PHP 8.x / Laravel 10–12 / php-cs-fixer 3.x on a standard CI pipeline (GitHub Actions or equivalent). The package as published does not fit this stack cleanly; the idea does.

Recommended path (in order of preference):

1. Reimplement as a sniffer. PHP_CodeSniffer with SlevomatCodingStandard's ForbiddenFunctions sniff (or a 20-line custom sniff) banning var_dump, print_r, dd, dump, ray, exit outside an allowlist. Maintained, battle-tested, zero porting cost, and it fails closed.
2. Vendor and port the fixers. Copy the fixer classes into tools/php-cs-fixer/, update to the 3.x FixerInterface, register via a local config, and add a per-fixer unit test asserting matched/non-matched code samples. Keeps auto-fixing rather than just detection.
3. composer require as published. Only viable on a legacy PHP 7.0/php-cs-fixer 2.x codebase. Not our case.

Migration path. No data migration, no schema change, no rollback risk — this is a CI-only change and can be reverted with one config commit.

Compatibility caveats. If the team standardises on Laravel Pint, confirm whether your Pint version supports registering external custom fixers; if not, run php-cs-fixer as a separate CI job rather than abandoning the rule. Pin php-cs-fixer exactly in CI so a minor bump cannot silently no-op the fixers.

Sequencing.

1. Spike: attempt install against current stack, confirm conflict — half a day, closes the question.
2. Decide reimplement vs. port (I would reimplement unless auto-fix is explicitly required).
3. Land as non-blocking CI report for two sprints; measure hit rate and false positives.
4. Flip to blocking, add pre-commit hook, document the suppression convention.
5. Add the same rule to PHPStan or the review checklist so Blade/JS artefacts are covered too.

Operational Impact

Maintenance. Adopting the package as-is means permanent maintenance with no upstream. Ported fixers are small enough (a few hundred lines total) that the ongoing cost is genuinely low — perhaps half a day per php-cs-fixer major version — but it must have a named owner in the platform or developer-experience backlog, or it will rot and become a false sense of security.

Support. No vendor, no issues triage, no CVE feed we can rely on. Because the dependency is dev-only, a compromised or broken release cannot reach production traffic; blast radius is CI machines and developer laptops, which is manageable but not zero (composer scripts, post-install hooks).

Scaling. Negligible. Static analysis over a few thousand files runs in seconds and parallelises well in php-cs-fixer 3.x. No per-request cost, no memory footprint, no effect on deploy size.

Failure modes to monitor.

• Silent no-op after a php-cs-fixer upgrade — the most dangerous mode. Mitigate with a CI self-test: a fixture file containing dd() that must be flagged, failing the build if it is not.
• False positives deleting intentional exit in console commands or dump() in debugging utilities. Mitigate with an allowlist path and a suppression comment convention.
• Coverage gaps — Blade templates, .env dumps, compiled assets, and Pest test files are not covered, so a green build does not mean "no debug statements." Pair with the PHPStan rule and a PR checklist item.
• Token-naive matching mangling strings or docblocks; verify against fixture tests before enabling auto-fix.

Ramp-up. Low for consumers (one config entry, one doc paragraph, one CI gate). Moderate for whoever ports it — a mid-level PHP engineer with php-cs-fixer familiarity needs 1–2 days including tests. The organisational risk is not difficulty, it is the 2018 timestamp: an abandoned 22-star package with zero dependents is a signal that nobody has run this in anger on a modern stack. Treat the score of 1.51 alongside an opportunity of 11.56 as "the problem is real, this artefact is not the solution" — validate the concept, then build or borrow a maintained implementation rather than depending on this one.