Array Map Keys Laravel Package

Product Decisions This Supports

• Build vs. buy, decided at the smallest possible scale. This package solves one narrow problem: applying a callback over an array while receiving each element's key alongside its value. That is a five-line helper, not a product capability. The correct PM framing is "do we need a dependency for this at all?" — and the answer is almost always no.
• Dependency governance and supply-chain posture. With 3 stars, 0 dependents, and a last release in November 2017, this is an unvalidated, unmaintained artifact. Adding it to composer.json is a permanent line item in every future security audit, PHP-version upgrade, and framework migration. A PM should treat that as a cost with no corresponding upside.
• Feature work it would nominally enable (all handled natively today): transforming keyed configuration maps per tenant, normalizing API payloads keyed by slug or event name, building lookup tables from associative arrays, reshaping permission or pricing-tier matrices where the key carries meaning. These are real use cases; the package is just not the right vehicle for any of them.
• Framework-alignment decisions. In Laravel 9+, Arr::map($array, fn ($value, $key) => ...) and collect($array)->map(fn ($value, $key) => ...) cover this exactly. Adopting a third-party micro-utility here signals a gap in team knowledge of the framework, not a gap in the framework — which is a documentation and onboarding decision, not a procurement one.
• Roadmap impact: none. Nothing here is strategic, defensible, or a differentiator. It should never appear on a roadmap; at most it appears as a rejected line in an architecture decision record.

When to Consider This Package

Consider it only under a narrow, largely historical set of conditions:

• You maintain a legacy codebase on PHP 7.x and Laravel below 9, where Arr::map does not exist and pulling in illuminate/collections is undesirable.
• The team has an explicit policy against local helper functions or a shared internal utilities package, so a tiny Composer dependency is the sanctioned escape hatch.
• The usage is a single, isolated, non-critical call site — not a pattern threaded through domain logic.
• You accept the MIT license and the maintenance burden of vendoring or pinning the dependency yourself.

Look elsewhere — meaning: use native framework features or write the helper — in every other case. Specifically:

• Laravel 9+ or any project already depending on illuminate/collections: use Arr::map or Collection::map. Zero new dependencies, first-party support, documented behavior.
• Plain PHP: foreach with key/value, array_walk, or array_reduce are clearer to most readers than an unfamiliar package name in the use block.
• Anything security-, billing-, or compliance-adjacent: an unmaintained 2017 package with no release cadence, no security policy, and a single maintainer is a supply-chain risk you cannot justify for a utility function.
• Teams that require active maintenance as an adoption gate: this fails that gate outright. The package has had no release in roughly eight years, PHP 8 compatibility is unverified, and there is no community to catch regressions.

The low opportunity score is itself the signal: there is no unmet market need here, because the ecosystem already closed this gap.

How to Pitch It (Stakeholders)

To executives: We evaluated a small open-source utility for mapping over arrays with key access. Recommendation: do not adopt. It provides a trivial convenience already available in our framework, but would add an unmaintained, single-maintainer dependency to our supply chain that we would carry through every future upgrade and security review. The cost is small but permanent; the benefit is zero. No roadmap impact.

To engineering: Use Arr::map or collect()->map() — both pass $value, $key to the callback — or add a small namespaced helper to our internal utilities package if we need this outside a Laravel context. Avoid adding a 2017-era package with three stars for behavior we can express in one line. If a legacy service on Laravel 8 or earlier genuinely cannot use Arr::map, prefer a local helper over a new dependency; if a dependency is mandated by policy, pin it and record why in an ADR.

To security and platform teams: Flagged and rejected. Last release 2017, no dependents, no security disclosure process, MIT-licensed and therefore forkable if we ever truly needed it — which we do not.