Jsonapi Rql Finder Bundle Laravel Package

Technical Evaluation

Architecture fit — unchanged, still low as shipped. Release 3.0.0 does not alter the fundamental mismatch. The package remains a Symfony bundle, not a Laravel package: its value is delivered through a bundle class registered in bundles.php, DI service definitions, and integration with paknahad/jsonapi-bundle (itself a Symfony bundle). There is still no service provider, no facade, no Laravel config publish path, and no test coverage against Laravel. PHP 8 support changes the runtime floor, not the extension mechanism. Treating this as a "Laravel/PHP package" remains a category error that will surface on the first integration attempt.

What is actually reusable — unchanged. The narrow, portable layer is still the RQL grammar handling: parsing the filter= / sort= query string into a normalized predicate tree, then translating that tree into a query-builder expression. That translation logic remains coupled to Doctrine's query builder, so the parser may be worth carrying forward while the translation layer gets rewritten against Eloquent. The RQL syntax contract — the thing your API consumers see — is the durable asset; the Symfony glue is not. A PHP 8 bump does nothing to change this split.

What 3.0.0 actually delivers. The entire release note is the phrase "Support for PHP 8." That is a real and useful change — it removes the most likely hard blocker identified in the prior assessment (a 2021–2022-era PHP constraint that would have excluded Laravel 10/11 runtimes) — but it is the only stated change in a semver-major release. A major version number implies breaking changes, and none are documented. For a TPM this is itself a signal about release discipline: if a major bump ships with a one-line note, assume the diff is the only changelog that exists and plan to read it.

Integration feasibility — unchanged in structure. The same three paths apply, in the same descending order of pragmatism:

1. Reimplement the contract, borrow the idea — adopt RQL as your public filter grammar and implement the parser/adapter natively in Laravel. Highest effort, lowest ongoing risk, cleanest fit.
2. Vendor and port — fork the repo at 3.0.0, strip the Symfony bundle wiring, keep the parser and predicate model, rewrite the backend translation to Eloquent. Moderate effort, but you inherit maintenance permanently. Note the 3.0.0 bump means the port must be done against the new tag, and any internal docs or examples written against 2.x may no longer apply.
3. Integrate as-is — still not viable without a Symfony/Laravel bridge or a parallel Symfony microservice. PHP 8 support does not create a Laravel extension point. Reject unless you already run Symfony.

Technical risk — still high, marginally improved. The PHP 8 constraint lift is genuine progress and should be recorded as such: it is the difference between "cannot run" and "can run." Everything else stands. Seven stars, zero dependents, and a prior release of 2022-03-21 mean there is still no downstream validation and no evidence of production use at any scale. Single-maintainer. Moving from dormant to "one release in three-plus years" is a sign of life, not a maintenance cadence — do not read it as a commitment to security patching or issue triage. The dependency on paknahad/jsonapi-bundle compounds this: you inherit that bundle's staleness, its Doctrine assumptions, and its own maintenance risk, none of which 3.0.0 addresses.

Security surface worth flagging early — unchanged. Exposing a filter DSL to untrusted clients widens the attack surface in two specific ways: arbitrary field access (a client filtering on password_hash or a relation they should not traverse) and parser denial-of-service (deeply nested or pathological expressions). Any adoption needs a strict allowlist of filterable fields and depth/complexity limits, neither of which this package is positioned to enforce for you. A major version bump is also the moment to re-read the parser for any changed recursion or depth handling — assume nothing was hardened unless the diff says so.

Key questions before committing engineering time:

• Do we actually need RQL specifically, or just "a documented, expressive filter syntax"? If the latter, spatie/laravel-query-builder or Laravel JSON:API's native filter support solves this with active maintenance and modern PHP support.
• Is there an external API contract or partner integration mandating RQL? That remains the only strong argument for path 1.
• What actually changed in 3.0.0 besides the PHP constraint? A major bump with a one-line note implies undocumented breaking changes. Diff 2.x against 3.0.0 before relying on any prior reading of the code.
• What Symfony version does 3.0.0 constrain, and does the PHP 8 support extend to PHP 8.2/8.3 or stop at 8.0/8.1? "PHP 8" is ambiguous and the runtime ceiling matters for Laravel 11.
• Does the parser or paknahad/jsonapi-bundle carry its own version constraints that still pin you to the 2021–2022 era?
• Who owns the fork if we take path 2, and what is the exit plan?

Integration Approach

Stack fit — still poor out of the box. The package assumes Symfony's bundle lifecycle and Doctrine's query builder; a Laravel application assumes service providers, Eloquent, and middleware. There is no overlap in extension mechanism. PHP 8 support means the code can now execute on your runtime, which removes a blocker but does not create an integration seam. The conceptual overlap — HTTP query string in, constrained query out — is real but must be rebuilt.

Migration path. Recommended sequence for a team that has decided RQL is the right contract:

