Array Actions Laravel Package

Getting Started

Require the package and confirm what actually shipped, since the README is the only reliable spec for a package this small:

composer require kamyshev/array_actions

Before writing any code, do three things in this order:

1. Read vendor/kamyshev/array_actions/src/ top to bottom. At 3 stars and a single 2018 release, there is no documentation ecosystem, no blog posts, and no Stack Overflow coverage. The source is the documentation. Confirm whether the package exposes namespaced functions (e.g. Kamyshev\ArrayActions\...) or classes — this determines whether you can autoload it cleanly under Laravel's Composer setup or need a files autoload entry.
2. Check the composer.json constraints (php, illuminate/* if any). A 2018 release almost certainly declares php: >=7.0 or similar with no upper bound. That will install on PHP 8.x but is not a signal that it works there.
3. Run the package's own test suite (vendor/bin/phpunit inside the package path, or copy its tests into your suite). It's the fastest way to see the intended API and catch PHP 8 deprecations before they surface in production.

First use case: treat it as a sandbox for one narrow, low-risk transformation — for example normalising a nested config array or flattening request payloads in a FormRequest — not as a replacement for collect(). Wire it into a single service class and observe it in a feature test before spreading it.

Be explicit with your team that this is an archived, zero-dependent package (last release 2018-10-25, MIT). Adopting it is a conscious decision to own the code, because upstream no longer will.

Implementation Patterns

Wrap it — never call it directly from controllers. Even a trivial array helper deserves a seam. Put the raw package calls behind one class so you can swap the implementation for Illuminate\Support\Arr or Collection later without a repo-wide refactor:

namespace App\Support;

final class ArrayActions
{
    public static function apply(string $action, array $input): array
    {
        // single entry point; all direct package usage lives here
        return match ($action) {
            'unique' => /* package call */,
            'flatten' => /* package call */,
            default  => throw new \InvalidArgumentException("Unknown action: {$action}"),
        };
    }
}

Prefer it in pure, framework-free layers. The one place a functional array library genuinely adds value over Collection is code that should not depend on Laravel — value objects, DTO hydration, domain services, or a package you might extract. If the surrounding code already imports Illuminate\Support\Collection, you gain nothing by introducing a second, less-documented array vocabulary. Draw the line at the domain boundary.

Compose small actions into pipeline steps. If the package exposes single-purpose functions, treat them as the primitives and build named domain operations on top:

// A domain operation, expressed as a readable pipeline of package primitives
$normalised = $this->pipeline(
    $payload,
    fn ($a) => /* package: trim/normalise */,
    fn ($a) => /* package: reject nulls */,
    fn ($a) => /* package: reindex */,
);

This is the pattern that survives refactoring: the pipeline shape and the domain names stay, the underlying calls are replaceable.

Use it in tests as an oracle. Because the actions are pure and small, you can cross-check your own hand-rolled helpers against the package's output in a data-provider test. If they agree, you have confidence to drop the package and keep your code.

Integration in Laravel specifically:

• No service provider, no facade, no auto-discovery — it is plain PHP, so there is nothing to register.
• If it exposes global functions, confirm they are namespaced; otherwise collisions with your own helpers are guaranteed.
• Use it in FormRequest::prepareForValidation(), API Resource transformation, or seeder/import normalisation — the three places ad-hoc array_* soup tends to accumulate.

Gotchas and Tips

• Archived + 3 stars + 0 dependents = you are the sole maintainer now. Fork it into your App\Support namespace or vendor it; do not rely on composer require resolving a fix. Pin the exact version ("kamyshev/array_actions": "1.0.0" style, not ^1.0) so a future upstream unpublish or Packagist hiccup cannot silently change your build.
• PHP 8 deprecations are the highest-probability failure. 2018-era code commonly hits: implicit nullable parameters (Type $x = null), implode() argument order, dynamic properties, and each()/create_function() removals. Run php -d error_reporting=E_ALL over your first integration test and read every deprecation, not just the fatal.
• Silent behavioural drift vs Collection. Key-preservation on map/filter/reverse is the classic mismatch. Before trusting the package, write a one-off test asserting key behaviour on each action you adopt — Laravel developers carry strong intuitions from Collection that a third-party library does not share.
• Empty-array and null edge cases. Small 2018 utilities frequently assume non-empty input. Wrap calls in a guard or assert in your service class; this is exactly the kind of bug that reaches production because the helper "obviously works".
• Debugging: the package has no logging, no exception types of its own, and no facades. When an action misbehaves, dump the input/output pair at the boundary of your wrapper — you cannot step into meaningful framework tooling here. ray()/dd() inside the wrapper is your entire debugging surface.
• Extension points are effectively nil. There's no config, no container binding, no events. Any customisation means editing the package or subclassing it, both of which reinforce the "fork it" recommendation.
• Migrating off is intentionally cheap if you build the wrapper. Illuminate\Support\Arr, Collection, or native array_* cover nearly every primitive this package exposes. The wrapper from Implementation Patterns makes the migration a single-file diff — plan for it rather than assuming perpetual use.
• Do a five-minute build-vs-buy check before committing. collect($array)->filter()->values()->all() is one line of first-party, actively maintained, exhaustively documented code. The case for adopting an archived helper must be strong (e.g. a genuinely non-Laravel layering constraint), otherwise you are adding supply-chain risk for syntax sugar.