Pager Bundle Laravel Package

Technical Evaluation

Architecture fit. ongr/pager-bundle is a Symfony bundle, not a Laravel package. It integrates via Symfony's Bundle registration, DI container compiler passes, and a services.xml config tree under the ongr_pager key. It has no Laravel service provider, no facade, no publishable config, and no auto-discovery. In a Laravel codebase it is a foreign artifact: you would either install Symfony's DI/HttpKernel components alongside Laravel (an unacceptable dependency footprint) or vendor the pagination logic out of the bundle and re-implement the wiring. Either path means you are not "using the package" — you are using it as reference source.

Ecosystem coupling is the deeper problem. The bundle is a thin presentation layer over ongr/pager and, in practice, ongr/elasticsearch-bundle. Its core abstractions (AbstractPager, PagerInterface, PagerManager, adapters, Request::createFromGlobals()-style page resolution from the Symfony request stack) assume an ONGR-configured Elasticsearch document manager. Adopting the pager therefore implies adopting the ONGR ES stack — itself archived — to paginate a search backend. That is a large, unmaintained surface area purchased for roughly 200 lines of cursor math.

Integration feasibility: low. Last release 2015-02-24; repository is in ongr-archive, meaning the maintainers have explicitly retired it. Stars (2) and dependents (0) confirm no community to lean on and no third party validating compatibility with any PHP runtime you would deploy today. Expect immediate friction: PHP 5.5/5.6-era code (no return types, no ??, likely each()/create_function or other removed constructs), Symfony 2.x interfaces (ContainerAwareInterface, getRequest() on the container), Twig 1.x template syntax, and composer constraints pinned to ~2.3 Symfony and symfony/symfony meta-package — which composer will refuse to resolve in a modern project without --ignore-platform-reqs hacks.

Technical risk: high, and mostly non-mitigable.

• Security/support: abandoned code receiving no CVE monitoring; a dependency audit will flag it, and any transitive Symfony 2 constraint reintroduces known-vulnerable framework versions.
• Runtime: PHP 8.x incompatibility is likely hard (fatal on removed functions), not a warning you can suppress.
• Licensing: MIT is clean and permissive — the one unambiguous positive, and the only reason this is a "read the source" candidate rather than a hard no.
• Correctness: pagination semantics (offset vs. from/size, deep-page limits, total-hit accuracy) are trivially re-implementable correctly; inheriting decade-old edge-case behavior buys no advantage.

Key questions for the requesting team. (1) Which framework is this actually for — is a Laravel evaluation of a Symfony bundle a scoping error, or was this a "find any pagination library" search? (2) What backend is being paginated: Eloquent/MySQL, or Elasticsearch? If Eloquent, Laravel's LengthAwarePaginator/CursorPaginator already solves this in core. If Elasticsearch, from/size pagination plus search_after for deep pages is a ~50-line wrapper. (3) Is there a hard requirement that motivated finding this package specifically (existing ONGR code, legacy migration)? (4) What is the cost tolerance for carrying an unmaintained dependency through the next framework upgrade?

Verdict: do not integrate. The score of 0.748 is generous relative to a 10-year-dormant, zero-dependent, wrong-framework bundle. Value here is limited to pattern reference — skim AbstractPager for interface shape, then implement natively.

Integration Approach

Stack fit: none. Target stack is Laravel (PHP 8.1+); the package targets Symfony 2.3–2.8 on PHP 5.5+. There is no overlap in service container, config loading, request lifecycle, or templating. No adapter shim makes a Symfony bundle a Laravel package without dragging in symfony/framework-bundle — at which point you have two frameworks in one process and a dependency graph nobody on the team can reason about.

Recommended migration path — treat as greenfield, not port. Two supported destinations:

1. Relational data (most likely case): use Laravel's first-party pagination. Model::paginate() / simplePaginate() for offset paging, cursorPaginate() for large or frequently-mutating result sets. Rendering via Blade's $results->links() (Tailwind or Bootstrap views ship in core). Zero new dependencies, zero licensing review, tests included. This is a same-day implementation and should be the default answer.
2. Search-backed data (Elasticsearch/OpenSearch): if the reason this package surfaced is ES pagination, use the official elasticsearch/elasticsearch PHP client (actively maintained, official) and wrap it in a small paginator service implementing Laravel's LengthAwarePaginator or CursorPaginator contract so Blade views and API resources work unchanged. Keep track_total_hits explicit and cap deep from + size (default 10,000) in favor of search_after + point_in_time for deep traversal.

Compatibility. Neither path inherits any constraint from the bundle. Pin elasticsearch/elasticsearch to the minor version matching your cluster; for Laravel pagination, no pinning is needed. Avoid any transitive ongr/* package — installing ongr/pager alone to "reuse the interface" will pull Symfony 2 constraints and block your framework upgrade.

Sequencing.

1. Confirm the backend and result-set size with the requesting engineer (blocking — determines path 1 vs. 2).
2. Delete this package from consideration; record the decision and rationale in the dependency ADR so it is not re-proposed.
3. Implement path 1 or 2 behind a PaginatorInterface-shaped boundary in your own code so the transport can change later.
4. Add a contract test asserting page-size, page-index bounds, empty-result, and last-page behavior; these are exactly the edge cases the bundle historically covered.
5. Add a CI guard (e.g., composer audit plus a denylist) so archived dependencies fail the build rather than reaching production.

Operational Impact

Maintenance. Carrying this package means owning it: upstream is archived, so every future PHP or framework upgrade becomes your patch. Realistic estimate is 2–5 engineer-days to make it run at all on PHP 8, then recurring cost at each platform bump. Native Laravel pagination or a thin ES wrapper has near-zero marginal maintenance because it tracks the framework's own release cadence.

Support. No vendor, no active maintainers, 0 dependents, 2 stars — there is no one to escalate to and no issue tracker that produces fixes. Internal support means one engineer reverse-engineering 2015 code under incident pressure. Compare against first-party Laravel pagination (framework docs, active community) or the official Elasticsearch client (vendor-backed, versioned support matrix).

Scaling. The bundle's pagination is offset-based (from/size semantics), which degrades on deep pages and produces duplicate/skipped rows under concurrent writes — a correctness issue, not just a latency one. Native cursorPaginate() and ES search_after both address this directly; the bundle does not. On the presentation side there is no meaningful load — the risk is entirely at the data layer and is better solved by the replacement.

Failure modes to expect if integrated anyway. (a) Composer resolution failure on modern Symfony/PHP constraints, usually "solved" with --ignore-platform-reqs, which silently defers breakage to runtime; (b) fatal errors on PHP 8 from removed language constructs; (c) container boot failure from Symfony 2 ContainerAwareInterface usage; (d) silent behavioral drift in page-count math after partial patching; (e) security review block at release because the SBOM contains a decade-EOL framework. Each of these lands late — after the integration work is already spent.

Ramp-up. Near-zero reusable knowledge: no engineer on the team will encounter this stack elsewhere, and time invested learning the ONGR pager abstractions is sunk cost. Ramp-up on the recommended alternatives is effectively zero for Laravel pagination (engineers already know it) and under a day for an ES cursor wrapper. The opportunity cost of the bundle is the deciding factor — it consumes attention and returns a pagination feature that the framework already ships.