Filter Via Dot Access Data Laravel Package

Product Decisions This Supports

• CLI output shaping as a user-facing feature. The package supplies the primitive behind --fields=id,name,user.profile.email and simple key-path filtering of nested output. This directly supports decisions like "do we let CI/ops users select columns in our CLI reports?" without building a bespoke selector per command.
• Export and reporting scope. The same dot-path lookup powers CSV/JSON column selection, "choose columns" in admin tooling, and trimmed machine-readable output for scripts — a recurring request in internal tooling and data-migration workflows.
• Build vs. buy for a commodity capability. At ~one class of logic, this is a buy (or vendor) decision only if you're already in the Consolidation ecosystem (Robo, Drush, WP-CLI-adjacent tooling). Otherwise it's a build decision, and cheap to build.
• Consistency across a command suite. Standardizing dot-notation semantics across many commands reduces divergent flag behavior, documentation sprawl, and "why does --fields work differently here?" support load.
• Representative use cases: internal admin CLIs, report/export commands, seed and migration scripts, log filtering, CI helper tooling.
• Not a differentiator. Nothing here should appear on a roadmap as a feature bet; it's plumbing that de-risks a small class of requests.

When to Consider This Package

Adopt when:

• You already depend on Consolidation tooling and want identical --fields/--filter semantics with near-zero integration cost.
• Your need is strictly read-only key-path selection on nested arrays — no operators, no grouping, no type coercion.
• You accept it is effectively frozen: last release January 2019. Pin the version and treat it as vendored code.
• The surface is developer-facing or internal, where a stale dependency is tolerable.

Look elsewhere when:

• You need comparison operators (>, contains, regex), boolean composition, sorting semantics, or joins — use a query layer, a Collection pipeline, or a real filter expression parser.
• License compliance is strict. The manifest reports NOASSERTION; legal review is required before shipping. It is very likely permissive, but "likely" is not a clearance.
• You need active maintenance or a security response path for a customer-facing surface. There is none.
• You are on current PHP versions and cannot verify compatibility; the code is trivial to reproduce.
• You can get this for free in Laravel. data_get() and Arr::get() already do dot-notation lookup. Reimplementing the wrapper is roughly 50 lines and removes the dependency, the license question, and the abandonment risk in one move.

Default recommendation: reimplement in-house unless the Consolidation ecosystem is already load-bearing.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost utility that standardizes how our command-line tools let users pick and filter output. It removes duplicated custom flag logic and a recurring category of support requests. It is commodity plumbing, not a competitive feature — the relevant risks are maintenance and licensing, not capability, and both are contained.

To engineering: A thin wrapper over dflydev/dot-access-data exposing dot-path selection on nested arrays. Vendor it behind an internal adapter interface so it can be swapped for Laravel's data_get/Arr or a fork without touching call sites. Before adoption: pin the version, resolve the NOASSERTION license (read the actual license file in the repo), and add a smoke test across the PHP versions we support — the 2019 release predates our current runtime and that needs verification, not assumption.

Bottom line: safe as an internal convenience, wrong as a foundation. The build cost is low enough that owning the ~50 lines is usually the better PM call.