Pager Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for commodity UI. Pagination is table-stakes — every mature framework already ships it (Laravel's paginate()/simplePaginate() and LengthAwarePaginator; Symfony's Pagerfanta and KnpPaginatorBundle). The real decision this package informs is whether we ever take a third-party dependency for something a team can implement in an afternoon. The answer here is a clean "no," and that becomes a reusable precedent.
• Framework-boundary hygiene. The request labels this a Laravel/PHP package; it is a Symfony bundle (type: symfony-bundle, bundle class, Twig templates, service-container wiring) targeting Symfony ≥3. There is no supported path where it is a dependency of a Laravel app without an adapter we own forever. That is a product decision about what crosses our stack boundary, and who pays for the port.
• Dependency/vendor-risk policy. Zero stars, zero dependents, single maintainer, EOL framework major. This is the textbook case for a minimum-adoption threshold in our engineering standards: below N stars / no dependents / no release cadence ⇒ require a fork-and-own plan and a named owner before adoption.
• List/table UX standardisation. The genuinely useful product decision hiding here is not "adopt this bundle" but "define pagination once": page-size defaults and caps, query-string contract, cursor vs. offset, empty and error states, accessibility and i18n of controls. A shared internal PageResult contract beats any micro-package.
• Legacy Symfony consolidation. Only relevant to a maintenance roadmap for ageing Symfony estates — not greenfield. Informs whether we fund an exit from Symfony 3-era dependencies.
• Roadmap de-prioritisation. Nothing here differentiates the product. Pagination should be invisible plumbing; spending roadmap capacity evaluating it is a poor return.

When to Consider This Package

Consider it only if:

• You maintain a Symfony ≥3 application and need basic offset pagination for an internal tool, prototype, or throwaway spike.
• You are prepared to vendor or fork the code (MIT permits this) and accept full ownership of maintenance, security patches, and upgrades.
• The surface is low-risk: no PII exposed via page parameters, no untrusted input reaching query building, no compliance scope, no accessibility or SEO requirement on the controls.
• You have confirmed via composer.json that its PHP/Twig constraints intersect your supported matrix.

Look elsewhere when:

• You are on Laravel. Use the native paginator — maintained, documented, tested, integrated with Eloquent and Blade. Porting this bundle has no upside.
• You need SLAs, security review, or long-term support. No release cadence, no community, no dependents means nobody else is finding the bugs for you; on-call engineers will read source directly.
• You need cursor/keyset paging, i18n, accessibility, or SEO-friendly pagination for large or real-time datasets — none of that is evidenced.
• Your dependency policy requires provenance, CVE monitoring, or maintainer succession.
• You are on Symfony 6/7 and want a maintained, widely adopted option (Pagerfanta, KnpPaginatorBundle).

The disqualifying question is upstream of all of these: do we actually have Symfony services? If the estate is Laravel, this is a non-starter and the ticket should be closed.

How to Pitch It (Stakeholders)

To executives: Pagination is undifferentiated plumbing — it does not win customers or open markets, and every framework we use already ships it. This package has no adoption signal (zero stars, zero dependents, one maintainer), targets a Symfony generation that has been end-of-life since 2021, and cannot drop into a Laravel codebase. My recommendation is do not adopt: the cost of evaluating, forking, and owning it exceeds the cost of what our frameworks already provide, and it introduces supply-chain and upgrade-blocking risk for zero strategic return.

To engineering: Treat this as a reference implementation at best, and read it as a cautionary example rather than a candidate. For Symfony work, benchmark against Pagerfanta and KnpPaginatorBundle on maintenance activity, test coverage, and upgrade path; for Laravel, use the native paginator. If we somehow do adopt anything, we fork it into our namespace, pin it, wrap it behind an internal PaginatorInterface returning a neutral PageResult DTO, and assign an owner — budgeting for a permanent fork within twelve months. The realistic risks to plan for are framework-upgrade deadlock (highest probability and cost), silent mis-pagination on GROUP BY/HAVING/DISTINCT queries, Twig major-version escaping drift, and reflected-XSS in links built from request query strings.

Parallel track regardless of this decision: write the pagination standard once — capped perPage, a documented query-string contract, cursor pagination for high-volume endpoints, cached or approximate counts where totals need not be exact — and add a minimum-adoption threshold to our dependency guidelines so this evaluation does not recur.

Bottom line: a low-value, low-signal, framework-mismatched component that fails both the build-vs-buy and vendor-risk tests. Recommend "no," with framework-native pagination as the default and a documented list-UX standard as the deliverable.