Data Dog Pager Bundle Laravel Package

Product Decisions This Supports

• List/table UX patterns: The bundle's core value proposition — paginate a Doctrine query while layering user-facing filters and sorters — maps directly to the highest-traffic screens in most B2B products (admin panels, search results, reporting tables, audit logs). It's a useful reference for defining the product contract: which fields are filterable, which are sortable, how page size and page number are exposed in URLs and API responses.
• Query-parameter design: Filters and sorters imply a public interface (?page=2&sort=-created_at&status=active). That's a product decision worth locking down early, because it becomes an external API contract and a bookmarking/sharing behavior your users will depend on.
• Build vs. buy for admin tooling: The package frames a decision PMs actually make — hand-roll pagination/filter plumbing per resource, or standardize on one library so every admin screen behaves identically (consistent sort arrows, empty states, page-size selectors).
• Scope of a "search" feature: If the roadmap says "add filtering to the orders list," this kind of package defines the boundary between table-stakes (page + sort + simple equality filters) and a real search product (full-text, faceted counts, saved views) that needs its own investment.
• Not a roadmap driver on its own: With zero stars, zero dependents, and a Symfony2-era scope, this is not evidence of a market need or a community-vetted solution. It cannot anchor a build-vs-buy recommendation.

When to Consider This Package

Consider it only in narrow, mostly historical cases:

• You maintain a legacy Symfony 2.x + Doctrine ORM application and already depend on this bundle; treat it as a frozen implementation detail, not something to extend.
• You want a reference implementation for how to structure paginator + filter + sorter abstractions in PHP, and you're reading it, not installing it.
• Your team explicitly runs Doctrine ORM inside Laravel (via laravel-doctrine) and has rejected the native paginator — a rare and usually regrettable configuration.

Look elsewhere in virtually every other case:

• This is not a Laravel package. Laravel's Eloquent ships paginate() / cursorPaginate() with query-string preservation, and simplePaginate() for large offsets. The problem this bundle solves is already solved natively.
• Stability risk: 0 stars, 0 dependents, and a score of 0 mean no downstream validation. There is no signal that anyone has run this in production, no community to answer questions, and no realistic expectation of security patches.
• Symfony 2 is end-of-life (Nov 2015, with security support long expired). Dependencies from that era typically pin PHP and Doctrine versions that conflict with modern stacks, forcing you into dependency-resolution surgery.
• Filters and sorters are commodity scope. Prefer spatie/laravel-query-builder for filter/sort/include conventions, or an admin framework (Filament, Nova, Livewire tables) that owns pagination UX end-to-end.
• No maintenance contract: Without a maintainer, an adopter inherits 100% of the bug-fix and upgrade burden — effectively a fork, which is a permanent team cost disguised as a free dependency.

How to Pitch It (Stakeholders)

For executives: This is not a dependency we should adopt. It's a Symfony 2 pagination library with no measurable adoption — zero stars, zero downstream dependents, an unmaintained codebase, and a framework generation that reached end-of-life in 2015. For a Laravel product, the capability it provides — paginated, filtered, sortable lists — is already built into the framework at no cost and with full support. Bringing this in would convert a solved problem into an ongoing maintenance liability without accelerating any roadmap item.

For engineering: Treat it as a design reference rather than a candidate. Review its filter/sorter abstraction if we're standardizing list endpoints, then implement on cursorPaginate()/paginate() plus spatie/laravel-query-builder so the filter and sort whitelist lives in one place per model. If anyone has a legacy Symfony 2 service still on this bundle, that's an argument for migration, not adoption.

Bottom line: No adoption recommendation. The only actionable insight is the interface pattern: lock down page, page-size, sort, and filter parameters as a shared contract across list endpoints — and buy that capability from the framework we already pay for.