Query Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for list/filter plumbing. Every CRUD-heavy surface (admin tables, internal dashboards, B2B API collection endpoints) needs the same thing: turn ?filter[status]=active&sort=-created_at&page=2 into a safe Eloquent query. This package is a candidate to replace the hand-rolled if ($request->has(...)) blocks that accumulate per controller — a decision worth making once and applying consistently rather than re-litigating per feature.
• API contract standardization. Choosing a query-parameter convention (filter/sort/include/paginate syntax) is a product decision, not just a technical one: it becomes part of your public API contract and your frontend's expectations. Adopting a package here is really a decision to freeze a convention.
• Roadmap acceleration for internal/back-office work. The value case is speed on low-differentiation surfaces — admin panels, support tooling, reporting tables. It does not support differentiated product surface (search relevance, ranking, recommendations, complex aggregation) where you want bespoke logic.
• Reducing endpoint-by-endpoint variance. A declarative "query bundle" abstraction makes filtering behavior reviewable in one place, which lowers the cost of consistent authorization/scoping decisions (e.g., "every list endpoint must be tenant-scoped") — a recurring PM concern in multi-tenant B2B products.
• Feature scoping input. Knowing this exists lets you answer "can we ship a filterable activity log in a sprint?" with a credible yes, and lets you defer building a shared query layer onto the roadmap with a named alternative.

When to Consider This Package

Consider it when all of the following hold:

• You are on a Laravel version contemporary with its last release (October 2022) — expect Laravel 9-era compatibility; verify against your actual framework and PHP versions before anything else.
• You have many similar list endpoints (roughly 5+) and the per-endpoint boilerplate is a measured drag, not a hypothetical one.
• You want a thin, readable abstraction you can audit in an afternoon — the codebase is small enough to read fully, which is the real reason a package this obscure is even viable.
• You are comfortable with a fork-and-own posture: MIT license, 13 stars, zero dependents, and no release in over two years means you are adopting code, not a community. Budget for vendoring it or copying the idea into app/.
• Your team is willing to write the authorization and allow-listing yourself — the security-relevant decisions (which columns are filterable, which relations are includable, tenant scoping) must not be delegated to an unmaintained dependency.

Look elsewhere when:

• You need a maintained dependency with a security-response path. Prefer Spatie's laravel-query-builder for the same problem: same conceptual model (allowed filters, sorts, includes, pagination), actively maintained, large install base, documented security posture. It is the default answer for most teams.
• You need PHP 8.2+/Laravel 10/11+ support and cannot fork.
• Your needs are search or relevance rather than structured filtering — this is not that tool.
• Your surface is one or two endpoints: the abstraction costs more than the boilerplate it removes.

Decision rule: treat this as a reference implementation to read, not a dependency to install, unless a timeboxed spike shows it covers your Laravel version and your filter grammar out of the box.

How to Pitch It (Stakeholders)

For executives (one paragraph): We have a recurring, undifferentiated engineering cost — every list screen and API collection endpoint re-implements filtering, sorting, and pagination. A small open-source Laravel package, studiomado/query-bundle, offers a standard way to declare those behaviors once. The strategic value is modest and the risk is low but nonzero: it is MIT-licensed and tiny enough to audit and own outright, but it has negligible community traction (13 stars, no downstream dependents, last release in 2022), so we should not treat it as a supported vendor dependency. Recommendation: do not adopt as a dependency; use it as a design reference and, if we want the pattern, either adopt Spatie's maintained equivalent or absorb ~100 lines into our own codebase. Cost of the evaluation is a one-day spike; the payoff is a consistent API convention across every list endpoint we ship.

For engineering (summary): Narrow, single-purpose abstraction over Eloquent query construction from request parameters — filters, sorts, includes, pagination — expressed as reusable bundle classes. Strengths: small, readable, MIT, no lock-in; the convention it enforces is more valuable than the code. Weaknesses: unmaintained since Oct 2022, no dependents, likely Laravel 9-era, no security process, no community to escalate to. Adopt only behind an allow-list you control (explicit filterable/sortable/includeable columns, mandatory tenant scoping, no raw column names from the client), and either fork it into packages/ or vendor the pattern. Benchmark it against spatie/laravel-query-builder on the same endpoint before committing; if the API surface is close, take the maintained one. Switching cost is low either way — the abstraction is thin, so a later swap is a contained refactor rather than an architectural change.