Paginator Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for commodity plumbing. Pagination is table-stakes infrastructure, not a differentiator. The real decision this package forces is whether we spend sprint capacity writing and testing our own paginator (~150 lines plus edge cases) or take a small dependency. It also surfaces a stack-fit question first: this is a Symfony bundle, not a Laravel package — in a Laravel codebase, LengthAwarePaginator/CursorPaginator already ship in-framework and this is a non-starter.
• API contract standardization. Whatever library we adopt, its assumptions become our public contract: page/per_page parameter names, the meta envelope (total, page, per_page, last_page), default and maximum page size. Changing that later is a breaking API change with client migration cost, so it deserves an explicit product decision rather than a default inherited from a library.
• Performance budget for list endpoints. Offset pagination implies COUNT(*) queries and OFFSET scans. This decision point drives whether catalog/search endpoints need keyset (cursor) pagination, what deep-page limits we enforce, and where we accept slower totals for simpler clients.
• Dependency risk acceptance. With 0 stars, 0 dependents, and a single-vendor origin (an internal extraction from a retail tech team, effectively bus factor of one), adoption means owning an unmaintained dependency. MIT licensing and a small source surface make fork-and-vendor viable — so the cost is vetting time and ownership, not lock-in.
• Roadmap prioritization. Paginated lists appear in nearly every admin and back-office surface. This is a "keep it boring and cheap" item; it should not compete with differentiating roadmap work.
• Procurement/legal. MIT, no commercial terms, no attribution burden. No blockers.

When to Consider This Package

Consider it when: you run Symfony 5.4/6.x/7.x with Doctrine, need straightforward offset pagination on internal tools, admin panels, or low-traffic APIs; the team is willing to read the (small) source, pin a version, and fork if it stalls; and you prefer a convention over a framework-agnostic library.

Look elsewhere when:

• Your stack is Laravel or anything non-Symfony — use the framework-native paginator; adopting a Symfony bundle here is pure friction.
• The endpoint is public, high-traffic, or drives infinite scroll — you want keyset/cursor pagination, not offset.
• You need community support, security advisories, or a maintenance SLA — prefer Pagerfanta, KnpPaginatorBundle, or API Platform's built-in pagination.
• You're planning to standardize it across many teams. Zero dependents means zero field-tested edge cases at scale; treat it as a reference implementation, not a safe default.

The October 2025 release suggests it's alive, but 0 stars and 0 dependents are a signal about ecosystem maturity, not code quality. Weight them as maintenance risk, not as a verdict.

How to Pitch It (Stakeholders)

To executives: pagination is commodity plumbing — no customer will choose us because of it, and no competitor will win because of it. This package is a convenience, not a strategic dependency. Recommendation: do not introduce it into a Laravel codebase, where the framework already solves this. If we operate a Symfony service, allow it only as a small, MIT-licensed, forkable utility with a pinned version and a named owner. The decision that actually matters is our pagination contract — page-size caps, response envelope, and where we use cursors instead of offsets — because that is what clients integrate against.

To engineering: small, readable surface area, permissive license, recent release. The risk is bus factor and absence of real-world dependents, not licensing or lock-in. Budget roughly half a day to review the source before adopting, and assume one day to fork if it's abandoned. Do not let it silently define our API envelope — treat that as a separate, explicit contract decision.