Technical Evaluation

Architecture fit

Laravel-native package (service provider + auto-discovery) that wraps Eloquent/Query Builder with a cursor paginator. Drop-in for API controllers, low conceptual surface.
Fit is narrow: Laravel 8+ ships native cursorPaginate(), so this package is effectively a pre-Laravel-8 shim. Its remaining value is (a) Laravel ≤7 estates, or (b) edge cases native pagination does not cover (custom/multi-column cursors, non-standard query shapes).
The low opportunity score (~0.54) is consistent with native cannibalization — this is not a strategic dependency, it is a compatibility artifact.

Integration feasibility

Very low cost to adopt: composer require, discovery, swap paginate() for the cursor method on selected endpoints. Days, not weeks.
The real constraint is the inverse: the package's Composer constraints likely pin PHP 7.x / Laravel ≤8, which fights the platform upgrade roadmap.

Technical risk

Archived (last release 2020-11-24), MIT, ~70 stars. No security patches, no PHP 8.1+/Laravel 9/10/11 support, no upstream triage.
Method-name collision risk with native cursorPaginate() during framework upgrades.
Low community/bus factor: limited issue coverage and test visibility; DB-driver support unverified.
Core correctness risk is cursor stability under concurrent writes — correctness depends on a unique, immutable tiebreaker in the sort key, not on the package.

Key questions

What Laravel/PHP versions must we support, and what is the upgrade horizon?
Do we need behavior native cursorPaginate() does not provide, or is this pure legacy compatibility?
Which DB drivers must be covered, and is cursor encoding signed/opaque enough for external clients?
Who owns a fork if we retain it, and what is the annual maintenance/security-review budget?
Are there transitive dependencies with open CVEs flagged by SCA tooling?

Integration Approach

Stack fit

Treat as a legacy-compat shim for Laravel 5.5–7 / PHP 7.2–7.4 only. On Laravel 8+, standardize on native cursor pagination.

Migration path

Inventory endpoints actually using the package.
Run a parity PoC: native cursorPaginate() vs. package output on 1–2 representative endpoints (ordering, tiebreaker, response shape).
If parity holds → migrate endpoints and remove the dependency.
If gaps exist → extract the needed logic into an internally owned, non-archived module (fork/vendor) with CI, pinned deps, and tests.
Decommission the package after full cutover.

Compatibility

Validate Composer constraints against target Laravel/PHP; test for method collisions with native pagination; run against all target DBs; check PHP 8 deprecations; add integration tests around cursor encode/decode and malformed-token handling.

Sequencing

Audit → parity PoC → adapter/fallback decision → endpoint-by-endpoint migration behind feature flags → dependency removal → document the cursor contract (sort order, unique tiebreaker, token TTL/opacity).
Recommendation: do not adopt net-new; if already present, migrate to native cursor pagination and retire the package within one or two release cycles.

Maintenance

Adopting means we become the maintainer. Budget for annual security review, dependency pinning, and upgrade-tax testing; prefer an internal fork over an unmodified dependency.

Support

No vendor; GitHub issues only, and archived repos get no triage. Requires a named internal owner/SME; bug escalation is effectively DIY.

Scaling

Cursor pagination scales better than offset at depth; package overhead is negligible. The real scaling constraints are stable sort keys and composite indexes on the ordering columns — infrastructure concerns, not package concerns.

Failure modes

Ramp-up

Low for Laravel developers (hours to first endpoint); moderate for cursor semantics (stable ordering, opaque tokens, client contract) — roughly 1–2 days per engineer, plus additional time for fork ownership and upgrade testing if retained.