Laravel Query Builder Laravel Package

Technical Evaluation

Reassessment basis. This update reflects release 3.4.0. There are no breaking changes, no API changes, no new features, no deprecations, and no security fixes in this release. The changelog is composed almost entirely of dependency/tooling churn (Dependabot bumps to setup-php, actions/checkout, codeql-action, ramsey/composer-install), a license year update, and three substantive composer.json/CI changes: PHPUnit 12 support, PHP 8.5 support, and Laravel 13 support — plus an orchestra/testbench constraint update. The structural concerns from the prior assessment (4 stars, 0 dependents, single maintainer, incumbent overlap) are untouched. Two named risks are, however, materially softened. The verdict does not change.

Architecture fit. Unchanged. zing/laravel-query-builder targets the standard Laravel request-to-Eloquent boundary: an HTTP request enters, a query builder translates query-string parameters (filters, sorts, includes, pagination) into a constrained Illuminate\Database\Eloquent\Builder. For any Laravel application exposing collection endpoints, that is a first-class architectural fit — it removes hand-rolled if ($request->has('filter')) branches from controllers and pushes query shaping into a declarative, testable layer. It composes naturally with API Resources, form requests, and Laravel's container; no framework-level surgery is implied. 3.4.0 does not alter this surface in any way.

Integration feasibility. Low and now slightly lower. Composer install, optionally publish config, declare allowed filters/sorts/includes per model or per controller. The integration surface is one middleware or builder invocation plus per-endpoint allowlists. A single engineer can spike it against a non-critical read endpoint in under a day. The only new feasibility wrinkle is test-side: PHPUnit 12 support means the package's own suite moved forward, so confirm your project's PHPUnit/Pest version against the supported range before assuming a frictionless composer require.

Technical risk. This remains the dominant concern, but the profile has shifted:

