Pagination Laravel Package

Product Decisions This Supports

• Build vs. buy vs. framework-native — resolved in favor of framework-native. This package is explicitly marked no longer supported (10 stars, MIT, single-maintainer provenance). For anything as commoditized as pagination, the correct decision is to use Laravel's first-party Paginator / LengthAwarePaginator and the links() Blade renderer. This package does not clear the bar for adding a third-party dependency.
• Roadmap: no allocation. Do not schedule feature work, integrations, or UI polish that assumes this package is present. Anything currently planned against it should be re-scoped onto native pagination.
• Dependency hygiene policy input. This is a concrete example to cite when writing or tightening a rule like "no dependencies without an active maintainer, a release in the last 12 months, and a documented upgrade path." Use it as the worked example in that policy.
• Existing-usage remediation decision. If it is already in the codebase, this justifies a small, bounded tech-debt ticket: inventory call sites, replace with native pagination, remove the dependency. Effort is typically low because pagination surfaces are shallow and easy to regression-test.
• Security and procurement triage. Unmaintained code means no upstream patches. That is a standing risk acceptance decision — and the recommendation is to decline rather than accept it.
• Vendor/reference evaluation. Informs how much weight to give other packages from the same author or similarly low-signal repos: treat them as read-only reference, not as dependencies.

When to Consider This Package

• Essentially never for new work. There is no scenario in a supported Laravel application where an abandoned pagination helper is the right call over the built-in paginator. The framework already ships the capability, the query-builder integration, and the Blade rendering.
• Legitimate narrow case — archaeology, not adoption. Reading its source while auditing or migrating a legacy codebase that already depends on it, to understand the exact markup and behavior you need to reproduce with native pagination before removal.
• Look elsewhere (i.e., to the framework) when: you need Bootstrap/Tailwind-styled pagination views (Laravel ships these), custom presenters, cursor pagination, or API-shaped paginated responses (ResourceCollection). All are covered first-party.
• Red flags that should end the evaluation immediately: "no longer supported" in the description, no recent releases, low star count relative to its problem domain, and a problem domain the framework already owns. Any one of these is a caution; all four together are a no.

How to Pitch It (Stakeholders)

For executives: We evaluated a third-party pagination add-on for Laravel and recommend against adopting it. It is no longer maintained, which means no security patches and no compatibility guarantees as we upgrade the framework. Pagination is a solved problem in Laravel itself, so adopting this would add risk and cost with no offsetting capability. Recommendation: use the framework's built-in pagination, and if the package is already in our code, fund a small cleanup ticket to remove it.

For engineering: This is dead code waiting to happen. The package is unsupported, low-adoption, and duplicates LengthAwarePaginator plus links(). Do not bring it into new services. Where it exists, replace call sites with native pagination and styled pagination views, cover the list endpoints with a couple of regression tests, and drop the dependency from composer.json. If we have a documented behavior we actually liked (custom markup, presenter semantics), port that as a local Blade view or presenter — a few dozen lines we own beats an unmaintained dependency.