Php Dump Logger Laravel Package

Technical Evaluation

Architecture fit. salibhdr/php-dump-logger is a developer-tooling package, not a runtime dependency. It intercepts dump()/dd()-style output and routes it to log files rather than the response body or stdout, which makes it relevant to Laravel teams debugging queue workers, API-only apps, and containerized environments where var-dumper output is lost. Architecturally it is a thin wrapper over symfony/var-dumper, registered as a service provider with config publishing — low coupling, no persistence layer, no impact on request lifecycle beyond dev-mode bootstrapping. It is a poor fit for anything in the production dependency graph and should be constrained to require-dev.

Integration feasibility. Trivially installable in principle: one Composer require plus an optional config publish. The 3.0.0 release does not change the public API — no new commands, no config schema changes, no renamed classes are announced. The entire breaking surface is the dependency constraint bump. That means code-level integration effort is effectively zero for existing adopters; the work is entirely in dependency resolution.

Technical risk. The dominant risk is the symfony/var-dumper ^8 constraint. ^8 excludes versions 6.x and 7.x, which are what current Laravel releases pin transitively. Any Laravel application that has not itself moved to Symfony 8 components will fail composer update with a conflict, and composer require will either refuse or downgrade var-dumper in ways Laravel's own constraints forbid. Concretely: this release likely makes the package uninstallable on the Laravel versions most teams are running today. Secondary risks are the unannounced PHP floor bump (8.3+ implied by the support statement — 8.2 and below are effectively dropped, though the release notes are silent on the minimum) and the fact that a major version was spent on dependency hygiene with no functional payoff for consumers. Note also that release notes make no mention of deprecations, removals, or a migration guide, which for a semver-major is itself a signal of thin release discipline.

Key questions. (1) Is symfony/var-dumper 8.x actually installable on the Laravel versions we target, or does this release only serve Symfony 8 / Laravel 13-era stacks? (2) Is there a ^7 || ^8 constraint planned, and if not, why was a hard major bump chosen over a widened constraint? (3) What is the actual PHP minimum in composer.json — 8.2 dropped or retained? (4) Who maintains this package, what is the release cadence and issue-response history, and is there a tagged support window? (5) Does it conflict with laravel/telescope, ray, or Ignition, all of which touch the same dump pipeline?

Integration Approach

Stack fit. Suitable only as a require-dev entry in Laravel applications that need dump capture in non-HTML contexts — queue workers, Artisan commands, Octane workers, CI container logs. It is not appropriate for packages, libraries, or anything distributed to third parties, since a dev-only tool should never appear in a library's own dependency graph. Teams standardized on Ray, Telescope, or plain Monolog channel logging should treat this as redundant rather than additive.

Migration path. For an app already on 2.1.1: do not upgrade reflexively. Run composer why-not salibhdr/php-dump-logger 3.0.0 first. If the blocker is Laravel's own symfony/var-dumper ^6|^7 constraint, the correct action is to stay on 2.1.1 — it remains functional and the 3.0.0 delta offers nothing but PHP 8.3/8.4 support, which 2.1.1 likely already runs on in practice. Pin to ^2.1 with an explicit note in the repo, and revisit when the framework line moves to Symfony 8. New adopters on current Laravel should attempt 2.1.1 rather than 3.0.0, or defer entirely.

Compatibility. Verify three things before any install: the app's Laravel version, its resolved symfony/var-dumper version, and its PHP version. There is no indication 3.0.0 introduced a compatibility shim for the 7.x line, so treat 2.x and 3.x as occupying disjoint framework generations. There is also no stated deprecation runway bridging them — a gap that will strand 2.x users when it is eventually abandoned.

Sequencing. (1) Inventory whether any team actually uses the package; a dev tool with no active users should be removed rather than upgraded. (2) If used, freeze at 2.1.1 and confirm the pin holds in CI. (3) Add a scheduled dependency-review check that re-evaluates when the app's Symfony constraint widens. (4) Only then evaluate 3.0.0 in a throwaway branch, and require the maintainer to publish a ^7 || ^8 constraint or an explicit rationale before adopting.

Operational Impact

Maintenance. Low steady-state cost — dev dependency, no schema, no runtime state, no data to migrate. The real burden is dependency-graph churn: a package that hard-bumps a Symfony major forces lockfile conflicts that surface as failed builds in unrelated PRs, which is disproportionately expensive for a logging convenience. Budget for periodic constraint-conflict triage, not for code changes.

Support. Upstream is a single-maintainer GitHub project with no vendor backing, no LTS statement, and 3.0.0 shipping without a migration note. Bus factor is the primary concern; the failure mode is not a broken feature but silent abandonment, which for a dev tool means a pinned, slowly rotting dependency. Treat the package as replaceable — the underlying capability is a few dozen lines over var-dumper, and an in-house log channel or a dd() replacement is a realistic exit.

Scaling. Effectively irrelevant — it does not sit on a request path and has no throughput characteristics. The one scaling-adjacent concern is log volume: routing dumps to files in high-frequency queue workers or Octane workers will write far more than screen output ever did, so log rotation, disk quotas, and a hard discipline of never enabling it outside local/CI are mandatory. Left enabled in staging, it is a disk-fill vector.

Failure modes. (1) Install/resolve failure from the ^8 constraint — most likely, most immediate. (2) Silent no-op if the service provider is registered but configuration is not published, producing false confidence that dumps are being captured. (3) Conflict with overlapping dump-interception tools producing duplicate or suppressed output. (4) Log-driven disk exhaustion in containerized environments without rotation. (5) Version drift where the app downgrades var-dumper to satisfy the package and breaks another dev dependency — the worst case, since the package appears to be the cause only after the fact.

Ramp-up. Negligible for developers familiar with Laravel service providers — an hour including verification. The non-obvious parts are the constraint troubleshooting and the config-publish check, both of which should be written into onboarding notes rather than learned per-engineer. Reviewers should be told plainly that 3.0.0 is not adoptable on the current framework line, so the version question does not get re-litigated in every PR.