Php Dot Array Laravel Package

Technical Evaluation

Architecture fit

• Single-responsibility utility: dot-notation accessors over nested arrays (get/set/has/delete, plus wildcard matching). This is a leaf dependency with no framework coupling, no service provider, no config, no migrations — it slots in as a static helper or a small injectable class.
• The critical architectural question is duplication. Laravel already ships Illuminate\Support\Arr::get/set/has/forget and the data_get/data_set/data_fill helpers, which cover dot-notation read/write and (in Arr::has) wildcard checks. Any Laravel-native adoption therefore needs a clear justification: wildcard write/delete semantics, stricter typing, exception behavior, or use outside the framework boundary (queued jobs, shared libraries, non-Laravel services in the same monorepo).
• For non-Laravel PHP code (CLI tools, SDKs, WordPress/legacy apps, package internals that must not depend on illuminate/support), the value proposition is stronger: pulling in the full illuminate/support package for four array helpers is a poor trade against a ~10-star micro-package.
• Risk of "yet another array helper" drift: if the codebase mixes Arr::, data_get, and this package's API, cognitive overhead and inconsistent wildcard behavior become a maintenance tax for near-zero functional gain.

Integration feasibility

• Install is a one-line composer require pharaonic/php-dot-array; no publishable assets, no bootstrapping, no environment variables. Integration effort is measured in hours, not sprints.
• Blocking unknowns are package hygiene, not architecture: PHP version constraint (^8.x?), PSR-4 autoload correctness, whether the API is static-only or instance-based, and whether wildcards apply to set/delete or only get/has. These need to be confirmed from the actual source and README before sign-off.
• The repository is listed as unknown in our metadata. That is a supply-chain vetting blocker: we cannot review source, CI status, test coverage, or maintainer identity from the record alone.

Technical risk

• Maturity / bus factor (high): 10 stars, unknown repository, no visible contributor base. This is a single-maintainer package with effectively no community backstop.
• Abandonment (medium-high): The surface area is small enough that we could vendor or fork it in an afternoon — which caps the downside but also caps the strategic value of adopting it as a dependency.
• Metadata integrity (medium): The recorded last release (2026-10-08) must be reconciled against the actual tag history on Packagist and the repository. A mismatch signals stale or scraped metadata, which undermines confidence in the rest of the record.
• Behavioral edge cases (medium): Dot notation collides with array keys that legitimately contain dots (e.g., config keys, JSON payloads with dotted field names, Elasticsearch-style keys). Wildcard expansion against large or sparse arrays can also be ambiguous (what does delete('a.*.b') do on partially populated nodes?). These need explicit test cases before adoption.
• Security surface (low): Pure in-memory array manipulation, no I/O, no deserialization, no eval. MIT license is permissive and unproblematic. Primary risk is correctness, not exploitation.
• Lock-in (low): Trivial API, trivially replaceable.

Key questions

1. Does the package do anything Laravel's Arr/data_get cannot? If not, why are we adding a dependency?
2. Is the API static, instance-based, or both — and does it throw or return null/default on missing paths?
3. What are the documented semantics for wildcards on set and delete, and how are dotted literal keys escaped?
4. What are the PHP version constraints, and does it support PHP 8.1–8.4?
5. Is there a test suite, CI pipeline, and static analysis (PHPStan/Psalm) in the repo?
6. Who maintains it, what is the release cadence, and is there a security contact?
7. Can we vendor the ~200 lines under our own namespace if the dependency lapses?

Integration Approach

Stack fit

• Treat it as an application-layer utility, not infrastructure. It belongs in domain/service code that manipulates configuration-shaped or payload-shaped arrays, not in framework bootstrapping.
• Best fit: (a) non-Laravel PHP services and shared libraries in a polyglot monorepo, (b) code paths that must stay framework-agnostic (SDK packages, queue workers extracted from the app), (c) teams that want consistent wildcard write/delete semantics that Arr does not offer.
• Poor fit: greenfield Laravel apps where Arr::get/Arr::set already cover 100% of the need. Introducing it there is unnecessary dependency surface.

Migration path

