- What is nunomaduro/dig used for?
- Dig is a lightweight, framework-agnostic PHP utility for reading deeply nested values out of arrays and objects using dot-notation paths such as user.address.city. It exists to remove the repetitive isset() and null-check chains developers write when pulling values from API responses, configuration trees, or complex payloads. It has zero dependencies and returns a default when a path does not exist. Published registry descriptions of this package are inconsistent, so confirm actual behaviour against the vendor source before standardising on it.
- How do I install nunomaduro/dig with Composer?
- Install it with a single Composer command, preferring a dev install: composer require --dev nunomaduro/dig. Because the package is framework-agnostic there is no service provider, facade, or config file to publish in a Laravel app. Pin the constraint in composer.json and run composer install --no-dev for production builds. Check the repository README for the currently supported version constraint and PHP requirement.
- Does Dig work with Laravel, or only plain PHP projects?
- It runs anywhere PHP 8 or newer is available, which includes Laravel applications, Laravel Zero binaries, Artisan and queue contexts, and standalone PHP scripts. There is no framework bootstrapping or container binding, so it works with any Laravel version running on a supported PHP release. It does not replace or require Illuminate components, which is what makes it usable outside a Laravel app.
- How do I read a deeply nested value with dot notation using Dig?
- You pass the source array or object together with a dot-notation path, and the package walks each segment in a single expression instead of a chain of nested array accesses. Depth is arbitrary, so paths of three, five, or ten segments are handled the same way. Confirm the exact method or helper signature in the README or vendor/dig source before you standardise on it across a codebase.
- What does Dig return when a nested key or path does not exist?
- It returns a default value you supply rather than throwing an exception or emitting a warning or notice. That default is usually null but can be any value you want to fall back to. This is precisely what lets you delete defensive isset() and array_key_exists() checks from call sites and keep data access to one readable line.
- Can Dig read nested values from objects and mixed array/object data?
- Yes. It supports arbitrary depth and tolerates structures where arrays and objects alternate along the same path, such as decoded JSON containing stdClass nodes or Eloquent models nested inside arrays. That makes it suitable for API payloads and configuration trees that mix both shapes. Note that it only retrieves values; it does not cast, transform, or hydrate them.
- Is Dig a replacement for Laravel's data_get() or Arr::get()?
- No. Laravel's data_get() and Arr::get() already provide comparable dot-notation access, so inside a normal Laravel application Dig adds little. Its value is code that lives outside the Laravel container, such as Laravel Zero binaries, standalone scripts, and reusable packages that cannot assume Illuminate is installed. If you are already inside Laravel, data_get() is the simpler default.
- Should Dig be installed as a require or a require-dev dependency?
- Treat it as developer tooling and install it under require-dev alongside VarDumper, Pest, and Collision. It has no request-path footprint, no data contract, and no bearing on uptime, so it should never end up in production autoloads. Enforce that boundary with a pinned version constraint, composer install --no-dev in production builds, and a CI check that the package does not appear in shipped dependencies.
- What are the maintenance and supply-chain risks of using Dig?
- The project is small: roughly 43 GitHub stars, no dependents, a single maintainer, and no stated security-response process or LTS policy, which means it will not pass a strict supply-chain review today. It is only acceptable under require-dev with a pinned constraint, and it is cheap to reverse because replacing it means swapping a handful of dot-notation calls. If the package autoloads a global helper, run a quick collision check against other globally autoloaded helpers in your dependencies before adopting it. Treat the low maturity as a reason to time-box a trial, not to write a design spec.
- How do I test code that uses Dig, and what configuration does it need?
- There is no configuration to publish and nothing to boot, so unit tests can call the package directly against fixture arrays and objects and assert on the returned value or the fallback default. Add cases for missing paths, null intermediate values, and mixed array/object nesting, since those are where naive access code usually breaks. If you adopt it, document the named fallback such as data_get() for in-app code so the choice does not become an undocumented local quirk.