Product Decisions This Supports
- Framing a pagination-strategy decision, not a dependency decision. The real product question this package touches is offset vs. cursor (keyset) pagination: cursor pagination gives stable results on frequently-mutating data (no duplicated or skipped rows while a user scrolls), roughly constant query cost at deep pages, and a better fit for infinite-scroll and mobile "load more" patterns. That is a genuine UX and performance decision worth making explicitly per-endpoint.
- Roadmap input for feed-style surfaces. If the roadmap includes activity streams, notifications, search results, or a mobile client that pages through lists, this is the category of solution to evaluate. It is not the specific artifact to adopt.
- Build-vs-buy leverage as prior art. With 0 stars, 0 dependents, and an archived repo, the only defensible use is as a reference implementation — reading the source to understand cursor encoding, ordering constraints, and tiebreaker handling before we implement internally.
- Where it argues against itself. For paginated admin tables that need "jump to page N" and an exact total count, cursor pagination is the wrong tool regardless of library; those surfaces should keep offset pagination. This package doesn't change that calculus.
- What it does not support: any long-term dependency commitment, security-patch planning, or vendor-risk assessment — there is no maintainer surface to assess.
When to Consider This Package
Treat "consider" as "read," not "install." The criteria are narrow:
- Legacy Laravel (< 8) that cannot be upgraded and needs cursor pagination now. Read it as prior art, then fork and vendor it with a named internal owner — do not depend on archived upstream.
- You want a compact worked example of keyset pagination semantics to inform an in-house implementation or a design review.
Look elsewhere — in practice, almost always:
- Laravel 8+ already ships
cursorPaginate() in core. It is maintained by the framework, documented, and covers this ground. That single fact makes the build-vs-buy answer "use the framework" for the overwhelming majority of cases.
- Archived status is disqualifying for a dependency. No security patch path, no compatibility guarantees against current Laravel/PHP releases, no community support, no upgrade story. The integration and eventual-removal cost exceeds the cost of writing this ourselves by a wide margin.
- Complex requirements — multi-column sort keys, custom tiebreakers, union or joined queries — need either a maintained alternative or an in-house implementation. This package won't carry that weight, and we can't rely on it being fixed.
- Read the 0.05 score as "insufficient evidence of health," not "bad code." The code may be perfectly fine; there is simply no signal — no stars, no dependents, no recent activity — to justify betting a roadmap item on it.
How to Pitch It (Stakeholders)
To executives: The underlying need — fast, stable pagination for large and fast-changing lists — is real and worth planning for. This particular package is not part of the answer. Adopting it would add a dependency we'd have to own, patch, and eventually remove, in exchange for a capability Laravel core already provides at zero added risk. Recommendation: no adoption action; retain as a reference example and move on.
To engineering: Archived, unmaintained, zero dependents. On Laravel 8+ use native cursorPaginate() and stop there. The package is only interesting as a reference implementation, or for legacy 7.x-era code — and in that case fork it with an assigned owner rather than pointing a dependency at an archived upstream. If an endpoint genuinely needs cursor semantics (infinite scroll, mobile paging, high-churn datasets), scope it as a small in-house change against the framework feature; if it needs page numbers and totals, keep offset pagination and don't force the pattern.