Pagi Laravel Package

Product Decisions This Supports

• Build vs. buy for commodity UI: Pagination is not a differentiator. Pagi is a thin, opinionated Blade/Tailwind pagination renderer, so adopting it converts an in-house UI chore into a dependency — engineering time goes to features instead of markup, ARIA attributes, and edge cases around page-window truncation.
• Design-system consistency: It standardizes pagination output across every paginated surface (blog/archive indexes, search results, admin list views, taxonomy archives). That is a UX-consistency decision as much as a technical one, and it is cheap to reverse.
• Roadmap / upgrade planning: This release (v1.1.1) is a dependency bump for Laravel 12. Its product meaning is not new capability — it is evidence the package tracks upstream framework releases, so it does not become a blocker in our next Laravel major-version upgrade. That supports "keep, schedule no migration work" rather than a re-evaluation.
• Use cases it unlocks: Server-rendered pagination in Laravel apps and Roots/Sage WordPress themes using Blade + Tailwind; simple (prev/next) pagination, standard length-aware paginators, and per-view customization of window size and wrapper classes without publishing vendor views.
• Decision this release supports: No action. v1.1.1 contains no feature, behavior, or breaking change — it is a maintenance release. Do not re-open the build-vs-buy question on the basis of it; only confirm compatibility on our version matrix.

When to Consider This Package

Adopt when most of the following hold:

• The application is Laravel (or a Sage/Blade WordPress theme) rendering pagination server-side in Blade.
• The front-end uses Tailwind CSS, or we are willing to override the wrapper/link classes to match our design tokens.
• We want a small, single-purpose surface: render a paginator, style it, move on — not a component library.
• We need per-view control (page window size, container classes, simple vs. length-aware pagination) without forking or publishing many vendor templates.
• We are on, or moving to, Laravel 12 / PHP 8.2+, which this release targets.

Look elsewhere when:

• The design system is Bootstrap or a bespoke CSS framework; Laravel's bundled pagination views or a design-system-native component will be less friction than overriding this one.
• The surface is API-only — use the paginator's toArray()/API resources; this package adds nothing.
• Pagination is client-side or infinite-scroll (Livewire, Inertia, Alpine). Pagi renders links; it does not manage state or lazy-loading.
• We need strict accessibility/SEO guarantees or heavy customization (custom ellipsis behavior, ad slots between pages, analytics hooks on each link). At that point owning a small Blade partial is cheaper than fighting an abstraction.
• Single-maintainer risk is unacceptable for the surface in question. This is a small, one-author package; treat it as a convenience, not infrastructure.

How to Pitch It (Stakeholders)

For executives: Pagi is a small, free, MIT-licensed package that replaces hand-written pagination markup with a consistent, Tailwind-styled component across our Blade views. The release we just reviewed (v1.1.1) is maintenance only — a dependency bump adding Laravel 12 support. There are no new features, no breaking changes, and no migration cost; it simply confirms the package will not hold us back on our next framework upgrade. Lock-in is low: usage is a handful of Blade calls, and replacing it means editing a single partial. The main caveat is that it is maintained by one person, which is acceptable for a UI convenience of this size but should keep it out of any "critical dependency" register.

For engineering: v1.1.1 bumps dependencies for Laravel 12 compatibility — nothing else changed. Action: run composer update log1x/pagi on a branch, confirm our PHP version satisfies the Laravel 12 floor (8.2+), and smoke-test the paginated views (index, search, admin lists) since the change is transitive-dependency surface rather than package code. Recommended hygiene: consume it through our own Blade partial/component wrapper so a future swap or fork is a one-file change, pin a caret constraint, and add a pagination rendering assertion to the test suite so a silent dependency break shows up in CI rather than in production. No code changes are required by this release.