Pager Bundle Laravel Package

Product Decisions This Supports

• Stack-mismatch triage before roadmap commitment. The package is a Symfony bundle, not a Laravel package — no service provider, no extra.laravel, no Blade/Twig overlap with Laravel conventions. The PM decision it supports is not "add pagination" but "confirm whether pagination tooling is a Symfony legacy concern or a Laravel-native one," which determines whether this dependency belongs on the roadmap at all.
• Build vs. buy for pagination. Laravel already ships LengthAwarePaginator, paginate(), and Blade pagination views. The decision this package informs is replace vs. retain: for Laravel-first products, "buy" here means adopting an integration burden for functionality the framework gives away; for Symfony 2.x/3.x estates, "buy" means a low-cost compatibility bump (^2.0.1) that avoids rewriting list/table views ahead of a framework upgrade.
• Framework upgrade sequencing. v2.0.1 is a compatibility-only patch — its entire content is Symfony v3.0 support. That makes it a signal for scheduling a platform upgrade, not for justifying new capability. Treat it as a dependency-risk line item in the upgrade plan, not a feature line in the release notes.
• Maintenance-risk scoring. Zero stars, zero dependents, no release since 2015. Treat it as low-velocity, compatibility-only, effectively unmaintained when scoring dependency risk against a maintained pagination library or the framework's own paginator.
• Use cases served (scoped): server-side pagination of result sets — admin tables, list views, search results — where the team already standardizes on Symfony's Kernel/DI/Twig conventions and wants pagers configured once in the container rather than rebuilt per controller. Cursor/keyset pagination, API pagination for SPAs, and streaming datasets are explicitly out of scope.

When to Consider This Package

Consider it when:

• The codebase is Symfony 2.x/3.x and you want pagination wired through the bundle/config conventions rather than hand-rolled — v2.0.1 is the minimum version that clears Symfony 3.0.
• You are executing a Symfony 3.0 upgrade and need to prove the pagination dependency still resolves; the patch is a single constraint widening, so it can ride the same change window.
• Requirements are simple, server-rendered pagination with modest rendering needs and no cursor/keyset semantics.
• The pager logic can be isolated behind an application-owned adapter, keeping bundle concepts (DI extension, Twig extension, templates) out of domain code.

Look elsewhere when:

• The product is Laravel-first. This is the dominant disqualifier: Composer will install it, but nothing auto-wires, no service provider registers, and every tutorial you find assumes Symfony's Kernel. Use Laravel's built-in paginator.
• You need modern pagination semantics — cursor/keyset pagination, API pagination, or large/streaming datasets.
• You need active development or forward-compatibility signals. A 2015 patch that only adds Symfony 3.0 says nothing about Symfony 4+, current PHP, or security patching. Verify compatibility independently before any greenfield adoption.
• API or headless/SPA front ends are the primary consumer — a Twig-era rendering bundle is the wrong shape.
• You require long-term support guarantees or a named maintainer with a release cadence. Assume internal ownership of the code, including the option to vendor/fork the small pager class.

How to Pitch It (Stakeholders)

To executives: This is a tiny maintenance release — it adds Symfony 3.0 compatibility and nothing else: no new features, no breaking changes, no deprecations, no migration work. The business value is narrow but real: on a Symfony estate it keeps a pagination dependency viable through a planned framework upgrade, avoiding a forced rewrite of list and table views. Two caveats matter for the decision. First, the package is a Symfony bundle, not a Laravel package — if our roadmap is Laravel-based, adopting it buys integration friction rather than saved work, and Laravel's built-in paginator already covers the need. Second, the project shows zero stars, zero dependents, and no release since 2015, so we should treat it as unmaintained code we own once adopted. Recommendation: approve as a routine dependency bump only if we are on Symfony; if we are Laravel-first, flag it for replacement rather than adoption.

To engineering: v2.0.1 declares Symfony v3.0 support and installs via Composer ("kgilden/pager-bundle": "^2.0.1"). No API surface changes, so treat it as a low-risk constraint bump — ideally landed in the same change window as the Symfony upgrade so compatibility is proven together, and staying on 2.0.0 is fine if you are not on Symfony 3. On the Laravel side, assume no auto-discovery: no service provider, no vendor:publish, no Blade views. Only the PHP pager object transfers cleanly; the Twig extension and templates must be reimplemented once as a Blade partial, and URLs must forward request()->query() so page links don't silently drop active filters. Clamp out-of-range pages and never run two paginators against the same ?page= parameter. Before committing, validate three things: (1) resolved Composer constraints against our actual PHP/Laravel/Symfony versions — Symfony 3.0 is EOL and likely conflicts with modern Laravel's Symfony components; (2) whether the pager is framework-agnostic enough to hide behind an interface; (3) who owns the fork if we need behavior changes, since upstream activity is effectively nil. Default position for new Laravel work: use LengthAwarePaginator and skip this dependency entirely.