Array Query Laravel Package

Technical Evaluation

Architecture fit. The package is a dependency-free, framework-agnostic utility that operates purely on native PHP arrays. It ships no Laravel service provider, facade, config file, migration, or persistence driver, so it sits as a leaf dependency rather than an architectural node — it cannot reach into HTTP, queues, Eloquent, or the container unless we let it. That isolation is genuinely favorable for fit. The problem is the inverse: the same isolation means it delivers little Laravel-idiomatic value. Illuminate\Support\Collection already covers filter, where, groupBy, sortBy, pluck, and aggregate helpers. The library's only differentiated capability is its query DSL (MongoDB/SQL-style operators) applied to nested arrays — a narrow, specific niche.

Integration feasibility. Mechanically high. Composer install, a single namespace, no publishable assets, no bootstrapping. The blocker is version posture: the last release is October 2019, which predates PHP 8.0 (Nov 2020) and Laravel 8+. On a modern Laravel 10/11 stack we should expect either a composer.json platform constraint conflict or untested PHP 8.x behavior. Working around that with --ignore-platform-reqs or a local fork is a governance smell that will need explicit sign-off.

Technical risk. High, on several independent axes: ~6 years unmaintained; 12 stars, meaning near-zero community validation and a bus factor of one; no releases addressing PHP 8.x deprecations or PHP 9 forward-compatibility; unknown or unverifiable test coverage; latent edge-case bugs in operator semantics that will never be patched upstream; and no security response process. Mitigants are real but bounded: MIT licensing permits forking and vendoring, the codebase is small enough that a full audit is a day or two rather than a quarter, and the blast radius stays small if it is isolated behind an interface.

Key questions.

• What concrete query does this express that a Collection pipeline or a where() closure cannot? Get the actual call sites before deciding.
• Does the declared PHP constraint admit ^8.1, and does its test suite pass on our PHP/Laravel matrix?
• Is the query structure ever influenced by user input? If so, pathological nested queries become a DoS/latency vector, and an unpatched parser is the wrong place to absorb that risk.
• Who owns the fork when upstream is formally abandoned?
• What array sizes are in scope? In-memory scanning with no indexing has a hard ceiling.

Integration Approach

Stack fit. Usable as a plain library behind an application-owned adapter (e.g. App\Support\ArrayQuery\ArrayQueryAdapter) bound in a service provider, with call sites depending on our interface rather than the vendor namespace. Keep it out of controllers and out of anything Eloquent-adjacent; constrain it to read-only querying of config, cached JSON payloads, and third-party API responses.

Migration path. There is no data migration — the library is stateless and operates on arrays already in memory. Three options, in preference order:

1. Skip it. Reimplement the two or three operators we actually use on top of Collection (roughly 1–2 developer-days). This eliminates the dependency entirely and is the default recommendation given the 0.18 score.
2. Adopt narrowly for read-only querying of bounded payloads, behind the adapter boundary, with contract tests.
3. Vendor the source into the repo under a maintained namespace if exact DSL behavior must be preserved — the fallback that keeps the semantics but accepts the maintenance.

Compatibility. Pin an explicit Composer constraint, add a CI job across our Laravel/PHP matrix, and write a smoke test per operator we actually use so that PHP upgrades fail loudly instead of silently changing semantics. Specifically audit for PHP 8.1+ deprecations: dynamic property creation, implicit nullable parameters, and string/array offset behavior.

Sequencing. (1) Two-day spike benchmarking the DSL against Collection equivalents for our real use cases; (2) go/no-go against the skip option; (3) if go, wrap behind an interface, add contract tests and the CI matrix job; (4) ship to one non-critical read path only; (5) schedule a forced re-decision at the next PHP major rather than letting it drift.

Operational Impact

Maintenance. We become the de facto maintainer. Budget an annual audit plus PHP-version patching. The artifact is small, but it is still an owner with a name attached. Log it in the dependency register with an explicit "abandoned-risk accepted" annotation so it does not get discovered late during a framework upgrade.

Support. No vendor, no paid tier, and effectively no community at 12 stars. Knowledge will concentrate in whoever integrated it — require a short ADR and in-repo usage examples as a condition of merge.

Scaling. Entirely in-memory and per-request CPU. Cost scales with array size × query complexity, and there is no indexing, so the worst case is repeated full traversals of nested structures. Acceptable for config-sized and sub-thousand-element payloads; not acceptable for request-time querying of large exports or multi-megabyte cached blobs. Track memory_limit headroom and p95 response time on any endpoint that touches it.

Failure modes. Silent semantic drift across PHP upgrades; uncaught TypeErrors when nested shapes or nulls differ from expectations; pathological nested queries causing timeouts, escalated to a real risk if query structure is user-influenced; memory exhaustion on unexpectedly large arrays; and Composer resolution failures that block a framework upgrade at the least convenient moment.

Ramp-up. Low — the syntax is learnable in under a day by a mid-level developer if documentation exists, but a 12-star 2019 package likely has a README and nothing more, so expect tribal knowledge. The number that matters is not ramp-up but exit cost, and the adapter boundary is what keeps that near zero. Treat the boundary as a hard requirement, not a nice-to-have.