Array Map Keys Laravel Package

Technical Evaluation

Architecture fit. aviator/array-map-keys is a micro-utility: a single-purpose helper that lets a callback receive both the key and the value when mapping over an array, closing a gap in native array_map(). That is a ~10-line capability, not an architectural layer. It provides no service container bindings, no config surface, and no persistence — so it neither helps nor hinders application architecture. The critical finding is that Laravel closed this gap natively: Collection::map() has passed ($value, $key) to its callback since 5.x, and Arr::map() (Laravel 9+) does the same for plain arrays. On any currently supported Laravel version, this package is functionally redundant with framework core.

Integration feasibility. Nominal but inadvisable. Composer install is trivial if constraints resolve; the risk is that they won't. A last release of 2017-11-25 places the package squarely in the Laravel 5.x / PHP 7.0 era. If its composer.json pins illuminate/support to ^5.x or php to >=5.6,<7.2, it will fail resolution against Laravel 9/10/11/12 (PHP 8.1+). The only honest integration path is to fork and widen constraints, at which point you own the code outright and the dependency has delivered no value.

Technical risk. Low blast radius, high friction. The package is a pure function with no I/O, no network, no deserialization — there is no meaningful security surface. The real risks are:

• Abandonment. 3 stars, 0 dependents, one maintainer, no release in ~8 years. There is no community to catch a bug and no realistic upstream fix.
• Global namespace collision. If the helper is defined as a global function, any collision with an existing or future function of the same name produces a fatal Cannot redeclare error at autoload time — a boot-time failure, not a graceful degradation.
• Argument-order ambiguity. Helper packages of this genre disagree on whether the callback receives ($key, $value) or ($value, $key). That is a silent correctness bug waiting for the next engineer.
• PHP 8 incompatibility. Anything using each(), uncurried string callables, or loose implicit nullable signatures will throw deprecations or fatals on modern runtimes.

Key questions. (1) Does the package register a ServiceProvider, and does it define a global or namespaced function? (2) What are the exact php and illuminate/support constraints, and does it install cleanly under our target Laravel version? (3) What is the callback signature order, and is it documented and tested? (4) Is there any usage in our codebase today, or is this a greenfield evaluation? (5) Does it ship tests we could inherit if we fork?

Integration Approach

Stack fit. Poor as a dependency, trivial as a pattern. Our target stack (PHP 8.1+, Laravel 10/11) already expresses this behavior idiomatically:

• Arrays: Arr::map($array, fn ($value, $key) => ...)
• Collections: $collection->map(fn ($value, $key) => ...)
• Legacy/plain PHP: foreach ($array as $key => $value)

Adopting the package would mean adding a third idiom for a problem the framework already solves twice. That is a net negative for readability and onboarding.

Migration path. If we are evaluating this for new code: don't adopt. If it is already in the tree, the exit is cheap and should be scheduled:

1. Inventory call sites (grep for the helper name and the vendor namespace).
2. Replace with Arr::map / Collection::map / foreach depending on context — behavior is identical for the value-first convention.
3. If a call site relies on key-first ordering, rewrite the closure explicitly rather than relying on the helper's convention.
4. composer remove aviator/array-map-keys and confirm no orphaned autoload entries.

Compatibility. Do not attempt to force installation with --ignore-platform-reqs; that converts a clean resolution failure into an untested runtime dependency. If some constraint genuinely requires this exact helper (e.g., a shared internal package depends on it), the correct move is to vendor a namespaced copy under app/Support/ guarded by function_exists(), pin it to our PHP version, and drop the external dependency.

Sequencing. Three days of work, ordered: (1) confirm the callback signature and current usage; (2) introduce the framework-native replacement in a single PR; (3) remove the package; (4) add a short ADR note stating "use Arr::map" so the question doesn't recur. There is no reason to phase this — the surface area is too small to warrant a staged rollout.

Operational Impact

Maintenance. Effectively total. With no release since 2017 and a single maintainer, every future PHP or Laravel upgrade becomes our problem to diagnose, not theirs. The code is small enough that "owning" it is not expensive in absolute terms — but the cost is non-zero and the benefit is zero, which is the definition of a bad trade.

Support. None available. No issue triage, no security advisories, no release cadence. Three stars and zero dependents mean no ecosystem has stress-tested this code. Anything we build on it, we debug alone.

Scaling. Functionally irrelevant at any scale — it is a userland loop over an array. There is a marginal per-element callable overhead versus a bare foreach, but it will never be the bottleneck. The scaling concern is organizational, not computational: each additional utility dependency adds a line to the upgrade checklist and a question in code review.

Failure modes. Ranked by likelihood: (1) Composer resolution failure when we bump Laravel or PHP — loud, caught in CI, cheap to fix; (2) silent argument-order mismatch producing inverted output — quiet, caught only by tests, expensive; (3) global function redeclaration fatal at boot — loud, outage-class if it ever reaches production; (4) unmaintained drift causing a deprecation to become a fatal on a future PHP minor. Failure modes 2 and 3 are the ones that justify a decision now rather than later.

Ramp-up. Near-zero technically — any PHP developer reads this in under a minute. The hidden ramp-up cost is editorial: a new hire encountering array_map_keys() must determine whether it exists for a reason, whether its argument order differs from Arr::map, and whether it is safe to remove. That is recurring cognitive tax on every future reader, paid in exchange for saving one line of foreach.

Recommendation. Do not adopt. On Laravel 9+ the capability is native; below that, Collection::map covers it. The package scores 0.045 with 3 stars, 0 dependents, and an eight-year-old release — the ecosystem has already voted. If it is already present, schedule removal as low-priority cleanup and standardize on Arr::map with a one-line ADR to prevent reintroduction.