Pagination Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for table UX: Informs the classic "do we roll our own pagination + sortable column headers, or take a dependency?" decision. The bundle packages three commodity capabilities — page-size configuration, Doctrine-backed paging, and a Twig sortable_header() helper — that are individually cheap to write and rarely a differentiator.
• Roadmap scoping for admin/internal tooling: Useful as a reference implementation when estimating the cost of "list views with sorting" across an internal back office. It shows the minimal surface area such a feature actually needs (default page size, max page size, sort query-string key, header template), which helps you scope an in-house equivalent in hours rather than days.
• Architecture direction (Symfony vs. framework-agnostic): The package's registration model (AppKernel::registerBundles()) forces a decision about how tightly coupled your UI layer is to a full-stack framework. That's a strategic call worth making explicitly, not by accident of a dependency.
• Vendor risk appetite: With zero stars, zero dependents, and a last release in July 2017, this is a live data point for defining your adoption bar. It supports a policy decision — e.g., "no unmaintained dependencies in production paths" — more than it supports a feature decision.
• NOT supported: any Laravel roadmap item. This is a Symfony bundle. It cannot be installed into a Laravel application without effectively rewriting it. If your product is Laravel-based, this package does not enter the build-vs-buy conversation at all.

When to Consider This Package

Consider it only under a narrow, largely historical set of conditions:

• You maintain a legacy Symfony 2/3 application already using Doctrine ORM, Twig, and bundle-based service registration, and you need paginated, sortable tables quickly.
• Your tables are internal, low-traffic admin screens where a frozen 2017 dependency has no meaningful security or performance exposure.
• You have vendored or forked the code and are prepared to own it, including PHP 8 compatibility, Doctrine API drift, and Twig deprecations.
• You need a reading reference for a pagination/sorting abstraction — not a runtime dependency.

Look elsewhere — or build it — in essentially every other case:

• Any Laravel codebase. Hard blocker. Bundles are not Laravel packages; there is no service provider, no config publish, no Blade integration.
• New builds of any kind. Roughly eight years without a release means no PHP 8 support, no Doctrine 3 support, no security patching, and no maintainer to escalate to. Zero dependents means zero community signal that it works against current versions.
• API-first or headless products, where pagination belongs in a JSON contract (cursor-based, stable ordering) rather than in a Twig helper.
• Non-Doctrine data sources — Eloquent, raw query builders, external search services. The README states the implementation is Doctrine Paginator-based "for now," and "for now" never arrived.
• Anything customer-facing where sortable headers, accessibility, deep-linkable state, and page-size persistence are real product requirements rather than table dressing.

How to Pitch It (Stakeholders)

For executives (one line): This is an abandoned 2017 Symfony utility for paginated tables; it is not usable in our Laravel stack, and even in a Symfony stack it represents unowned technical risk — we should treat it as a design reference and build the equivalent in-house.

For engineering:

• It solves three small, well-understood problems: page-size config with a default and a ceiling, Doctrine-backed paging, and a Twig sortable_header(label, query_key) helper that auto-translates labels.
• The entire configuration surface is four keys — default_page_size, max_page_size, sortable_header_template, default_sort_query_string. That is roughly a half-day of work to reproduce idiomatically, with tests, in whatever framework we actually use.
• Do not add this as a dependency. Zero stars, zero dependents, no release since 2017-07-04, and no evidence of PHP 8 or modern Doctrine support. Adopting it trades a small amount of implementation time for an indefinite maintenance liability we would immediately own.
• Recommended action: spike an in-house pagination + sortable-column component behind our existing table conventions; keep this repository bookmarked as a requirements checklist, not a dependency. If we are on Laravel, use the framework's native paginator plus a small sortable-header Blade component.