Php Var Dump Check Laravel Package

Technical Evaluation

Architecture fit The package is a development-time static analysis utility, not a runtime dependency. It scans PHP source files for forgotten debug calls (var_dump, print_r, and — if supported — Laravel/Symfony helpers dd, dump, ray). That places it in the same architectural tier as Pint, PHP_CodeSniffer, or PHPStan: a shift-left quality gate that never ships to production, adds no autoloaded code to the request lifecycle, and has no coupling to Laravel's container, service providers, or config system. For a TPM this is the cheapest possible integration shape — no application code changes, no runtime risk, no performance budget consumed.

Integration feasibility Feasible but unproven. Three unknowns must be closed before committing: (1) is it published on Packagist with semver tags, or must it be pulled via a vcs repository entry pointing at a personal GitLab namespace; (2) does it declare a PHP constraint compatible with the runtime (8.1/8.2/8.3) and a require-dev-only footprint; (3) does it return a non-zero exit code on findings, since a tool that always exits 0 is worse than nothing in CI. Detection method also matters: regex-based scanners are fast but miss namespace-qualified calls (\var_dump), method calls ($dumper->dump()), and multi-line expressions, and they false-positive on strings, comments, and heredocs. An AST-based implementation (nikic/php-parser) is more accurate but drags in a dependency that frequently conflicts with existing PHPStan/Pint versions.

Technical risk The dominant risk is provenance, not code quality. Zero stars, zero dependents, a personal GitLab namespace, and no visible community creates meaningful abandonment and deletion risk — a repository removal breaks composer install for every developer and every CI run. Secondary risks: single-maintainer bus factor, no security disclosure path, unvetted code executing inside CI with access to repository contents and secrets, and unknown behavior on large trees (does it exclude vendor/, storage/, bootstrap/cache/ by default?).

Key questions

• Is it on Packagist with tagged releases and a permissive, clearly stated license?
• Which patterns does it detect, and does it cover dd, dump, ray, var_export, print_r?
• Regex or AST? How does it handle commented-out code, strings, and heredocs?
• Does it support path exclusion, an allowlist/baseline, and machine-readable output (JSON/SARIF)?
• Exit code semantics, and is there a configurable severity threshold?
• Last commit date, open issue count, PHP version matrix, and CI status of the package itself?

Integration Approach

Stack fit Install as a require-dev Composer package and wire it into three layers, cheapest first: a Composer script (composer lint:debug), a pre-commit hook via CaptainHook or GrumPHP for sub-second developer feedback, and a dedicated CI job in the static-analysis stage. It should sit alongside Pint and PHPStan, not replace either.

Migration path Do not adopt directly. Introduce through a thin internal wrapper script (e.g., bin/check-debug-calls) that shells out to the tool and normalizes exit codes and output. The wrapper is the seam: if the package is abandoned or proves noisy, swap the implementation for a PHP_CodeSniffer sniff, a custom PHPStan rule, or a scoped git grep without touching a single CI config or hook definition. Given the adoption signals, treat the package as a candidate implementation of a policy, not as a dependency to standardize on.

Compatibility Validate the PHP constraint against the application runtime before merging, and ensure it resolves without --ignore-platform-reqs. Check for nikic/php-parser version overlap with existing tooling — this is the most common source of dev-dependency conflicts in Laravel repos. Confirm it does not require a Laravel service provider or config publish; if it does, verify the supported Laravel version range explicitly.

Sequencing

1. Read-through of the source (30–60 min) to answer the detection and exit-code questions.
2. Time-boxed spike on a representative repository in a throwaway branch.
3. Run in report-only mode for one sprint; measure true positives, false positives, and runtime.
4. Promote to a blocking pre-commit hook if the false-positive rate is tolerable.
5. Promote to a required CI check; publish a baseline/allowlist for legacy violations so the gate is green on day one.
6. Add to the new-project repository template so it is default-on rather than retrofitted.

Operational Impact

Maintenance Effectively unmaintained upstream. Pin an exact version, mirror the repository into the organization's GitLab group or vendor the source, and record an internal owner. Budget a contingency: if the tool is still in use in six months and upstream is dormant, forking a ~few-hundred-line scanner is a day of work — but only if the wrapper seam exists.

Support No vendor, no SLA, no security process. Support burden falls entirely on the platform/DevEx engineer who owns the wrapper. Document the tool, the policy it enforces, and the escalation path in the engineering handbook; add the fork/mirror location to the dependency inventory.

Scaling File-scan cost is linear and negligible relative to a test suite — acceptable even for monorepos, provided exclusions cover vendor/, node_modules/, storage/, and compiled Blade caches. There is likely no incremental caching, so for very large repositories scope the CI invocation to changed files (diff-based) and keep the full scan as a nightly job.

Failure modes

• Silent pass: tool exits 0 on findings or errors — must be asserted in a smoke test with a deliberately planted dd().
• Supply-chain break: upstream deletion or Packagist outage blocks installs — mitigated by mirroring and version pinning.
• Build-breaking false positives on legitimate debug wrappers or test fixtures — mitigated by allowlist and rollout in report-only mode.
• Coverage gap: dumps inside Blade templates, generated code, or string contexts are invisible — pair with a code-review checklist item; the tool is a safety net, not the control.
• Config drift: exclusions silently widen over time until the gate is toothless — review the config quarterly alongside the PHPStan baseline.

Ramp-up Near-zero for application developers: it behaves like a linter and produces an obvious message. Real ramp cost is one platform engineer for roughly half a day to spike, wire the wrapper, and write the runbook — plus a short onboarding note. Given the low adoption signals, the TPM recommendation is a time-boxed evaluation framed under an existing release-hygiene workstream, with a documented fallback to a first-party sniff or grep rule rather than a standalone adoption initiative.