Pager Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on filterable admin lists. The package bundles the three things every back-office CRUD screen needs — pagination, a filter/sort abstraction, and list scaffolding. Any roadmap item of the form "give ops/support a searchable, sortable table" is really a build-vs-buy question, and this is a useful scoping reference for what "advanced filtering" actually costs. Note the answer for a Laravel roadmap is buy — Filament, Nova, or Spatie Query Builder — not adopt this.

• Defining what "advanced filtering" means in acceptance criteria. Compound conditions (AND/OR), per-field operators (contains, between, in), and multi-column sorting are chronically underestimated in estimation and chronically underspecified in tickets. This package is a checklist: if the story says "add filters," this is the granularity the acceptance criteria should reach.

• Filter model architecture — the genuinely transferable idea. Its core design is one filter/sort definition that resolves uniformly against either an array or an entity/query builder. That duality means the same filter spec drives in-memory test fixtures and live database queries, so list-layer logic becomes unit-testable without a database. That is a real testability and velocity argument, and it should be captured in our internal pattern regardless of vendor choice.

• Dependency policy and "own your dependencies" calibration. 10 stars, 0 dependents, single maintainer, mid-range score. This is a clean worked example for the dependency-vetting criteria we apply elsewhere: adoption here is not a library decision, it is a fork-ownership and staffing decision.

• Platform-fit / framework-mismatch triage. Despite being filed under PHP/Laravel tooling, this is a Symfony bundle — Symfony bundle registration, DI container, Twig rendering, Symfony Request. Laravel has no shim for any of that. So it supports a no on the dependency and a yes on borrowing the pattern, with the maintained Laravel equivalents doing the actual work.

• Where filtering belongs in the stack. If the requirement is a rich data grid in a JS frontend, server-side PHP filtering is the wrong layer — it belongs in the API contract. Useful for killing a "build a PHP filter engine" workstream before it starts.

When to Consider This Package

Consider it only when all of these hold:

• The codebase is Symfony, and specifically an older-generation one whose conventions this bundle matches — not modern attribute-driven configuration.
• You are extending a legacy admin, not replacing it, and need composable per-field filters without rewriting the list layer.
• You specifically need the Array/QueryBuilder parity for testing, and no maintained alternative gives it as cleanly.
• A named engineer will own the fork: patch PHP/Symfony compatibility, watch advisories, keep it building.
• Blast radius is internal, low-stakes tooling where a stalled dependency is an annoyance, not an outage.

Look elsewhere when:

• You are on Laravel. Hard mismatch — wrong framework, wrong conventions, and a bridge would drag Symfony HttpFoundation, DependencyInjection, and Twig into the app for one UI concern. Use Filament, Nova, or spatie/laravel-query-builder plus native pagination.
• You are on modern Symfony. EasyAdmin, SonataAdmin, and API Platform's filter system are maintained, documented, and have active security response.
• You need a dependency that survives a security review. Zero dependents and no advisory history means nobody else is finding the bugs — and this component builds query criteria directly from user input.
• The grid lives in a JS frontend. Do the filtering in the API contract instead.
• You only need pagination. That is a solved, trivial problem; do not take a CRUD bundle for it.

How to Pitch It (Stakeholders)

To executives: This is a small, single-maintainer open-source library for building filterable admin tables, and it targets Symfony rather than our Laravel stack. We are not recommending it as a dependency — the cost of adopting it (owning a fork, patching it ourselves, no community, no security response) exceeds the cost of using a maintained tool we already have access to. We are recommending we borrow its filtering model, which cleanly separates filter definitions from the data source so the same filters work in tests and in production. That gets us better-tested admin screens at roughly the same effort, with no new vendor risk and no added maintenance burden.

To engineering: Treat it as a design reference, not a dependency. The transferable pattern is a filter/sort abstraction that resolves against either an array or a query builder — that is what makes list-layer logic unit-testable without a database. Concrete recommendation: implement our filter definitions in the idiom of whatever maintained tool we've already chosen (Filament or Spatie Query Builder for Laravel), using this package's Array/QueryBuilder duality as the model. If someone wants to evaluate the bundle directly, scope it to a one-to-two-day spike — confirm supported PHP/Symfony versions, check whether filter names are allowlisted or reach the query builder raw, and verify a test suite exists — then discard it and close the question. Do not let this block a roadmap item; it is a nice-to-have abstraction with no deadline.