Doctrine Pagination Bundle Laravel Package

Product Decisions This Supports

• Feature scoping for admin/reporting surfaces. The package addresses exactly one narrow need: server-side pagination over Doctrine ORM queries (typically hand-written DQL) in a Symfony application. It is relevant only if such screens are on the roadmap.
• Build vs. buy — this one lands firmly on "build" or "use something maintained." With 0 stars, 0 dependents, a single author, and a last release of December 2022, there is effectively no external validation. The functional surface (wrapping Doctrine\ORM\Tools\Pagination\Paginator in a service/controller helper) is a few hundred lines at most. The replacement cost is measured in hours, which makes any dependency-management or upgrade cost hard to justify.
• Naming/fit check as a gating decision. The name ends in -bundle, which is Symfony terminology; Laravel ships packages with service providers, and its default ORM is Eloquent, which already provides paginate() and cursorPaginate(). This is a fit problem, not a quality problem — it should be screened out early in any Laravel evaluation.
• Roadmap signal: at most a reference implementation for a spike — a pattern to read when designing your own paginator wrapper. Not a strategic or platform dependency.
• Primary legitimate use case: internal Symfony + Doctrine admin tooling over a small, stable set of DQL queries, where a team is comfortable forking and owning the code.

When to Consider This Package

Adopt only if all of the following hold:

• You are on Symfony with Doctrine ORM — not Laravel/Eloquent.
• You have a handful of complex DQL queries where offset/limit pagination needs a total count, and you want a thin wrapper rather than a full abstraction.
• You are willing to fork and vendor it: no releases since 2022, no dependents, no community, and no stated compatibility matrix for current Symfony/PHP versions. Treat it as source code you adopt, not a library you depend on.
• Your security/procurement process tolerates a single-maintainer, zero-adoption MIT dependency (or you vendor the code to sidestep that entirely).

Look elsewhere if:

• You're on Laravel. Use Eloquent's built-in pagination — it is maintained, documented, and covers both offset and cursor pagination.
• You need cursor/keyset pagination for large or fast-changing datasets; offset pagination with COUNT(*) degrades badly at scale.
• You need a maintained dependency. Prefer Doctrine's own Paginator or Pagerfanta, both of which have real user bases and active maintenance.
• You need SLAs, security patching, or upgrade guarantees. A package dormant since 2022 provides none.

How to Pitch It (Stakeholders)

To executives (recommendation: do not adopt): This is a small, single-purpose utility for paginating database queries, published by one author with no community around it and no updates since December 2022. It has zero known users. The capability it provides is small enough that our engineers can implement it in hours, and owning a dormant third-party dependency creates ongoing upgrade and security-review overhead that exceeds the value delivered. Recommendation: skip it; the equivalent functionality is either built into our stack or trivially built in-house.

To engineering (technical summary): javihgil/doctrine-pagination-bundle is a Symfony bundle wrapping Doctrine ORM's Paginator for paginated DQL. It is not a Laravel package — Laravel's Eloquent already provides paginate()/cursorPaginate(), and Doctrine in Laravel would be an unusual, self-imposed integration burden. Signals: 0 stars, 0 dependents, last release 2022-12-20, no compatibility statement for current Symfony/PHP. If we're on Symfony + Doctrine and need this, read it as a reference and implement internally, or use Doctrine's Paginator/Pagerfanta directly. Do not add it to a Laravel codebase. Estimated effort to replicate the useful behavior: under a day.