Php Var Dump Check Laravel Package

Getting Started

Install it as a dev dependency — this is a pre-production guardrail, not a runtime library:

composer require --dev guni/php-var-dump-check

Before anything else, open composer.json inside vendor/guni/php-var-dump-check/ and read the bin key. The package ships a CLI entry point, but the executable name is the one thing you must confirm up front; run it via vendor/bin/<binary> rather than guessing. If there is no bin entry, the package exposes a class you invoke from a small custom script instead — check src/ for the scanner class and its public method signature.

Run it against your source tree:

vendor/bin/var-dump-check src/

Then deliberately break it: drop a var_dump($user); into a controller, run the command, and confirm a non-zero exit code plus a file/line report. That single test tells you whether the tool is CI-usable at all, and it is the only smoke test that matters.

The first real use case is CI. A forgotten var_dump() in a controller is the classic "works on my machine, dumps the whole Eloquent model into the HTTP response in production" bug. Wire the check into your pipeline before you invest in pre-commit hooks or editor integration — CI is the gate that cannot be bypassed with --no-verify.

Implementation Patterns

Composer script as the single entry point. Never let CI call the binary directly; give the team one command and let CI reuse it.

{
  "scripts": {
    "check:dump": "var-dump-check app/ routes/ config/",
    "check": [
      "@check:dump",
      "@phpstan",
      "@php-cs-fixer"
    ]
  }
}

Now composer check locally is byte-identical to what CI runs, which kills the "passed locally" class of failure.

Pre-commit hook, scoped to staged files. A full-tree scan on every commit gets slow and gets disabled. Scan only what is being committed:

#!/bin/sh
files=$(git diff --cached --name-only --diff-filter=ACM -- '*.php')
[ -z "$files" ] && exit 0
vendor/bin/var-dump-check $files

Because the tool takes paths as arguments, this works without any special "changed files" mode. Keep the CI full scan as the backstop for anything that slips through git commit --no-verify.

CI job as its own step. Put it before the test suite so a stray dump fails fast and cheaply:

- run: composer install --no-interaction --prefer-dist
- run: composer check:dump

Separate step, not folded into a generic "lint" step — when it fails you want the job name to say exactly what broke.

Pair it with a wider banned-function grep. The tool targets variable dumping specifically. Teams usually also want dd(), dump(), print_r(), var_export(), and die()/exit() in web request paths. If the package's config allows a custom function list, use it. If not, run a companion grep in the same job:

! grep -rnE '\b(dd|dump|print_r|var_export)\s*\(' app/ routes/

Two tools with overlapping coverage is fine; a false negative in production is not.

Legacy codebase onboarding. On a mature repo you will get hundreds of hits, most of them legitimate (debug helpers in test fixtures, a var_dump inside a deliberately-broken fixture). Do not try to fix them all in one PR. Either exclude those directories (tests/, fixtures/, database/seeders/) via whatever ignore/exclude mechanism the package supports, or commit a baseline of known files and only fail on new offenders. Ratchet the exclusions down over subsequent sprints.

Editor integration. A real-time search is faster feedback than a commit-time hook. Add a project-level search template or a .git/hooks-adjacent IDE inspection for var_dump so the developer sees the squiggle while typing, and treat the CLI as the enforcement layer. The two are complementary: the IDE prevents the mistake, the CLI proves its absence.

Gotchas and Tips

String and comment false positives. Naive matchers will flag "call var_dump() to debug" inside a docblock or an error message. In a codebase with documentation-heavy comments, this alone can make the tool unusable. Verify how it tokenizes: a proper implementation uses token_get_all() and only inspects T_STRING tokens followed by (, which correctly skips comments and string literals. If your first run reports hits in comments, that is a signal to check the implementation before trusting the results — and to consider a tokenizer-based alternative.

Qualified and namespaced calls. \var_dump($x) and var_dump ($x) (with a space) are easy edge cases to miss. Test both explicitly. Laravel's dump() and Symfony's dump() also belong on your radar even if the tool does not cover them.

Exit codes are the whole contract. A finder that prints findings but exits 0 is worthless in CI. Confirm the failure path returns non-zero, and confirm the success path returns 0 (not an error code) so the job does not fail on clean trees. If the binary exits non-zero on clean runs — for instance because a path argument did not exist — your pipeline will be red for the wrong reason and people will start ignoring it.

File extensions. Most scanners default to *.php. That leaves .blade.php, .phtml, .php.dist, and .inc uncovered. Blade files are a common place for a leftover @php var_dump($x) @endphp. Check whether you can pass globs or an extension list; if not, add a separate grep for those paths.

Path arguments and vendor. Always pass explicit paths (app/ routes/) rather than scanning . — scanning the repo root pulls in vendor/, node_modules/, storage/, and cached compiled views, which is slow and produces noise from third-party code you cannot fix. If the tool has no default excludes, this is the number one reason people conclude "it's too slow."

Debugging a surprising result. When the tool reports a hit you cannot find, search the exact reported line number in the file — it is almost always a generated file, a cached compiled view, or a fixture you did not know existed. Run the tool against a single file path to confirm the report is reproducible in isolation before opening an issue.

Extension points. Two things are worth checking in the source: whether the banned-function list is configurable (so you can add dd/dump without a second tool), and whether the scanner exposes its findings programmatically rather than only via the CLI. If findings are returnable as data, you can write a custom reporter that posts inline PR comments via your CI provider — a much better developer experience than a wall of stdout.

Version pinning. With a single maintainer and a 0.x-era package, pin the version in composer.json and review changelogs on upgrade. A scanner whose matching logic silently changes will flip your CI from green to red across a dependency bump, and the failure will look like a code problem rather than a tooling problem.