Array Undot Laravel Package

Product Decisions This Supports

• Configuration and settings hydration. Any feature that stores configuration as flat dot-notation keys (env-style overrides, key-value settings tables, tenant-level overrides) needs a reliable "expand into nested structure" step before it can be consumed by typed config objects. This package is that step.
• Build vs. buy vs. use-the-framework. The decision this most directly informs is whether to write our own dot-expansion helper. For Laravel shops the answer is usually "use Arr::undot()" — meaning the real product decision is not adopting this package, and documenting the native path in our engineering standards instead.
• Feature-flag and dynamic-config rollout. Flag payloads delivered as flat maps (checkout.v2.enabled, pricing.tiers.pro) must be expanded before merging into app config. This supports roadmap items around progressive delivery without introducing a config service.
• Data import and integration mapping. CSV/spreadsheet imports and third-party webhooks frequently arrive as flat header→value maps; expanding to nested arrays lets us reuse existing validation, model-fill, and transformer layers rather than writing per-integration mappers.
• API/serialization contracts. Supports use cases where a client expects nested JSON but our source of truth is a flat store (or vice versa), useful for backward-compatible API versioning work.
• Not a differentiator. This is infrastructure glue, not user-facing capability. It should never appear on a roadmap as a feature; it is a line item in an engineering spike at most.

When to Consider This Package

Consider it only when all of the following hold:

• We are on a non-Laravel or pre-Arr::undot PHP codebase, or we deliberately want a framework-agnostic utility shared with a non-Laravel service.
• The input is genuinely flat dot-notation and we need expansion with no type coercion, casting, or schema awareness — this package does string-key expansion and nothing more.
• We want a tiny, single-purpose, low-ceremony dependency rather than pulling in a larger config or collection library.
• We have cleared LGPL-3.0 with legal. Copyleft-by-library licensing is fine for most SaaS deployments (dynamic linking, no modification), but it triggers review in some enterprise procurement processes and in any product that ships PHP source to customers.

Look elsewhere — or simply write the ~10-line helper — when:

• We are on Laravel 5.5+. Arr::undot() is native, maintained by the framework, and removes the dependency entirely. This is the default case and should be the documented recommendation.
• We need collision semantics defined (what happens when user and user.name both exist), numeric-key handling for lists, or guaranteed behavior for empty segments and malformed keys. The package is small and unopinionated; these become our bugs.
• We need validation, casting, or schema enforcement alongside expansion — reach for a config/DTO hydration library instead.
• We need performance at volume (per-request expansion of thousands of keys). Benchmark first; a hand-rolled iterative implementation with pre-allocated arrays may be faster than a generic recursive helper.
• Supply-chain posture matters more than convenience. 24 stars and a single maintainer is a real (if small) ongoing-risk line item for a dependency we could vendor in one function.

Given the above, my recommendation is a one-time engineering decision record: use Arr::undot() where Laravel is present, vendor a small internal helper otherwise, and treat this package as a useful reference implementation rather than a dependency.

How to Pitch It (Stakeholders)

For executives: This is a micro-utility that converts flat "dotted" key-value data into nested configuration arrays. It is not a product capability and carries no direct revenue impact. The relevant decision is a small one: whether to add a third-party dependency or use functionality Laravel already ships. I recommend the latter, which means no new dependency, no license review, no added maintenance surface — the package serves mainly as a validated reference for a helper we can implement internally in a few lines if a non-Laravel service ever needs it.

For engineering: array_undot is the inverse of array_dot and does exactly one thing, with no casting or validation. If you're on Laravel, Arr::undot() is equivalent and already in the framework — prefer it. Adopt this package only for framework-agnostic contexts or legacy PHP services, and if you do, pin the version, confirm LGPL-3.0 with legal, and write contract tests for the edge cases the package doesn't specify (key collisions, numeric segments, empty segments). Do not let it spread as a transitive convenience dependency; keep the call sites behind a single internal adapter so we can swap it for the native helper later at zero cost.