Pagination Bundle Laravel Package

Technical Evaluation

Architecture fit. This is not a Laravel package. It is a Symfony bundle: installation requires registering Everlution\PaginationBundle\EverlutionPaginationBundle() in app/AppKernel.php, configuration is loaded via Symfony's YAML bundle config (everlution_pagination), and the primary developer surface is a Twig function (sortable_header()). Its data layer is Doctrine — the README explicitly states it is "based on Doctrine Paginator (for now)." Laravel's pagination is built on the Illuminate\Pagination contracts over Eloquent/Query Builder. There is no overlap in container, templating, or ORM abstraction, so the architectural fit for a Laravel codebase is effectively zero without a port.

Integration feasibility. As a drop-in: not feasible. Composer will resolve it, but the bundle will never boot in Laravel — no service provider, no facade, no Blade directive, no Eloquent integration. The only viable integration is as a reference implementation: the sorting-header UX pattern and the page-size bounding model (default_page_size, max_page_size) are the genuinely reusable ideas, and both are trivially reproduced with Laravel's LengthAwarePaginator, appends(), and a Blade component.

Technical risk. High, concentrated in abandonment. Last release 2017-07-04, zero stars, zero dependents, no community. That date places it in the PHP 5.6/Symfony 2.8–3.x era, so its composer.json constraints will almost certainly conflict with PHP 8.1+ and Symfony 5/6, and it depends transitively on doctrine/orm versions that are themselves EOL. There are no indicated tests, so any port would be validated entirely by us. The sorting feature also accepts a query-string parameter mapped to a column identifier — that is a SQL-injection-adjacent surface unless the original implementation maintains a strict allowlist, which the README does not evidence.

Key questions.

• What is the actual driver here — a specific sorting-header UX the team liked, or a mandate to evaluate this package? If the former, we should not adopt the dependency at all.
• Does our target stack use Doctrine at all, or is it Eloquent? If Eloquent, the Doctrine Paginator dependency is a non-starter.
• Is there an internal owner willing to fork and maintain, or is this strictly a pattern to copy?
• How does the sort parameter get sanitized in the original code? We need to read the source before borrowing the approach.
• What is the target Laravel and PHP version, and has anyone actually attempted composer require against it to confirm the conflict?

Recommendation: do not adopt. Treat as a design reference only. The opportunity score of 1.14 and overall score of 2.47 are consistent with this read.

Integration Approach

Stack fit. Poor across every layer. Container: Symfony DI compiler passes vs. Laravel's service container. Templating: Twig function vs. Blade. Persistence: Doctrine Paginator vs. Illuminate\Pagination\LengthAwarePaginator. Translation: Symfony translator for header labels vs. Laravel's __(). Four independent mismatches means there is no partial-adoption story — it is all-or-nothing, and "all" means Symfony.

Migration path. The realistic path is a clean-room reimplementation in Laravel, scoped at roughly one to two days:

1. Replace the Doctrine paginator call with Model::query()->paginate($perPage) and enforce max_page_size via a config value, mirroring the README's bounding intent.
2. Replace the sortable_header(label, column) Twig helper with a Blade component or a @sortableHeader directive that emits a link carrying sort and direction query params, preserving existing filters via ->appends(request()->query()).
3. Reimplement the label translation using __() so the auto-translate behavior is retained.
4. Implement a strict column allowlist per resource — this is where we improve on the original rather than replicate it.
5. Add feature tests covering page bounds, invalid sort keys, and filter preservation.

Compatibility. Assume incompatible until proven otherwise. Verify with a throwaway branch: composer require everlutionsk/pagination-bundle on the target PHP/Laravel version and read the resolver output. Expect conflicts on php, symfony/*, and doctrine/orm. Even if it resolves, booting it requires an AppKernel, which Laravel does not have — so a clean resolution would still not yield a working integration.

Sequencing.

1. Spike (half day): confirm the Composer conflict and document it. This closes the "should we just install it?" question definitively.
2. Source review (half day): read the sort-parameter handling and the page-size bounding logic; extract anything worth keeping.
3. Build (1–2 days): native Laravel implementation with allowlisting and tests.
4. Rollout behind a feature flag on one list view before standardizing.

Do not sequence any work that assumes the bundle itself ships to production.

Operational Impact

Maintenance. This is the decisive factor. The package is unmaintained since mid-2017 with no dependents and no visible contributor base — there is no upstream to receive security patches from. Adopting it means we inherit the maintenance burden for code we did not write, in a framework idiom (Symfony bundles) that our team does not work in. That is a permanent tax for a feature Laravel ships in core. The reimplementation, by contrast, is a few dozen lines we fully own and can test.

Support. None. No active maintainers, no issue triage, no community to escalate to. Internal escalation would fall to whoever volunteered to fork it, creating a single-point-of-knowledge risk.

Scaling. Pagination is not itself a scaling concern, but two details matter. First, Doctrine's Paginator issues a separate COUNT query per page request, which mirrors what Laravel does — acceptable, but on large tables with complex filters it needs an index review before we rely on it. Second, the sorting feature renders per-column links, so a table with many columns multiplies the template work; negligible at our scale but worth noting.

Failure modes. Ranked by likelihood:

• Container boot failure — bundle never registers in Laravel; surfaces immediately and is a hard stop.
• Composer resolution failure — blocks install; expected and easily confirmed.
• Unvalidated sort parameter — if the column name from the query string reaches the query builder without an allowlist, this is an injection or error-oracle vector. Highest-severity risk if any code is borrowed verbatim.
• Page-size abuse — mitigated by max_page_size in config, but only if the cap is enforced server-side rather than trusted from the request.
• Template not found — sortable_header_template points at an app-level Twig file; a missing path yields a rendering exception mid-list-view.
• Silent behavioral drift — no tests upstream means no regression signal if anyone ever patches a fork.

Ramp-up. Non-trivial and misdirected. Getting productive with this bundle requires Symfony bundle conventions, Doctrine's paginator semantics, and Twig — none of which are transferable to the team's actual Laravel work. The native alternative requires only knowledge the team already has. Ramp-up cost is therefore best modeled as waste rather than investment.

Net. The only durable value here is two design ideas: bounded page sizes and a translated, query-string-driven sortable table header. Both are cheap to reproduce idiomatically in Laravel and expensive to inherit as a 2017 Symfony dependency. Recommend closing this evaluation with a "reference only" disposition and a short native implementation ticket.