Query Filter Bundle Laravel Package

Technical Evaluation

Architecture fit. The release is for artprima/query-filter-bundle, which — despite being framed here as a Laravel/PHP package — is a Symfony bundle. It binds to Symfony's HTTP kernel, DI container, event dispatcher, and (historically) annotation/config loading. It has no service provider, facade, or middleware contract that Laravel would recognize. For a Laravel codebase the architectural fit is effectively nil without an adapter layer; for a Symfony codebase the fit is plausible but only if the surrounding app matches the bundle's (undocumented here) version constraints.

What this release actually changes. The note translates to: "This is the version without the dependency on sensio/extra-bundle." That is the entirety of the disclosed change surface. Concretely this means the hard requirement on SensioFrameworkExtraBundle — abandoned upstream since 2023 and superseded by native Symfony attributes — has been dropped. Two very different implementation realities are consistent with that sentence, and the release note does not distinguish them:

1. The dependency was relaxed (moved to suggest/conflict), leaving code that still calls Sensio annotation readers → runtime breakage, not a fix.
2. The dependency was removed along with the code paths that used it → a genuine modernization step, but with a behavioral contract change for anyone relying on annotation-driven filtering.

Integration feasibility. Low as delivered. The release is not distributed via Packagist; consumption requires a hand-edited repositories entry pointing at a personal VCS fork (github.com/glebkaf/query-filter-bundle) and pinning the branch alias fix-deps. There is no tagged version, no semantic versioning, and no checksum-stable artifact. Composer will resolve the branch head, meaning two installs on different days can produce different code — unacceptable for any regulated or reproducible build.

Technical risk.

• Supply chain / provenance: a private fork of a third-party bundle, unpinned, is a standing code-execution path into the application. No upstream review, no CVE feed, no provenance attestation.
• Silent breakage: "fix-deps" implies dependency surgery without a corresponding test signal. Removing a bundle that supplied param converters, @Route loading, or security annotations changes runtime behavior in ways static analysis will not catch.
• Fork drift: the fork diverges from artprima/query-filter-bundle upstream; future upstream fixes must be manually cherry-picked or the fork becomes the de facto product.
• Version ambiguity: fix-deps is not a constraint an auditor, SCA tool, or SBOM can reason about.

Key questions.

1. Is the target codebase Symfony or Laravel? If Laravel, this package is out of scope and the evaluation should be closed rather than continued.
2. Was sensio/extra-bundle removed or merely relaxed? Provide the composer.json diff and confirm no remaining Sensio\Bundle\FrameworkExtraBundle\* imports.
3. Which Symfony versions are supported after the change (5.4 LTS / 6.x / 7.x)? Does the removal of Sensio unlock 6.4+/7.x, or is the fork still pinned to an EOL minor?
4. Does a tagged, semver release exist or is fix-deps the only ref? Can we get a commit SHA pin plus a composer.lock diff?
5. Is there a CI/test suite in the fork, and does it run against the Symfony versions we intend to use?
6. License and ownership: is the fork's license compatible, and who is accountable for it (named maintainer, not a GitHub handle)?
7. Does the app use annotation-based query filtering anywhere? Enumerate call sites before touching the dependency.

Integration Approach

Stack fit. Determine the host framework first — this gates everything downstream. In a Symfony app the bundle is a natural fit and the Sensio removal is directionally correct, since SensioFrameworkExtraBundle is abandoned and blocks Symfony 6.4/7.x adoption. In a Laravel app there is no integration path short of reimplementing the filter/query-builder logic as a native Laravel package (service provider + query scope + middleware); do not attempt to load a Symfony bundle via a compatibility shim.

Migration path (Symfony host).

1. Freeze the current state: capture composer.lock, run the full test suite, record baseline query-filter behavior on a representative endpoint set.
2. Switch the dependency from the upstream Packagist entry to the VCS repository + fix-deps reference in a throwaway branch, and pin to a commit SHA rather than the branch name before it reaches any shared environment.
3. Replace any Sensio annotation usage in our code with native PHP attributes (#[Route], #[IsGranted], param converters) — this is our work, not the package's, and it is the most likely source of "it's the bundle's fault" incidents.
4. Diff the fork against upstream and against the previous locked version; read the actual code change, do not rely on the release note.
5. Run the recorded baseline endpoints and compare filter output byte-for-byte.

Compatibility. Confirm the Symfony minor/major constraint, PHP constraint, and that no other dependency still requires SensioFrameworkExtraBundle (a common trap: removing one requirement while a sibling bundle still pulls it in, leaving Composer conflict errors or a mixed annotation/attribute regime). If the removal was a conflict relaxation rather than a code deletion, treat the release as unverified and block it.

Sequencing. (1) Framework clarification → (2) source review of the fork → (3) SHA pin + lockfile → (4) local/staging validation with baseline diff → (5) internal fork or vendor mirror → (6) production. Do not parallelize steps 1–2 with 3–6; if the target is Laravel, stop at step 1.

Operational Impact

Maintenance. Ownership is the dominant cost. A personal fork with a single non-semver branch means our team is the maintainer of record in practice. Budget for: tracking upstream commits, re-applying the dependency fix on rebase, periodic Symfony upgrade compatibility work, and an internal decision on when to upstream the patch (the correct long-term outcome — removing an abandoned dependency is a generally useful fix that belongs upstream, not in a private fork).

Support. No vendor, no SLA, no release cadence, no deprecation policy. Incident response depends on an individual contributor's availability. If the fork goes stale or the repository is deleted, builds break — mitigate by mirroring the pinned SHA into an internal Git host or a private Composer repository (Satis/Private Packagist).

Scaling. Query-filter bundles are read-path components; they scale with the API surface, not with traffic directly, but filter construction that produces unbounded or unindexed query predicates can degrade database performance as data volume grows. Verify that filters compile to indexed predicates and that user-supplied filter parameters are validated against an allowlist — a filter bundle is an injection-adjacent surface and the release note says nothing about input handling.

Failure modes.

• Build failure: VCS repo unreachable, branch renamed/force-pushed, or GitHub rate limiting in CI → non-reproducible installs. Mitigation: SHA pin + internal mirror.
• Silent behavior change: Sensio-annotation-driven filtering stops being applied after the dependency drop, returning unfiltered result sets — a data-exposure risk in multi-tenant contexts, and one that typically surfaces as a bug report rather than a test failure. Mitigation: explicit baseline diff on tenant-scoped endpoints.
• Mixed annotation regimes: part of the codebase on attributes, part on annotations, producing inconsistent filtering. Mitigation: complete the attribute conversion in one pass.
• Dependency conflict at install time: another package still requires Sensio → Composer resolution failure. Mitigation: composer why sensio/framework-extra-bundle before adopting.
• Fork abandonment: no security patches flow. Mitigation: assign an internal owner and a review date.

Ramp-up. Low for a Symfony team already familiar with bundles; not applicable to a Laravel team, where the realistic ramp is "rewrite the filtering logic natively." Regardless of framework, expect roughly half a day to a day to read the fork's diff and the Sensio removal properly, plus test-writing time — the release note is one sentence and is not an adequate basis for a production dependency change.

Recommendation. Conditional hold. The intent of the release (dropping an abandoned dependency) is correct and modestly valuable, but the delivery mechanism — an untagged branch of a personal fork — is not production-grade. Proceed only with a pinned SHA, an internal mirror, a completed Sensio-attribute migration on our side, and a named internal owner; otherwise vendor the filter logic directly. If the target application is Laravel, close the evaluation: this package is out of scope.