Array Actions Laravel Package

Technical Evaluation

Architecture fit. kamyshev/array_actions is a pure-PHP utility library — a thin set of action-object wrappers around array manipulation (map, filter, reduce-style operations). There is no evidence of Laravel coupling: no service provider, facade, config publish, migrations, or container bindings are implied by a package of this size and vintage. It would sit in the support/utility layer at best, and it overlaps almost entirely with capabilities already in the framework: Illuminate\Support\Arr, Illuminate\Support\Collection, and native array_* functions. For a Laravel codebase, this is a redundant dependency rather than an architectural fit.

Integration feasibility. Technically trivial — a single composer require, MIT licensed, no extensions, no external services, no runtime state. Effort is measured in minutes. The blocker is governance, not engineering: the repository is archived, last released 2018-10-25, 3 stars, 0 dependents. There is no realistic path to an upstream fix if something breaks.

Technical risk. High, for a package this small. Ranked:

1. PHP compatibility (most likely blocker). A 2018 composer.json will almost certainly pin ^7.0 or ^7.1. Against PHP 8.2/8.3 on Laravel 10/11, Composer resolution will likely fail outright. That is a hard stop, not a soft risk.
2. Abandonment. Archived means no PHP 8.x bump, no security response, no bug fixes. The package becomes a permanent fork obligation or a permanent pin.
3. Unknown API surface. With essentially no documentation footprint and no downstream users, behavior is only as specified as the author's own tests — which we cannot see the coverage of. Edge cases around key preservation, nested arrays, reference semantics, and empty inputs are unvalidated by anyone but the author.
4. False economy. If the library is a few hundred lines — likely — the dependency costs more to vet, pin, and defend than to reimplement.

Key questions to answer before any decision.

• What is the exact php constraint in composer.json, and does it resolve on our target runtime?
• Is it framework-agnostic, or does it ship a Laravel service provider we would need to register?
• What does it provide that Arr, Collection, or native array_* do not? If the answer is "action-object ergonomics," that is a style preference, not a capability gap.
• What is the total line count and test coverage? Under ~500 LOC, vendoring or rewriting wins on every axis.
• Are there transitive dependencies? Any abandoned transitive is a second, compounding risk.
• Why was it archived — author moved on, or superseded by something better?

Verdict: do not adopt. The value proposition is a thin ergonomic wrapper over functionality Laravel already ships; the cost is an archived, unmaintained, PHP-7-era dependency in our inventory.

Integration Approach

Stack fit. Neutral at best. This is not an integration in the Laravel sense — there is nothing to wire into the kernel, no config to publish, no migrations, no DI. It is imported code. That means no operational surface, but also none of the framework guarantees (version support windows, upgrade guides, security advisories) that make framework-adjacent packages safe to depend on.

Compatibility. Establish the target matrix first — PHP 8.2/8.3 and the current Laravel major. Check the package's composer.json constraint against it before writing a single line of code. Three outcomes:

• Resolves cleanly: still do not adopt by default; proceed only under the sequencing below.
• Fails on PHP constraint: fork-and-fix is the only path, and forking an abandoned 3-star package to save a few hours is a bad trade. Skip.
• No PHP 8 claim but happens to run: worst case. Untested-on-8 code that "seems fine" is exactly the class of dependency that produces silent data bugs after an upgrade.

Migration path (only if a team insists on adopting). Treat it as a leaf dependency with a pre-agreed exit from day one:

1. Confine all call sites to a single namespace or a thin internal wrapper, so replacement is a one-file diff.
2. Add it to composer outdated / dependency-inventory review and flag it as archived.
3. Pre-commit to replacing each call with the equivalent Arr:: or Collection call — for the operations described, these are semantically equivalent.
4. Target removal within one or two sprints; do not let it reach a second release cycle.

Sequencing. Do not put this on a delivery path. If a team believes there is value, timebox a one-day spike on a sandbox branch: measure lines saved and readability gained against the cost of an unmaintained dependency. The expected outcome of that spike is "no material gain."

Recommended alternative. Implement the handful of helpers the team actually wants in app/Support with our own tests, our own PHP 8 typing, and our own upgrade path. Estimated cost: one to two hours. That is cheaper than the first round of dependency review this package would trigger, and it eliminates the risk entirely.

Operational Impact

Maintenance. One hundred percent ours, permanently. Archived means no upstream fix for a PHP 9 incompatibility, no CVE response, no compatibility shim. Every framework upgrade cycle, someone must re-litigate whether this still works. That recurring tax is disproportionate to a library that saves a few lines.

Support. Effectively none. Three stars and zero dependents means no community knowledge base, no Stack Overflow answers, no peer teams to consult, and no realistic chance the author responds to an issue on an archived repo. Every question becomes internal research against source code.

Scaling. Not applicable at runtime — this is in-process array manipulation with no throughput, memory, or concurrency characteristics worth modeling. The scaling concern is cognitive and organizational: introducing a third dialect for array handling alongside Collection and Arr fragments conventions across teams and raises the cost of every code review and every new hire's onboarding.

Failure modes. Low blast radius, but the failures are the expensive kind:

• Build-time hard failure at PHP or Laravel upgrade, discovered mid-upgrade when the dependency graph is already churning.
• Silent wrong results — key collisions, reference semantics, empty-array handling, nested-array behavior — surfacing as data defects rather than exceptions. These are costly precisely because nobody suspects a five-line array helper; the investigation goes to the business logic first.
• Audit friction — an archived, single-maintainer, zero-adopter dependency in the SBOM generates a finding in any SOC 2-style or customer due-diligence review, requiring a written justification that, in this case, is hard to write honestly.
• Mitigation: a strict wrapper plus a scheduled replacement converts all three into contained, planned work rather than incidents.

Ramp-up. The API itself is learnable in minutes — the misleading part. The real ramp-up is the organizational overhead: dependency review, archival justification, upgrade-cycle verification, and eventual replacement. For a library this small, that overhead exceeds the functionality it delivers by a wide margin.