Array Undot Laravel Package

Technical Evaluation

What the package is: array_undot performs the inverse of Laravel's array_dot / Arr::dot() helper — it takes a single-level array keyed with dot notation (['user.name' => 'Ada', 'user.roles.0' => 'admin']) and expands it into a nested multi-dimensional array. It is a single-purpose, pure-data transformation utility with no I/O, no persistence, no service dependencies, and no runtime configuration surface.

Architecture fit: Narrow but well-defined. It fits anywhere a configuration, form, or flatten/unflatten boundary exists — hydrating flat env/config payloads into nested structures, round-tripping data through a dot-keyed store, or translating between flat and nested representations at an API or persistence boundary. It is not an architectural component; it is a leaf utility. The correct mental model is "a function we happen to source from Composer," not "a dependency."

Integration feasibility: Trivially high on mechanics — one Composer require, near-zero configuration, no service provider needed in most cases (verify whether the package registers a global array_undot() function via autoload.files, which is the author's common pattern). The real feasibility question is necessity, not effort.

Primary technical risk — redundancy. Laravel shipped a native Arr::undot() in 5.8 (2019). If our stack is Laravel ≥ 5.8, this package duplicates first-party, framework-maintained behaviour and adds a third-party supply-chain link for zero functional gain. That single fact should dominate the decision.

Secondary technical risks:

• Ambiguity and collision semantics. Dot notation is lossy. Keys that legitimately contain dots ('app.version' as a literal key vs. a nested path), empty segments ('a..b'), leading/trailing dots, and partial-path collisions ('a' => 'x' alongside 'a.b' => 'y') all require a defined policy. Silent last-write-wins overwrite is the likely behaviour and is the most dangerous failure mode, because it corrupts data without erroring. Must be verified against our inputs before adoption.
• Numeric segment handling. Whether 'items.0.name' produces a list or a string-keyed array matters for downstream JSON serialization and consumers that distinguish [] from {}.
• License. LGPL-3.0 is a genuine outlier in the PHP ecosystem, which is overwhelmingly MIT. For internal, non-distributed use it is normally acceptable, but for anything redistributed (an SDK, an on-prem appliance, a packaged product) it will trigger legal review and may require shipping the library's source and modification notices. This is a procurement blocker, not a code problem.
• Bus factor. 24 stars, effectively a single-maintainer package. Assume no SLA, no security response process, and no guaranteed compatibility with future PHP majors.

Key questions:

1. What Laravel version(s) are we on, and do we already have Arr::undot() available? If yes, what does this package buy us?
2. Do we have non-Laravel PHP consumers for this logic? If yes, is a ~15-line internal recursive helper simpler than a dependency?
3. Does our dependency policy permit LGPL-3.0, and is the artifact ever redistributed outside the organisation?
4. What are the exact collision and dotted-literal-key semantics we require, and does the package match them?
5. Does the package define a global function that could collide with Laravel or another dependency?
6. Is the input ever user-controlled (request payloads, imported config)? If so, silent key-overwrite becomes an input-validation concern.

Integration Approach

Stack fit: Excellent mechanical fit with Laravel/Composer; it is explicitly designed as the counterpart to a first-party Laravel helper. Poor strategic fit precisely because the framework already solved this. For Symfony, Slim, or vanilla PHP, it fits but competes against a small internal function with no license or supply-chain overhead.

Migration path — recommended order:

1. Native first. If on Laravel ≥ 5.8, use Arr::undot(). Zero new dependencies, first-party maintenance, identical intent. This is the default answer and should require justification to deviate from.
2. Internal helper second. If we need framework-agnostic behaviour or specific collision semantics, write and unit-test a ~15-line recursive function in our own namespace. We control the semantics, the license is ours, and the maintenance cost is lower than tracking an external package of this size.
3. Adopt the package third. Only justified if we need it now, have no capacity to write the helper, and accept the LGPL and bus-factor exposure.

If we do adopt it:

• Pin an exact version in composer.json; do not float.
• Wrap it behind a single internal adapter (e.g., App\Support\ArrayExpander::undot()) with our own contract and tests, so the vendor is swappable in one file. This converts an external dependency into an implementation detail and neutralises the abandonment risk.
• Check composer.json for autoload.files global function registration; if present, confirm no collision with Arr/array_undot elsewhere.
• Add a characterisation test suite covering: dotted literal keys, numeric segments, empty segments, partial-path collisions, deep nesting, and empty input. This is the real integration work, and its size dwarfs the "install" step.

Compatibility and sequencing: PHP version support must be checked against our runtime matrix — a low-traffic package can lag on new PHP majors. Sequence the work as: (a) requirements and edge-case semantics agreed, (b) native-vs-helper-vs-package decision, (c) characterisation tests written first, (d) implementation swapped in behind the adapter, (e) dependency recorded in the SBOM with license classification.

Sequencing risk: Low. This touches a leaf transformation, not a data contract, provided it is introduced behind an adapter. There is no coordinated release or data migration required.

Operational Impact

Maintenance: Near-zero runtime maintenance — the code is a pure function with no external surface. The maintenance burden is dependency lifecycle, not operations: version bumps, PHP compatibility, and periodic review of whether the package still earns its place. In practice, adopting it costs more over a 3-year horizon than a 15-line internal helper. Set a review trigger rather than a recurring task.

Support: No vendor support. Community-only, single maintainer, no security disclosure process. If it breaks, we fix it or fork it. Mitigation: the code is small enough to fork and vendor into our repo in an afternoon, which also dissolves the LGPL redistribution concern (we would carry the license and our modifications). For a 24-star package, "we can fork it" is the honest support plan.

Scaling: Compute scaling is a non-issue — O(n) over input size, negligible for config- and form-scale payloads. Two scaling caveats worth noting:

• Depth. Recursive expansion can hit stack or memory limits on pathologically deep nesting. Guard inputs if depth is unbounded.
• Fan-out. Expansion multiplies key count relative to input; large flat payloads produce proportionally larger nested structures. Not a problem at typical sizes, but it is a memory-doubling step, so avoid it on hot paths processing large batches.

Failure modes:

Ramp-up: Effectively zero for any PHP developer — the concept is one sentence and the API is a single call. The genuine ramp-up is semantic, not syntactic: teams must learn the escaping and collision rules we standardise on, otherwise they will quietly assume the wrong behaviour at call sites. Budget the onboarding time on the edge-case policy document, not on the library.

Overall TPM position: Low technical risk, low operational burden, but equally low value — and the value is largely already provided by the framework. Recommend do not add as a dependency for Laravel ≥ 5.8 projects; use Arr::undot(). For non-Laravel or semantics-sensitive needs, build a tested internal helper. Reserve adoption for cases with an immediate, documented need and a stated willingness to fork, and route the LGPL-3.0 question through legal before any redistribution.