• Phase 0 — vet: mirror the repository internally, read the source in full, run it against our own edge-case fixture set (dotted literal keys, null intermediate nodes, numeric segments, wildcards, empty arrays, very deep nesting).
• Phase 1 — constrain: pin an exact version in composer.json (avoid ^ while the package is pre-1.0 or thinly maintained), commit composer.lock, and add a composer audit / Dependabot hook.
• Phase 2 — wrap: expose a thin internal adapter (e.g., App\Support\ArrayAccess) that delegates to the package. This is the single most important step — it converts an external dependency into an internal interface we control, so swapping to Arr or a vendored fork is a one-file change.
• Phase 3 — adopt incrementally: introduce in one bounded module or new code first; do not do a repo-wide sweep of existing Arr:: calls. Replace existing helpers only where the package demonstrably improves behavior (wildcard deletes, typed returns).
• Phase 4 — standardize: document the convention in the engineering style guide ("use the adapter, not raw Arr:: or the package facade") and add a lint/architecture rule if feasible.

Compatibility

• Verify PHP constraint against our runtime matrix; verify PHPUnit version compatibility if we intend to use it in test helpers.
• Confirm no namespace collisions (Pharaonic\...) with existing packages from the same vendor; several pharaonic/laravel-* packages exist and may pull shared dependencies.
• Framework-agnostic by design, so Laravel major upgrades (11 → 12 → 13) should not affect it — a genuine advantage over illuminate/support-coupled alternatives.

Sequencing

1. Source review + Packagist/tag verification (1–2 days).
2. Edge-case test harness and behavior sign-off (1–2 days).
3. Internal adapter + pinned dependency merged behind a feature flag or scoped to a single module (2–3 days).
4. Documentation and team comms (0.5 day).
5. Reassess for broader rollout after one sprint of production exposure.

Total realistic effort: under one engineering week. That is the ceiling on this decision — it should not consume architecture-review bandwidth beyond a lightweight ADR.

Operational Impact

Maintenance

• Ongoing cost is near zero if wrapped: no runtime configuration, no scheduled tasks, no state. The real maintenance burden is dependency governance — tracking a package that receives no updates and deciding when to fork.
• Recommend a quarterly review trigger: if no release or commit in 12 months, or if the repo becomes unavailable, execute the pre-agreed fork/vendor fallback. Because the code is small and MIT-licensed, the fallback is cheap; document it in the ADR so it is a decision, not a scramble.

Support

• No vendor support, no SLA, no security disclosure process visible. Internal ownership must be assigned explicitly — name a team (platform/backend foundations) as the owner of the adapter and the fork contingency.
• Developer support is self-serve: the README and source are the documentation. Budget a half-day of a senior engineer's time to produce an internal one-pager covering wildcard semantics and dotted-key escaping, since those are the parts most likely to be misused.

Scaling

• Runtime scaling is a non-issue: pure array traversal, O(depth × segments) per operation. Watch only for wildcard operations that recursively expand large result sets on hot paths — a delete('*.*.id') over a 100k-element payload is a CPU and memory spike, not a correctness bug but an operational one. Ban wildcard writes in request-critical paths via code review.
• Organizational scaling is the real constraint: a 10-star package used by three teams is fine; used by thirty it becomes de facto internal infrastructure that nobody owns. Cap adoption until the adapter and ownership are in place.

Failure modes

• Silent null / no-throw behavior: missing paths returning null or silently no-op'ing can mask configuration errors. Mitigate by requiring explicit defaults at call sites and asserting on has() where absence is a bug.
• Dotted-key collision: data containing literal dots gets misparsed into nested paths, causing subtle data loss on writes. Highest-severity failure mode; mitigate with validation at the boundary of any external payload.
• Wildcard over-reach: a wildcard delete removing more than intended. Mitigate with a dry-run/assert pattern in code review and tests.
• Package disappearance: repo goes private or is deleted; Composer installs fail in CI. Mitigate with a committed lockfile, a Composer cache/mirror, and a vendored-fork contingency.
• Autoload/namespace conflicts: low probability, caught immediately at install time.

Ramp-up

• Learning curve is effectively nil: any PHP developer understands the API in under 15 minutes. The non-obvious parts — wildcard semantics, dotted-key escaping, null-vs-default returns — must be captured in the internal one-pager or each new engineer will rediscover them independently.
• Onboarding cost: one paragraph in the style guide plus the adapter's docblock. No training, no certification, no tooling.

Bottom line for the TPM: this is a low-cost, low-risk, low-value decision. Approve it only as a scoped, adapter-wrapped utility in framework-agnostic code where Arr is unavailable or insufficient; reject it as a general replacement for Laravel's native array helpers. The dominant risk is not technical failure — it is adopting an unowned micro-dependency for convenience and inheriting long-term governance overhead disproportionate to the functionality gained.