- What does drew/debug-statements-fixers do?
- It is a dev-only collection of custom php-cs-fixer rules that detects and removes leftover debug calls such as dd(), dump(), var_dump(), print_r(), ray(), and die/exit-style statements from PHP code. It runs during static analysis or CI, not at runtime, and has no service provider or production code path. Think of it as a lint rule packaged as a Composer dependency. It is meant to keep commits and production code free of accidental debugging artefacts.
- Can I install drew/debug-statements-fixers in a Laravel 10, 11, or 12 app on PHP 8.x?
- Probably not cleanly. The last release was 2018-04-19 and predates php-cs-fixer 3.x, which changed the FixerInterface contract, including getName() removal and supports() semantics. A modern Laravel app on PHP 8.x will almost certainly hit a Composer dependency conflict. The practical path is to vendor and port the fixer classes or reimplement the rule with a maintained tool, so do not assume composer require will work without a spike.
- Does it support php-cs-fixer 3.x?
- No, not as published. The package was released before php-cs-fixer 3.x and targets the 2.x FixerInterface. Porting requires updating each fixer to the 3.x contract and registering it through a local config. Pin php-cs-fixer exactly in CI so a minor bump cannot silently disable the fixers.
- Does it work with Laravel Pint?
- The package is described as Laravel Pint fixers, but under the hood it provides custom fixers for friendsofphp/php-cs-fixer, which Pint wraps. Whether Pint can register external custom fixers depends on your Pint version, so confirm that first. If your Pint version cannot register them, run php-cs-fixer as a separate CI job rather than dropping the rule. You may also need to port the fixers to the current php-cs-fixer contract before Pint can use them.
- Which debug statements does it remove?
- The documented set covers dd(), dump(), var_dump(), print_r(), ray(), and die/exit-like statements. Because the package dates from 2018, verify coverage of newer conventions such as ddd(), var_export(), and error_log() in the source before relying on it. Each fixer is small, roughly 30 to 80 lines, so adding missing patterns during a port is feasible. Treat the published list as a starting point, not a guarantee.
- Is drew/debug-statements-fixers safe to use in production?
- It is not a runtime library and has no production code path, service container binding, or Laravel provider, so it does not ship to production. It runs only in the dev/CI lane as a static-analysis pass. The real production concern is a false sense of safety: if a php-cs-fixer update silently disables the fixers, your team may believe it has a guardrail it does not have. Pin the tool version and verify the fixers actually run.
- Will it flag legitimate exit or die calls in Artisan commands and queue workers?
- It can. The fixers target die/exit-style statements, but legitimate uses exist in Artisan commands, queue workers, and CLI scripts. It may also match dump() inside test helpers or intentionally broken fixtures. You need an allowlist or suppression convention, and you should run the rule as a non-blocking CI report for a couple of sprints to measure false positives before making it blocking.
- How do I suppress or ignore a debug statement?
- The package does not document a suppression convention such as @debug or @phpstan-ignore. If you port the fixers or reimplement the rule, add one explicitly, for example an inline ignore comment or an allowlist for known-safe exit/die locations. PHP_CodeSniffer-based alternatives support standard ignore annotations out of the box. Document the convention so developers do not disable the whole rule to silence one false positive.
- What are the best alternatives for banning dd(), dump(), and ray() in Laravel?
- Use PHP_CodeSniffer with SlevomatCodingStandard's ForbiddenFunctions sniff, or a roughly 20-line custom sniff, to ban var_dump, print_r, dd, dump, ray, and exit outside an allowlist. That approach is maintained, battle-tested, and fails closed. If you need auto-fixing rather than detection, vendor and port these fixers into tools/php-cs-fixer/ with per-fixer tests. Also add the same rule to PHPStan or your review checklist so Blade and JavaScript artefacts are covered.
- Is drew/debug-statements-fixers still maintained, and should we adopt it?
- No upstream maintenance is evident; the last release was in 2018. Supply-chain risk is low because it is dev-only and MIT-licensed with no runtime dependencies beyond php-cs-fixer, but adopting it as-is means inheriting permanent ownership. The realistic options are reimplementing the rule with PHP_CodeSniffer or vendor-and-porting the fixers with regression tests. For a modern Laravel stack, composer require as published is only viable on legacy PHP 7.0/php-cs-fixer 2.x codebases.