Ux Pagination Laravel Package

Product Decisions This Supports

• Build vs. buy on pagination. This package is a small, MIT-licensed, Symfony-maintained layer that replaces hand-rolled paging code (Doctrine query slicing + Twig navigation markup). It is a "buy" only for teams already on Symfony/Twig; for a Laravel product it is a "don't build, don't buy — use what ships with the framework" decision.
• Stack standardization on the roadmap. The package's real product value is consistency: one paging abstraction across Symfony services, one set of overridable templates that map to a design system, and cursor pagination available as a first-class option rather than a bespoke implementation per team. That is a maintainability and UX-consistency argument, not a feature argument.
• Feature enablement for large, growing datasets. Cursor pagination is the pattern that keeps deep pagination viable as tables grow (activity feeds, audit logs, admin tables, notification lists). v3.6.0 makes cursor paging correct on timezone-aware datetime columns, which unblocks any feature that paginates event/created-at data in non-UTC or tz-aware storage — a common and previously risky case.
• Design-system alignment. Overridable Twig templates mean pagination controls can be made visually consistent across products without forking logic. Useful when a redesign or accessibility pass is scoped.
• Scope correction as a decision. The evaluation was framed as a Laravel/PHP package; it is a Symfony UX package. The PM-level decision this supports is explicit de-scoping: evaluate for the Symfony estate, close for Laravel, and re-scope the ticket if Laravel pagination was the actual intent. Continuing to evaluate it as a Laravel candidate burns review cycles for no product return.
• Maintenance budget allocation. No security advisory, no new integration surface, predictable release cadence tracking Symfony's lifecycle. The decision is "schedule as routine dependency hygiene," not "open a project."
• Roadmap input on framework dependency. Adopting this net-new ties pagination's support lifetime to the Symfony versions the estate runs. If Symfony isn't already a tracked upgrade obligation for that team, that's a roadmap-level commitment to record before adoption, not after.

When to Consider This Package

Adopt when:

• The service is Symfony with Twig rendering; the UI tier assumes Twig components, not Blade or a JSON API.
• Data access is Doctrine ORM or DBAL — the package's adapters are built for those, plus Pagerfanta.
• Symfony UX is already present or acceptable in the dependency tree; adding it solely for pagination is a heavier decision than adding pagination to an existing UX stack.
• Cursor pagination is a genuine need — large or offset-averse result sets where numbered paging degrades.
• The team wants pagination controls that can be restyled per design system without touching paging logic.
• Pagination is currently duplicated or inconsistent across services and consolidating has value beyond the code saved.

Look elsewhere when:

• The product is Laravel. Laravel's native paginator already covers Eloquent, query builder, Blade views, and JSON responses. Adopting this creates two pagination paradigms in one codebase with no user-facing benefit. This is the default answer for a Laravel-first product.
• The front end is an SPA or consumes JSON only. The PHP Pager can be used headless, but that discards the Twig/UX rendering tier — the package's main value — and leaves you maintaining a custom renderer for a thin abstraction.
• The team has no Symfony/Twig fluency. Ramp-up is roughly a day for a Symfony developer and a multi-day, low-returning effort for a Laravel-only team. That gap is itself the recommendation.
• You need more than paging. Rich client-side sorting, filtering, saved views, or virtualized infinite scroll are outside scope; don't select this hoping it grows into a data-grid solution.
• You require a large, fast-moving community or commercial support. This is a young, low-star package under the Symfony umbrella; support lifetime is bounded by Symfony's release cycle, not by a vendor SLA.
• You are mid-migration or on an unsupported Symfony version. Version skew between the PHP package and the published JS/CSS assets is the most common failure mode with UX packages; don't adopt while the framework version itself is in flux.

How to Pitch It (Stakeholders)

One line: A small, free, Symfony-maintained component that standardizes and simplifies pagination — worth adopting inside our Symfony services, and not applicable to our Laravel product.

For executives: This is a low-cost, low-risk dependency decision, not a project. The package is MIT-licensed, maintained under the Symfony umbrella, and replaces code we would otherwise write and maintain ourselves. There is no security advisory and no urgency: it can ride the normal dependency cycle. The main value is consistency — one paging approach and one set of design-aligned controls across Symfony services — plus correct deep pagination on large datasets, which is what keeps list-heavy features responsive as data grows. The strategic decision to make is scoping: adopt in Symfony, decline in Laravel, and stop spending review time on the mismatch.

For engineering: In Symfony services this is a routine minor bump — no migration, no new integration surface. Two things must be checked before merge, not assumed: (1) a regression test proving page boundaries are correct for cursor pagination over timezone-aware datetime columns, because v3.6.0 is a correctness fix and output will legitimately change for anyone paginating those columns — the failure mode is silent, data-dependent page drift; (2) a grep for the removed adapter-iterator method, since the changelog classifies its removal as a bug fix and any subclass calling it will fatal. Treat the minor-version label as "probably non-breaking," not guaranteed. Then bump one service, deploy to staging with production-shaped data, soak a cycle, and batch-roll the rest — this doesn't merit per-service ceremony after the first.

For Laravel stakeholders: Don't adopt this. It pulls in Symfony components, assumes Twig, and duplicates functionality Laravel already provides with Blade and Eloquent integration. The cost isn't licensing or performance — it's two divergent pagination conventions and a second idiom for every engineer to learn. If the intent was to evaluate a Laravel pagination option, the evaluation should be re-scoped.

Recommendation: Approve as a routine dependency for the Symfony estate, contingent on the two pre-merge checks above. Decline for Laravel services. Record the inherited Symfony upgrade obligation if this is a net-new adoption, and revisit the consolidation question — whether pagination should be one internal standard — once the first service has soaked a release.