Paginator Bundle Laravel Package

Product Decisions This Supports

• Pagination build-vs-buy: Informs the recurring "do we own pagination or vendor it?" call. Pagination is commodity infrastructure with well-maintained first-party options on both Laravel (LengthAwarePaginator) and Symfony (Pagerfanta, KnpPaginatorBundle), so this package lands on the "buy/borrow nothing, use the platform" side of the ledger.
• Dependency governance and vendor-risk scoring: A concrete worked example for a dependency policy — archived repo, zero stars, zero dependents, last release July 2018. Useful as a template when defining the acceptance checklist any new composer require must pass (maintenance signal, release recency, downstream adoption, platform fit).
• Platform-fit decisions: This is a Symfony bundle, not a Laravel package, despite being catalogued as a Laravel/PHP package. If the roadmap is Laravel-first, the decision is made on platform mismatch alone and no further evaluation is needed.
• Fork-vs-adopt-vs-remove: The MIT license permits vendoring or forking. If an audit surfaces this in an existing composer.lock, the PM decision becomes "schedule removal" rather than "evaluate upgrade path," because there is no upstream to upgrade to.
• Reference-spec, not dependency: The bundle's value to a product team is as a readable pattern for a thin paginator abstraction — a design input for an internal pagination interface, not a line item in composer.json.
• Does not support: any roadmap commitment to a feature, any customer-facing capability, or any build-vs-buy decision where a maintained alternative exists.

When to Consider This Package

Narrow cases where it is defensible:

• A legacy Symfony application already depends on it, and the cost of removing it this quarter exceeds the risk of leaving it in place — i.e., a documented, time-boxed exception, not a standard.
• You want a small, permissively licensed (MIT) paginator abstraction to read as a reference implementation before writing your own.
• An air-gapped or fully vendored codebase where you already own maintenance of every dependency and accept that burden explicitly.

Look elsewhere — effectively always, and specifically when:

• The product is Laravel. Use the framework's native paginator; there is no gap to fill.
• The product is on Symfony 5+, PHP 8+, or any currently supported runtime. A 2018 release predates those and will not have been tested against them.
• You need security patching, CVE response, or an SLA. There is no maintainer to respond.
• Your dependency policy requires active maintenance, recent releases, or evidence of downstream adoption. Zero stars and zero dependents fail all three.
• The team has no spare capacity to own a fork indefinitely. Adopting an archived package is a quiet commitment to maintain it yourself.
• Compliance, procurement, or enterprise review requires a supported vendor relationship.

How to Pitch It (Stakeholders)

For executives — recommendation: no-go. Do not adopt. This is a small, MIT-licensed pagination add-on for Symfony, last released in July 2018 and now archived. It has zero stars, zero known dependents, and no maintainer. The opportunity is not in the package — it is in the fact that pagination is a solved problem: Laravel ships it in the framework, and Symfony has maintained community options. Choosing a dead third-party library for a solved problem buys us no capability and adds an unowned dependency we would have to patch ourselves. The build cost of in-house pagination is days, not weeks, and the ongoing cost of a fork is indefinite. Action: exclude from the approved dependency list; if it appears anywhere in our code, raise a removal ticket rather than an upgrade ticket.

For engineering — treat it as a pattern, not a package. It is a thin Symfony bundle wrapping a paginator abstraction, MIT-licensed, small enough to read in an afternoon. Its legitimate use is as a design reference if we build an internal pagination interface, or as vendored code in a legacy app we cannot yet migrate. Do not add it to new composer.json files. On Laravel, use the native paginator; on Symfony, use Pagerfanta or KnpPaginatorBundle. Note the platform mismatch in our cataloguing — flagged as a Laravel package, actually a Symfony bundle — and correct it so it does not resurface in future evaluations.