Pager Bundle Laravel Package

Product Decisions This Supports

• The build-vs-buy call on pagination — and the answer here is "neither." Pagination is commodity infrastructure: a page-size parameter, a count query, an offset/limit, and a page-link renderer. It is roughly a day of engineering work or one line in Laravel ($query->paginate(25)). Any dependency in this slot must justify itself purely on maintenance risk, and this one cannot.
• Framework-fit triage. Despite being catalogued as a Laravel/PHP package, ongr/pager-bundle is a Symfony bundle (DI extension, service definitions, Bundle class). It cannot be dropped into a Laravel app without effectively rewriting it. That is a hard stop for any Laravel roadmap item — it removes the "maybe" and makes this a no.
• Roadmap de-prioritization of "listing UX." If a ticket says "add pagination to the orders/search/admin tables," the PM decision is not "which package" but "which existing framework primitive." Framework-native pagination means zero new dependency, zero license review, zero procurement friction, and instant onboarding for new hires.
• Legacy-platform freeze decisions. The one legitimate context: a Symfony 2.x application on the ONGR Elasticsearch stack that is in maintenance-only mode, where the existing composer.lock already pins this. There, the decision is "leave it, don't extend it, plan migration off it" — not "adopt it for something new."
• API contract decisions. Pagination shape (page/offset vs. cursor) is an externally visible API contract. A library that hasn't shipped since 2015 will not help you reason about cursor-based pagination for high-volume endpoints, which is where the actual product risk lives today.
• Dependency-governance policy. This is a clean worked example for a "no new dependencies without an active release in the last 24 months and at least one maintained dependent" rule. Opportunity score 17.08, 2 stars, 0 dependents, last release 2015-02-24 — it fails every healthy-dependency test simultaneously.

When to Consider This Package

Consider only if all of the following are true:

• The application is Symfony, not Laravel — the package is structurally incompatible with Laravel's container, service providers, and paginator contracts.
• You are on a legacy Symfony 2.x / PHP 5.x-era codebase that is feature-frozen and already depending on the ONGR Elasticsearch bundle family, so this is already in composer.lock.
• You have no plan to upgrade PHP or Symfony for the foreseeable life of the app.
• Nothing security-sensitive is exposed — the surface is rendering page links and slicing result sets, which limits (but does not eliminate) CVE exposure.
• You accept zero upstream support: no fixes, no PHP 8 compatibility, no security patches, no answers to questions.

Look elsewhere — this is the default — when:

• You are building in Laravel: use the built-in paginator. It is free, maintained by the framework, and already familiar to every Laravel developer you will hire.
• You are building in modern Symfony (4/5/6/7): use Pagerfanta (actively maintained, framework-agnostic) or KnpPaginatorBundle (large install base, maintained).
• You need cursor-based / keyset pagination for large or real-time datasets — neither this package nor classic offset paginators solve that correctly.
• You need SEO-correct page links, canonical URLs, or infinite-scroll semantics — you want a maintained, documented library, not a 2015 bundle you cannot ask questions about.
• Compliance, procurement, or an SBOM requirement applies — an abandoned 2015 dependency with 0 dependents is a finding waiting to be written up, and MIT licensing does not offset that.

Verdict: Do not adopt. Migrate away if already present. Budget is better spent on a pagination design decision (page size, cursor vs. offset, empty-state behavior) than on this dependency.

How to Pitch It (Stakeholders)

To executives — one line: We recommend against adding this component; pagination should come from the framework we already pay for, not from an unmaintained 2015 library.

• Cost of ownership exceeds cost of build. Adopting it saves at most a day of engineering. It adds an indefinite liability: no maintainer, no patches, no upgrade path, and a future forced migration that will cost far more than the day it saved.
• It doesn't fit our stack. It's a Symfony bundle; our application is Laravel, which ships pagination in the framework. Choosing it means paying integration cost to get functionality we already own.
• Health signals are uniformly red. Last release February 2015; 2 GitHub stars; 0 known dependents; opportunity score 17.08. A package nobody else uses is a package nobody else has debugged.
• Business risk is concentrated and avoidable. Pagination touches every list view, every search result, and potentially every public API response. That is a poor place to carry an unsupported dependency.
• Recommendation: Build on the framework's native paginator for Laravel; if any Symfony surface exists, standardize on Pagerfanta. Treat pagination as a solved, non-differentiating capability and direct engineering effort to features customers actually notice.

To engineering — the ask: confirm no active ongr/pager-bundle dependency in shipping code; if one exists in a frozen legacy app, log it as technical debt with a migration target and do not extend its usage. Estimate the replacement at under one sprint for a typical CRUD surface.