• Version drift — downgraded from high to moderate. This is the headline positive. A low-traffic package supporting Laravel 13 and PHP 8.5 ahead of or alongside your upgrade path is doing precisely the thing abandoned packages fail to do. The illuminate/* and orchestra/testbench constraints were explicitly touched, not left to rot. The prior assessment's "may lag on illuminate/* constraints and block your framework upgrade" risk is now evidenced as not materializing on the current cycle.
• CI matrix — question partially answered. The presence of Dependabot automation across setup-php, actions/checkout, codeql-action, and ramsey/composer-install, plus a CodeQL workflow bump, indicates real CI infrastructure that is being kept current. CodeQL in particular suggests a security-scanning posture. This is inference from release notes, not a verified green matrix — confirm by reading the workflow files and the last few CI runs.
• Release cadence — question partially answered, with a caveat. Releases are flowing and the maintainer is responsive to ecosystem shifts. But the cadence is dependency-driven, not feature-driven. There is no user-facing feature in 3.4.0. Read this as maintenance mode, competently executed — which is what you want from a stable utility package, but it means do not expect the feature gaps relative to spatie/laravel-query-builder to close.
• Adoption validation — unchanged, still effectively zero. 4 stars and 0 dependents. No third-party production usage to learn from, no Stack Overflow corpus, no blog walkthroughs. The 8.48 composite score reflects structural/package-health signals, not ecosystem traction; the 3.02 opportunity score is the more honest read. A version-support release does not move this at all.
• Bus factor of one — unchanged. @zingimmick authored every substantive change in this release; the rest are bots. A responsive single maintainer is still a single maintainer. MIT does not mitigate abandonment — only your willingness to fork does.
• Security surface — unchanged and unanswered. 3.4.0 contains no security fix and no disclosure, so nothing here tells you whether filters and sorts are allowlist-enforced by default. This remains the highest-severity unknown, and dependabot/CodeQL activity is not a substitute for answering it.
• Overlap with an entrenched incumbent — unchanged. spatie/laravel-query-builder still owns this niche. The stated-reason requirement for adopting this package stands.

Key questions — status after 3.4.0:

1. What does this do that spatie/laravel-query-builder does not? Still open. 3.4.0 adds no differentiating capability.
2. Is there a CI matrix across supported PHP and Laravel versions, and does it actually run? Partially answered. PHP 8.5, PHPUnit 12, and Laravel 13 support in one minor implies a matrix exists and passes. Confirm by inspecting the workflow files directly.
3. Are filters, sorts, and includes allowlist-only by default? How are invalid parameters handled — 400, 422, or silent drop? Still open, still the top blocker.
4. What is the release cadence and breaking-change history? Partially answered. Cadence is healthy; 3.x has had no visible breaking change in this window; the 2026-03-18 date concern is moot given 3.4.0 supersedes it. Confirm 3.3.0 → 3.4.0 is semver-clean by diffing the changelog.
5. Is there a documented security policy and a path to report issues privately? Still open. CodeQL presence is a weak positive signal, not an answer.
6. Does it support relation includes with per-relation constraints, and does it guard against unbounded include depth? Still open. No relevant change.

Integration Approach

Stack fit. Unchanged, but the envelope is now wider: Laravel through 13, PHP through 8.5, PHPUnit through 12. Eloquent-backed read endpoints, JSON:API-style or query-param-style collection filtering. Still a poor fit for non-Laravel PHP, for Doctrine-based data layers, or for teams standardizing on GraphQL where query shaping belongs in the schema.

Migration path. Do not rip out an existing spatie/laravel-query-builder integration — the behavioral differences in parameter naming, allowlist semantics, and error handling will surface as silent API contract changes. 3.4.0 gives you no new reason to migrate.

• If greenfield, this is a legitimate candidate but must win a bake-off against the incumbent on a written feature matrix.
• If brownfield, restrict this package to new endpoints only, behind an internal interface.

Compatibility. Pin to 3.4.* (exact minor, as before). The version-support expansion removes the main compatibility objection — but validate three specifics rather than trusting the changelog:

• Your Laravel target is covered by the illuminate/support and illuminate/database constraints as published in 3.4.0's composer.json, not merely by the PR title.
• PHPUnit 12 requires a recent PHP floor. If your app runs PHP 8.1/8.2, confirm the package does not transitively force a PHPUnit upgrade that your test suite or CI image cannot absorb. This is dev-only, but it bites at install time.
• The orchestra/testbench constraint change is testbench-side and should not affect consumers; verify it did not narrow the Laravel range it was meant to widen.
• Re-confirm middleware ordering assumptions against your kernel, and PHP 8.5 semantics if you are on the leading edge.

Sequencing.

1. Spike (1–2 days). Install 3.4.* in a sandbox branch; wire one read-only endpoint; attempt to break it with malformed filters, unknown params, deep relation includes, and sort injection. Confirm the install is clean on your PHP/PHPUnit pairing.
2. Adapter (2–3 days). Wrap all usage behind a thin internal QueryFilter interface or base controller trait. Unchanged in priority — this is the single highest-leverage decision, converting bus-factor risk from an outage risk into a refactor cost.
3. Pilot (1 sprint). One non-critical list endpoint in production behind a feature flag; capture latency, error rates, and query counts.
4. Review gate. Compare against the incumbent on developer velocity, error behavior, and upgrade friction. Go/no-go.
5. Rollout. Only after the gate; expand endpoint by endpoint, never as a codebase-wide sweep.

Nothing in 3.4.0 justifies compressing or skipping this sequence. The release reduces upgrade friction; it does not reduce adoption risk.

Operational Impact

Maintenance. Materially improved, not resolved. The maintainer has demonstrated willingness to track Laravel and PHP majors and to keep CI tooling current — the strongest available counter-signal to the abandonment thesis. Still budget for a fork within 12 months; still fork into your org namespace on adoption day if the pilot passes, so you are never blocked waiting on an upstream release. Track upstream commits; pull selectively. Expect maintenance releases that are mostly dependency churn — plan a low-friction, automated intake path (Dependabot or Renovate on your side, contract tests to catch behavior drift) rather than reading every changelog by hand.

Support. GitHub issues only, no SLA, no commercial backing, no community. CodeQL and Dependabot indicate engineering hygiene, not a support contract. Internal escalation path is still "the engineer who forked it." Name that person before rollout.

Scaling. Unchanged. The builder itself is cheap — it constructs a query, the database executes it. The scaling risk is entirely in what it permits: unrestricted relation includes produce N+1 storms, and unrestricted sort columns produce unindexed ORDER BY full scans on large tables. Enforce per-endpoint allowlists, cap pagination size globally, forbid nested includes beyond one level, and require index review for every newly allowlisted sort column. Add query-count assertions to the test suite so an accidental include regression fails CI rather than p99.

Failure modes to design for:

Ramp-up. Unchanged. For a Laravel-fluent engineer: half a day to first working endpoint, one to two days to understand allowlist semantics and edge cases. For engineers new to Laravel: one to two weeks, and the absence of tutorials or community examples for this specific package materially lengthens that curve — they will be reading source, not docs. 3.4.0 produces no documentation or example gain.

Verdict. Architecturally sound; operationally less fragile than previously assessed, but still fragile. Release 3.4.0 is a competence signal, not a traction signal: it retires the version-drift objection by tracking Laravel 13, PHP 8.5, and PHPUnit 12, and it shows live CI with CodeQL coverage. It does not add a single reason to choose this over spatie/laravel-query-builder, does not answer the allowlist/error-handling security question, and does not create a second maintainer. Adopt only behind an internal adapter, only after winning a documented comparison against the incumbent, and only with a named owner and a fork budget. If those three conditions cannot be met, the correct decision remains to decline.