Eloquent Array Query Builder Laravel Package

Technical Evaluation

Architecture fit. The package is a thin, non-invasive wrapper around Laravel's query builder: it accepts an associative array (selects, wheres, orderings, limits) and translates it into standard Eloquent/DB calls. It introduces no new persistence layer, no schema changes, and no runtime services — so it slots into any existing Eloquent model with a trait/macro opt-in. Architectural blast radius is small, which is the package's main appeal.

Integration feasibility. Installation is a single composer require williamoliveira/eloquent-array-query-builder, with Laravel package auto-discovery likely handling the service provider. The real feasibility question is version compatibility: the last tagged release is 2020-08-18, which predates Laravel 9, 10, and 11. Expect the composer.json constraint to cap at Laravel 6–8 / PHP 7.x, meaning a fork, a constraint override, or --ignore-platform-reqs (not recommended) is almost certainly required before this can run on a modern stack.

Technical risk. This is the dominant concern. An 18-star package with no release in ~4.5 years is effectively orphaned, and the score of 0.62 reflects that. Specific risks: (1) unpatched compatibility with current Laravel/PHP; (2) no security responsiveness if a vulnerability is disclosed; (3) the array syntax itself obscures generated SQL, which can complicate debugging, query-log review, and index tuning; (4) if the array is ever populated from request input, it becomes a mass-assignment-adjacent surface and must be validated/allow-listed before it ever reaches the builder; (5) overlap with native where([...]) array syntax may cause confusion or unintended behavior.

Key questions. Does it install cleanly on our target Laravel/PHP version, or does it need a maintained fork? What is the license (permitting fork/vendor)? Are query parameters bound safely, and are array keys allow-listed? What test coverage exists, and can we run the upstream suite ourselves? Is there an internal owner willing to adopt and patch it? Is the ergonomic gain meaningful versus native Eloquent or a ~50-line internal helper?

Integration Approach

Stack fit. Best suited to an existing Laravel monolith where teams frequently build dynamic, filter-driven queries (admin tables, reporting screens, search APIs) and want to reduce repetitive ->when(...) chains. It offers little value in codebases that already use query objects, scopes, or a query-builder DSL.

Migration path. Do not touch production first. (1) Audit the source and composer.json constraints. (2) Install on a feature branch, pin a specific commit or fork, and run the full application test suite. (3) Add a thin internal wrapper (e.g., a QueryFilters class or a dedicated scope) that delegates to the package, so adoption remains reversible and the vendor API is isolated behind one seam. (4) Pilot in one or two low-risk controllers, diff the generated SQL against the existing implementation with DB::listen/toSql, then expand incrementally.

Compatibility. Verify PHP 8.1+ and Laravel 10/11 support explicitly; if absent, fork under our org, bump constraints, add CI, and treat the fork as the supported artifact. Confirm behavior on the major DB drivers we use (MySQL/PostgreSQL/SQLite), since array-to-builder translation can diverge on null handling and boolean casting.

Sequencing. Audit → fork/pin → wrapper → pilot → SQL parity review → expand or abandon. Build the native-Eloquent fallback in parallel so the decision at the pilot gate is a real choice, not a sunk-cost one.

Operational Impact

Maintenance. Assume an unmaintained dependency. Ownership, patching, and CI must be internal; budget a few days per year for compatibility bumps (and more on major Laravel upgrades). Without an internal owner, this becomes a latent upgrade blocker.

Support. No vendor support and a very low bus factor. Troubleshooting relies on reading the (small) source, which is feasible given the package's size, but there is no community to lean on.

Scaling. Runtime overhead is negligible — it is a translation layer over the same builder. The real scaling cost is cognitive and diagnostic: opaque array-driven queries are harder to profile, harder to refactor for eager loading (with), and harder for new engineers to trace in stack traces and slow-query logs.

Failure modes. Silent misbehavior on unrecognized array keys; malformed or user-supplied arrays producing unintended clauses; breakage on Laravel major upgrades; conflict with native where([...]) semantics; debugging friction when generated SQL diverges from intent.

Ramp-up. Low for basic usage (the API is intuitive), but conventions must be documented — especially the allow-listing of keys, the boundary between package usage and native Eloquent, and how to inspect generated SQL. Expect a short onboarding doc and a code-review checklist rather than formal training.