Array Actions Laravel Package

Product Decisions This Supports

• Build vs. buy: This package tilts the decision firmly toward build (or reuse framework-native helpers). The surface area is small enough that copying the pattern or writing equivalents with Illuminate\Support\Arr is cheaper than taking on a dependency.
• Dependency governance: Supports a "do not add" decision. With 3 stars, 0 dependents, no release since October 2018, and an archived repository, it fails basic maintainability and supply-chain criteria.
• Legacy remediation: If it already exists in a codebase, this assessment supports a roadmap item to replace it with first-party helpers during the next refactor window, rather than budgeting for upgrades or patches.
• Feature/roadmap impact: None. It does not unlock user-facing capabilities; it is an implementation detail for array reads/writes/checks. It should not appear on a product roadmap.
• Use cases: Reasonable only for throwaway scripts, internal prototypes, or as a reference for action-oriented design. Not appropriate for production features, shared libraries, or anything with a security/compliance surface.
• Standardization: Supports standardizing on Laravel's Arr/Collection APIs or a maintained utility package, reducing the number of bespoke array helpers across services.

When to Consider This Package

Consider it only when all of the following are true:

• You are working in a legacy PHP 7.x codebase with no Illuminate/Collection dependency available.
• You specifically need small, isolated array "action" classes (get/set/has/forget-style operations) and want an MIT-licensed reference implementation to vendor or copy.
• You are evaluating design patterns (action classes vs. static helpers) rather than seeking a supported dependency.
• You accept that there will be no fixes, no PHP 8+ compatibility guarantees, and no security response.

Look elsewhere when:

• You need anything production-grade, maintained, or audited — use illuminate/support (Arr), Laravel collections, or ramsey/collection.
• You need performance-sensitive or large-array operations — benchmark first; a handful of helper classes will not move the needle, and framework helpers are better tested.
• You require PHP 8.x compatibility, static analysis cleanliness, or modern typing.
• You are deciding whether to add a Composer dependency — the answer here is no; the cost of ownership exceeds the value.

How to Pitch It (Stakeholders)

To executives: We evaluated kamyshev/array_actions and recommend against adoption. It is an archived, single-maintainer utility package with negligible community adoption and no releases in over six years. The functionality — a few simple array helpers — is trivial to replicate internally or cover with framework-native utilities. Adding it would introduce maintenance and supply-chain risk for near-zero product value.

To engineering: Treat this as a reference, not a dependency. The package provides small action-style wrappers around array operations; equivalent behavior is available via Illuminate\Support\Arr or a short internal helper class. If it is already in the codebase, schedule removal alongside other dependency cleanup; do not build new work on it. If someone proposes it for a new service, redirect to framework helpers or a maintained collection library, and document the decision so it is not re-litigated.