Pagination Bundle Laravel Package

Product Decisions This Supports

Primary decision supported: a documented "do not adopt" call. The most valuable output of this evaluation is a fast, defensible rejection, which saves engineering evaluation time and prevents an accidental dependency from entering the codebase. Specific decisions it informs:

• Stack-fit gate (build vs. buy → buy from the right vendor). This is mazarini/pagination-bundle, a Symfony bundle coupled to Doctrine ORM — not a Laravel package. If our product surface is Laravel/Blade/API Resources, the answer is the framework's built-in LengthAwarePaginator / cursorPaginator. The decision is not "build vs. buy," it's "use the primitive we already own."
• Roadmap scoping. Pagination is a commodity, undifferentiated capability. It should never occupy roadmap capacity as a feature; it belongs to platform hygiene. This assessment is a prompt to keep it there.
• Default-policy precedent. Establishing a house rule ("collection pagination is satisfied by the framework or a single approved library") is a durable product decision this evaluation justifies far more than the package itself does.
• Licensing checkpoint policy. GPL-3.0 is the single highest-leverage attribute here. It generalizes into a standing rule: any third-party dependency in a distributed artifact (on-prem, SDK, mobile, white-label) requires a license review before it enters the dependency graph. For a purely hosted SaaS where we never convey the software, GPL obligations typically do not trigger — but that is a legal determination, not an engineering assumption, and it must be confirmed per deployment model.
• Migration-risk budgeting. With 1 GitHub star, 0 dependents, and an opportunity score of 0.38, adopting this means we become the de facto maintainer. That's a staffing cost, not a feature cost — a decision about headcount, not scope.
• Legitimate use cases, if the constraints ever fit: internal Symfony + Doctrine admin back-offices, reporting tables, and collection endpoints on tooling we do not distribute. That is a narrow, plausible niche — not our product.

When to Consider This Package

Consider only if every one of these is true:

1. The application is Symfony and the persistence layer is Doctrine ORM — not Eloquent, not Laravel.
2. The artifact is never conveyed to third parties (internal tooling or hosted-only SaaS), or legal has explicitly cleared GPL-3.0 for distribution.
3. You have a named owner willing to fork and maintain it, because the upstream signal (1 star, 0 dependents, single maintainer) does not support a bet on upstream responsiveness.
4. You have evaluated and rejected the incumbents — knplabs/knp-paginator-bundle or pagerfanta/pagerfanta — on concrete grounds, not convenience.

Look elsewhere — the default answer — when:

• You are on Laravel. Use the built-in paginator. Zero dependencies, zero license surface, first-class JSON/API and cursor support. This package cannot serve you at all.
• You need distribution rights. GPL-3.0 is incompatible with most commercial closed-source distribution models. This alone ends the evaluation for any shipped product.
• You need longevity. A single-maintainer package with no dependents has no bus factor and no ecosystem pressure to keep it current with Doctrine/Symfony majors.
• You need cursor or keyset pagination for large or frequently-mutating datasets — offset pagination at scale is a performance and correctness trap this package does not solve.
• You are weighing a dependency against ~15 lines of code. Offset pagination over a query builder is small, well-understood, and cheaper to own than a vendor relationship.

Comparison for the decision record:

How to Pitch It (Stakeholders)

For executives (30 seconds): We evaluated a third-party pagination library and are recommending against it. Three reasons: it doesn't run on our stack (it's built for Symfony, we're on Laravel), it carries a GPL-3.0 license that creates legal exposure for anything we distribute, and it has essentially no adoption or maintenance base — one maintainer, one star, no downstream users. Pagination is a solved, commodity capability that our framework already provides for free. Recommendation: no action, no spend, no dependency. The cost of adopting it would exceed the cost of building it, and we'd own the maintenance forever.

For engineering (the substance): Don't take this dependency. We get pagination from the framework's LengthAwarePaginator for offset cases and cursorPaginator for large or high-churn datasets — both MIT, both maintained by the core team, both already in the lockfile. If we ever stand up a Symfony/Doctrine service, use KnpPaginatorBundle or Pagerfanta; both are MIT and have real user bases. This package is single-maintainer with zero dependents, meaning we would become its de facto maintainer for a capability that is roughly fifteen lines of query-builder code. The GPL license is a hard stop for any distributed artifact and needs a legal read before any hosted use.

The durable win from this evaluation is the policy, not the package: pagination stays out of the roadmap as a feature, and any third-party dependency in a distributed artifact gets a license check before it gets a pull request.