1. Spike (1–2 days). Clone the repo at tag 3.0.0, diff against the last 2.x release to establish what the major bump actually changed, then read the parser and the Doctrine translation layer to determine the parser/glue split. If the parser is a clean standalone dependency, reuse it; if it is interleaved with Symfony services, plan to write the parser.
2. Define the contract first. Publish the subset of RQL you will support (eq, ne, lt, gt, in, like, and, or, plus sort and pagination). Not all of RQL is worth supporting, and a documented subset is easier to secure and to evolve.
3. Build a translation adapter against Eloquent. One class, one interface: FilterDefinition → Builder. Keep it isolated so the grammar can be swapped without touching controllers.
4. Gate with an allowlist. Register filterable fields and relations per resource, mirroring how Laravel JSON:API handles filter authorization. Reject unknown fields with 400, not 500.
5. Only then decide whether to keep a vendored copy of the original code or maintain a clean-room implementation. Most teams will end at step 4 having written it themselves.

Compatibility — improved, with caveats. The prior blocker is lifted: 3.0.0 supports PHP 8, so the parser can plausibly run on a Laravel 10/11 runtime. Three things still need verification before the spike concludes: (a) the exact PHP range — 8.0 only versus 8.1+/8.2+ materially changes your options; (b) the Symfony constraint, since the bundle layer being incompatible is fine if you only want the parser, but you need to know which is which; (c) whether paknahad/jsonapi-bundle and the parser's own dependencies accept the same PHP/Symfony ranges. Laravel's own requirements are no longer the constraint — the dependency graph behind this package now is.

Sequencing. Do not sequence this behind a feature delivery. The RQL contract is an API design decision with a long tail; make it early, or default to a maintained Laravel filtering package and defer RQL until a consumer demands it. Note that the 3.0.0 release does not create urgency — it does not make the package maintained, and one release does not justify pulling the decision forward.

Alternatives to evaluate in parallel: spatie/laravel-query-builder (mature, allowlist-oriented, PHP 8 supported), laravel-json-api (if you are genuinely doing JSON:API, its filter layer is the closest maintained analogue), or a thin custom parser if the RQL grammar is contractually required.

Operational Impact

Maintenance. Still the dominant cost. 3.0.0 is a positive datapoint — someone is still at the keyboard — but a single release after a three-plus-year gap does not establish a cadence, a triage process, or a security-response path. If you vendor or fork, budget for a named owner and a periodic review cadence; an unowned fork rots faster than an unowned dependency because it is invisible to tooling. Pin your fork or dependency to 3.0.0 explicitly; if you adopt anything from this repo, do not track a branch.

Support. Still none available. No issue triage commitment, no CVE response, no upstream fix path. Any production incident traces to your own team. The 3.0.0 release slightly raises the odds someone responds to an issue, but it does not constitute support, and you should not plan around it.

Scaling. Parsing overhead per request is negligible relative to database work; the real scaling risk is query shape. A permissive RQL surface lets clients compose filters and sorts that generate unindexed scans, deep relation joins, and unpredictable cardinality. Mitigations: allowlist, depth and complexity caps, per-endpoint rate limits, and query-plan review of the top filter combinations before launch. Nothing in 3.0.0 changes this analysis.

Failure modes to design for explicitly:

• Malformed or unsupported RQL returning 500 instead of 400 — noisy, and a signal to attackers.
• Field enumeration: error messages that distinguish "unknown field" from "forbidden field."
• Parser recursion limits: pathological nesting exhausting memory or CPU.
• Silent semantic drift: filter behavior changing when the vendored copy is patched.
• Undocumented 3.0.0 breaking changes: because the release note is one line, any behavior you validated against 2.x must be re-validated against 3.0.0. Treat the major bump as an unknown until diffed.
• Doctrine-flavored expressions translated incorrectly to Eloquent (null handling, case sensitivity, collation) producing subtly wrong result sets — the hardest class of bug to detect.

Ramp-up. Team cost is moderate but real: engineers must learn RQL syntax, the allowlist model, and the translation layer's edge cases. Because there is no documentation ecosystem around this package specifically — and 3.0.0 ships with a one-line note rather than a changelog — ramp-up depends on the underlying RQL spec and on whoever performs the initial port. Budget for that person to write the internal docs; they are the only docs that will exist.

Bottom line for a TPM. The recommendation is unchanged: do not adopt this package. Adopt the idea — RQL as a documented filter contract — and either implement the subset you need on Laravel's query builder or use a maintained Laravel filtering library. The package is best treated as a reference implementation and a source of design input, not as a dependency. What 3.0.0 changes is narrow but worth recording: the PHP version constraint is no longer an automatic disqualifier, so the remaining obstacles are architectural rather than environmental. What it does not change is the core picture — still a Symfony bundle with no Laravel seam, still zero dependents, still a single maintainer, still a major version shipped with a one-line note. The score of 0.255 and seven stars are consistent with the same conclusion as before: this is not a component to build production API surface area on.