Php Dump Logger Laravel Package

Getting Started

• Confirm platform compatibility before anything else. 3.0.0 targets PHP 8.3/8.4; if you are still on PHP 8.1/8.2 (Laravel 10/11 era), stay on the 2.1.x line.
• Install with composer require salibhdr/php-dump-logger. Because 3.0.0 bumps symfony/var-dumper to ^8, run composer why symfony/var-dumper immediately afterward to see whether Composer actually resolved v8 or whether your Laravel version pinned v7 and blocked the install.
• Look first at the package README for the current helper names and default log path. The package is a thin dump-to-file utility: you call its dump helper instead of dump()/dd(), and output is appended to a log file rather than emitted to the HTTP response or console.
• First use case: an API endpoint or queued job where dump() would corrupt a JSON response or disappear into a worker. Replace dump($payload) with the package helper and inspect the log with tail -f storage/logs/<dump-log> (or whatever path the README/config specifies).
• Decide up front whether you are using it as a local-only debugging aid or as a persistent diagnostic log. That decision drives whether you guard calls with app()->isLocal() and whether you add the log file to .gitignore.

Implementation Patterns

• API/JSON debugging: use the log helper instead of dump() so responses remain valid. Log the variable, continue execution, and tail the file in a second terminal. This is the primary day-to-day use case.
• Queue workers and console commands: dump() is unreliable or invisible in workers; the log helper gives you a durable trail. Log before/after external calls and include an identifier (job ID, order ID) in the message so grep is useful.
• Replace dd() with the “die” variant sparingly: useful in a one-off request, dangerous in queue jobs because it kills the worker process mid-job. Prefer non-fatal logging in async code.
• Context labeling: prepend a short label to the dumped value (or use a label argument if the helper supports one) so a single log file remains searchable: dump_log('checkout payload', $payload).
• Environment guard: wrap calls in a small project helper, e.g. debug_log() that no-ops unless app()->isLocal() or a dedicated env flag is set. This prevents stray dumps from shipping to production.
• Test hygiene: if tests exercise code paths containing log calls, truncate the dump log in setUp() or point it at a temp path; otherwise the file grows across CI runs and can leak fixture data.
• Container/volume awareness: in Docker or Sail, the log path is inside the container. Either bind-mount the log directory or docker compose exec into the container to tail it. Do not assume the host path matches.
• Version pinning: if you maintain packages/apps across PHP 8.2 and 8.4, constrain explicitly (^2.1 for older PHP, ^3.0 for 8.3+) rather than relying on floating constraints.

Gotchas and Tips

• The big one: symfony/var-dumper ^8 vs Laravel. Laravel 10/11/12 constrain symfony/var-dumper to the 7.x line. A hard ^8 requirement in 3.0.0 will conflict with the framework’s own dependency and can make composer require fail or force an unwanted framework upgrade. Check composer why symfony/var-dumper before adopting 3.0.0; if it conflicts, stay on 2.1.1 until Laravel allows v8.
• PHP 8.3 claim vs var-dumper 8: the Symfony 8 component line targets PHP 8.4. A package that requires symfony/var-dumper:^8 while claiming PHP 8.3 support may not actually resolve on 8.3. Verify with composer update --dry-run on your exact PHP version rather than trusting the release note.
• Log growth and rotation: these utilities typically append to a single file with no rotation. Add logrotate, a size check, or manual truncation; otherwise a busy loop fills the disk. A > dump.log truncation is fine locally but not in production.
• Permissions: the PHP-FPM/queue user must be able to write the log path. Permission errors often surface as silent failures or warnings buried in the framework log, not as exceptions from the dump helper.
• Sensitive data: dumps frequently contain tokens, passwords, and PII. Since this writes to disk, treat the dump log as sensitive: gitignore it, restrict permissions, and avoid logging full request/auth objects.
• Fatal “die” helpers in long-running processes: Octane, queue workers, and Swoole processes do not appreciate a hard exit. Reserve the die variant for traditional request lifecycles.
• Config/opcache caching: if you change the log path via config or env, restart Octane/queue workers and clear config caches; otherwise the old path remains in use.
• Autoload/helper registration: if helper functions appear undefined after install, run composer dump-autoload and confirm the package’s files autoload entry is present. If the package registers a global VarDumper handler, remember it affects all dump() calls, including framework internals.
• Extension points: check whether the log path and handler are configurable/publishable. If not, wrap the helper in your own function so you can swap the implementation later without touching every call site.