Dig Laravel Package

Product Decisions This Supports

• Framing the decision correctly: DX line item, not product roadmap. nunomaduro/dig ships nothing to customers, adds no runtime dependency in production, and touches no SLA or uptime commitment. The decision it informs is narrow and honest — "is a shorter terminal debug loop worth an engineer-day of evaluation?" — and it belongs in the developer-experience/tooling budget, not the platform architecture one. Saying this out loud early prevents the package from absorbing review cycles it doesn't deserve.

• Build vs. buy vs. adopt for internal debugging tooling. The real comparison set is the free baseline already installed (dump()/dd(), Symfony VarDumper), a paid inspector (Ray), or a heavier local stack (Xdebug + IDE, Buggregator/Trap) — not "build our own." A 43-star MIT package can only justify itself by beating what engineers already have at zero marginal cost. That bar is genuinely high, and the assessment should state it as the bar.

• Coverage-gap analysis of the debugging workflow. Mature Laravel debugging is browser-request-shaped: Ignition, Telescope, Clockwork, Ray. The uncovered surfaces are Artisan commands, queue workers, scheduled jobs, import/ETL scripts, and Laravel Zero binaries — places where dd() halts execution and dump() floods scrollback. The PM question is concrete and cheap to answer: what share of our debugging time lives in that gap? A skeptical answer kills the proposal at near-zero cost, which is a legitimately useful finding to bank.

• Golden-path and dev-image decisions. If a spike shows traction, the follow-on decision is small: does it enter the standard local dev image, or just a documented "recommended dev tools" list? Given the reversal cost is roughly composer remove plus deleting one wrapper helper, it should go through the lightweight list route — not a mandate, not an approval gate.

• Dependency-policy posture, made explicitly. 43 stars, zero dependents, a single maintainer. Even in require-dev, adoption is a statement about how strict our supply-chain bar is. Under a strict dependency-review or SLSA-style policy this fails today; the PM should decide that consciously rather than discover it during a security review.

• Scope discipline and stated non-goals. Worth writing down before anyone installs anything: this is not observability, not a logging strategy, not a profiling substitute, and never appears in a production image, a CI pipeline, or any code path touching production secrets or PII. Non-halting terminal probes only; VarDumper remains the named fallback.

• A maturity datapoint worth flagging to leadership. The package's own metadata is internally inconsistent — the repo describes a command-line debug tool while accompanying documentation describes a dependency injection container with autowiring and bindings. Those are different products with different use cases. Until that's resolved against the actual source, any scoping, estimate, or use-case claim is speculative. A PM should treat this as evidence of immaturity and a reason to time-box, not to write a spec.

When to Consider This Package

Consider it when:

• A meaningful share of debugging happens in the terminal — Artisan commands, queue workers, long-running processes, CLI tools — and the current loop is "add dd(), re-run, scroll, delete." That loop is the cost being priced.
• You want non-halting, readable inspection in CLI contexts without a paid SaaS inspector or a heavier local stack.
• The work is a time-boxed spike, not a standardization. One day, one branch, one go/no-go with a written report.
• require-dev discipline is already healthy: pinned constraints, lockfile hygiene, composer install --no-dev in production builds, and a grep gate catching stray dig( calls before merge.
• You can absorb small-package maintainer risk, and the cost of removal is measured in hours. It is — which is precisely why the spike is cheap.
• The use case is confirmed against the source, given the self-description ambiguity. Reading vendor/ end to end takes minutes and settles it.

Look elsewhere when:

• Maturity and supply-chain risk dominate. No support contract, no security-response process, no third-party evidence of production use, bus factor of one.
• Debugging is mostly web-request. Ignition, Telescope, Clockwork, and Ray already cover that ground and are far more mature. Don't pay an adoption cost for overlap.
• You need production observability. Structured logs, OpenTelemetry, Sentry — different problem, different budget, different owner.
• You actually want a DI container. If the docs are right and this is a container, that's a platform-architecture decision with a much higher bar, and a 43-star container competing with Laravel's own is not a serious candidate. Do not let the two framings blur into one proposal.
• Your environment can't render a TUI. Interactive terminal output breaks or garbles under non-TTY CI, piped output, Docker without -t, and some SSH sessions. If it garbles in your real setups, that's a hard blocker, not a nuisance.
• You need SLAs, LTS guarantees, or vendor accountability.

How to Pitch It (Stakeholders)

To executives: This is a zero-cost, MIT-licensed, developer-only tool. It ships nothing to customers, adds no runtime dependency, and cannot affect production behavior — the entire downside is a few engineering hours and a pinned require-dev entry. The upside is a shorter debugging loop for engineers who spend real time in the terminal, an area our existing browser-based tooling doesn't reach. Recommendation: approve a one-day spike confined to require-dev, keep the existing toolchain untouched, and defer any standardization decision until the spike reports back with a go/no-go and, ideally, a rough measure of time saved. Two caveats to note up front: there's an open question about what the package actually does (its description and documentation disagree — the spike answers that in hour one), and its maturity signals are thin (43 stars, no dependents, one maintainer).

To engineering: composer require --dev nunomaduro/dig, pinned to an explicit version, local and terminal-only. Read vendor/nunomaduro/dig/src in one sitting — it's tiny — and check composer.json for the autoloaded global helper and PHP/Symfony Console/Termwind constraints before building a habit on it. Wrap it in a single project-local helper that no-ops outside local so there's one grep target and one place to delete. Test it in your actual Docker and SSH setups and check for global-helper collisions before installing. Do not add it to production images or CI; never point it at secrets, tokens, or PII; grep for stray calls before shipping console commands. Keep VarDumper as the documented fallback so the team doesn't split into users and non-users.

The verdict to carry into the room: low strategic value, low cost, low risk — and low maturity, with an unresolved question about what the package actually is. This is an opportunistic trial, not a bet. Revisit standardization only on a clear trigger: a stable 1.x, a second maintainer, meaningful dependent count, or a spike result showing measurable time saved in the terminal gap. Otherwise close it out, keep the free baseline, and spend the attention on something that touches the product.