Pager Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy — pagination is now a closed question. The package resolves firmly toward build natively. Despite being catalogued as a Laravel/PHP candidate, it is a Symfony2 bundle with zero Laravel surface area, so it offers no "buy" shortcut at all. Laravel already ships LengthAwarePaginator, Paginator, and CursorPaginator with Blade templates for Bootstrap and Tailwind. The "buy" side of this decision is empty.
• Consistent pagination UX is a real backlog item — just not this package. The 37.02 opportunity score is a signal about the problem space (data-heavy admin surfaces need predictable, consistent pagination across list views), not about this package. That maps directly to our own roadmap item: a thin shared pagination component and documented standard, deliverable in roughly 1–2 days with zero vendor exposure.
• Cursor pagination is the architecturally valuable takeaway. Offset pagination degrades linearly on deep pages and produces unstable ordering under concurrent writes. The evaluation surfaces a genuine query-layer decision — standardize on cursor/keyset pagination for high-volume tables — that no third-party paginator can make for us. This belongs on the technical roadmap independent of any adoption decision.
• Dependency-intake calibration. A 0-star, 0-dependent, single-maintainer, EOL-framework bundle with a vendor-name/repo-name mismatch (makerlabs vs. smoya) is the canonical profile of a package that fails review. Useful as a worked example for the intake checklist and for training reviewers on provenance checks.
• API contract reference — free design work. If we build the shared component in-house, the bundle's page / perPage / total surface is a sane shape to crib. Take the design, not the dependency.
• Legacy triage only. If we inherit a Symfony 2.x codebase, this is a candidate to tolerate temporarily during migration — never to newly introduce as a stepping stone. Go directly to the modern target instead.
• Nothing on the roadmap should be gated on it. No feature, launch, or commitment depends on this package.

When to Consider This Package

There is no realistic condition under which a Laravel team should adopt this package. The narrow case where its code is worth reading:

• You are writing a paginator from scratch and want a compact reference for the page / perPage / total contract and adapter shape. Read the Adapter/ directory; ignore the rest.
• You are maintaining a legacy Symfony 2.x service already in production, the work is time-boxed toward decommission, and the organization formally accepts no upstream fixes, no security response, and no community support.

Look elsewhere — or do not adopt — when:

• The stack is Laravel. This is the decisive disqualifier. No service provider, no facade, no config publish tag; its Symfony 2.x pins collide with the Symfony 5/6/7 components Laravel 10/11 already require. Zero overlap, zero value.
• The stack is modern Symfony (5/6/7). Use KnpPaginatorBundle, Pagerfanta (babdev/pagerfanta), or Doctrine's Paginator. Symfony 2 bundle conventions do not map onto modern service/bundle configuration.
• Any security, maintenance, SLA, or audit obligation exists. Zero dependents means no downstream bug reports, no security regression testing, no de facto compatibility matrix, and no advisories channel — the worst detection profile.
• You need pagination semantics beyond basic offset paging — cursor/keyset, stable-sort cursors, or infinite scroll are out of scope.
• You need documented, tested behavior. Treat the source as the only specification; there is no evidence of CI or test coverage.
• Provenance is unresolved. makerlabs/pager-bundle versus the smoya/PagerBundle repository raises fork, publish-rights, and possible autoload-collision questions that must be answered before any further evaluation.

Cost of not adopting is low and bounded: native Laravel pagination plus a shared Blade component covers the need in 1–2 days, fully testable and owned.

How to Pitch It (Stakeholders)

Executive summary: do not adopt — and close the evaluation. The package is a paginator bundle for Symfony2, a framework generation that reached end of life in 2018. It has zero stars and zero dependents: no community validation, no realistic path to a bug fix or security patch, and a single maintainer. It also does not fit our stack. Despite being catalogued as a PHP/Laravel candidate, it offers nothing to a Laravel application, which paginates natively out of the box.

For engineering: the dependency fails our intake bar on every axis — maintenance (single maintainer, EOL framework), adoption (0 stars / 0 dependents), fit (Symfony2 bundle versus a Laravel codebase), and scope (offset pagination only). Expect a Composer resolution failure on install; document it so the rejection is evidence-backed rather than asserted. Do not attempt --ignore-platform-reqs to force a fit — that converts a clean rejection into a latent production fault, and a bundle-boot failure in a non-Symfony kernel is a full outage rather than a degraded feature.

Recommended actions:

1. Close the evaluation and record the finding in the dependency registry so it is not re-evaluated.
2. Resolve the transitive question (2h). Confirm whether the package appears in any composer.lock today and what pulled it in; if so, pin or replace the dependent. Also settle the makerlabs / smoya vendor identity and whether it is a fork with patched code.
3. Route the underlying need to the platform backlog. Consistent, predictable pagination across list views is satisfied by native Laravel pagination plus a thin shared Blade component — roughly 1–2 days, no long-term vendor exposure.
4. Document a pagination standard once — offset versus cursor, view conventions, page-size limits — and enforce it in code review. Add cursor pagination for high-volume endpoints as a separate query-layer roadmap item.
5. File an ADR with the constraints found, the substitute chosen, and a re-evaluation trigger (e.g., a maintained Laravel package with active CI and non-zero dependents appears).

The headline for the roadmap: the 37.02 opportunity score is a signal about the problem space, not about this package. Do not let it pull a dead dependency onto the roadmap. The package's only residual value is as a design reference; the genuinely valuable architectural insight it surfaces — that cursor pagination beats offset at scale — is one we can act on immediately, for free.