Weave Code
Easy Pagination Laravel Package
eonx-com/easy-pagination
Easy Pagination is a lightweight Laravel/PHP package that simplifies paginating query results and collections. It offers a clean, consistent API for building paginators, controlling page sizes, and integrating with Eloquent and the query builder, making reliable pagination easy to add to APIs and vi...
Provides a generic way to handle pagination data from clients
Frequently asked questions about Easy Pagination
- What does eonx-com/easy-pagination actually do?
- It is a lightweight pagination input utility, not a paginator. It parses request-driven page and per_page values plus defaults into a transport-agnostic value object, leaving query execution and response shaping to your application. That makes it a clean seam beneath Eloquent, Doctrine, or raw PDO. It is a poor fit if your controllers already standardize on Laravel's native paginate().
- How do I install eonx-com/easy-pagination in a Laravel project?
- Install it with Composer: composer require eonx-com/easy-pagination. It is MIT-licensed and part of the EonX easy-* family, so it should drop into a standard PHP 8.1+ Laravel service. Because the repository is a read-only subtree split, pin an exact version rather than a caret range and commit your lockfile. Then spend a short spike reading src/ and tests/ before wiring it into an endpoint.
- Does Easy Pagination replace Laravel's paginate() and LengthAwarePaginator?
- No. The package only handles the input side of pagination: parsing page and per_page values into a value object. Laravel's LengthAwarePaginator still executes the query and builds the response payload. Using both across an app means maintaining two pagination vocabularies, so pick one convention per endpoint rather than mixing them.
- Is eonx-com/easy-pagination framework-agnostic or does it depend on Illuminate?
- The overview describes it as transport-agnostic, but you should verify the actual composer.json constraints before committing. Check whether it requires illuminate/http or illuminate/support, since that framework coupling determines whether a Laravel bump could break it. If the surface really is one or two value objects plus a parser, it should be genuinely portable to non-Laravel PHP.
- Does Easy Pagination validate page and per_page input from clients?
- That is the key question to settle during your spike, because untrusted client input must be bounded. Read the source and tests to confirm whether it clamps per_page to a maximum, rejects negative pages, and falls back to a default for non-numeric values. If it turns out to be a pure DTO that trusts its caller, add validation at the HTTP boundary yourself before the object reaches your repository layer.
- Which PHP and Laravel versions does Easy Pagination support?
- Check the declared constraints in composer.json against your runtime and Laravel minor version first, since anything below PHP 8.1 is a non-starter. Because the GitHub repository is a READ-ONLY subtree split from a vendored monorepo, released tags may lag the parent project. Confirm last commit and tag dates in both repositories before assuming the constraints are current.
- How do I use Easy Pagination with Eloquent or the query builder?
- Parse the incoming request into the package's pagination object at the HTTP boundary, then pass that object inward to your query or repository layer. Your repository reads page and per_page off the object and applies them to the Eloquent builder, while the package stays out of the query itself. If you use it consistently, one canonical pagination representation can serve every endpoint.
- Does Easy Pagination require a service provider or a config file?
- The package surface appears to be pure PHP value objects and a parser rather than a Laravel service provider with configuration. Confirm this by checking src/ and any composer.json extra.laravel providers entry after install. If it is pure PHP, you can instantiate it directly without registering anything in your application bootstrap.
- Is eonx-com/easy-pagination actively maintained?
- It is a single-vendor easy-* package with very low adoption (roughly 2 stars and 0 dependents), and the repository carries a READ-ONLY split marker pointing at an upstream monorepo. Runtime risk is negligible since there is no I/O and no state, but lifecycle risk is real: if the upstream goes quiet, nobody owns fixes for a PHP or Laravel upgrade. Audit transitive easy-* siblings with composer why eonx-com/easy-pagination so vendor risk does not multiply.
- How do I adopt Easy Pagination safely and keep an exit plan?
- Introduce it behind a small internal interface, such as a PaginationParamsFactory, instead of importing the vendor class across the codebase. That wrapper is your exit plan: if the package is abandoned, you swap the implementation and call sites stay untouched. Migrate endpoint by endpoint as you touch each one rather than doing a big-bang rewrite, and pin an exact version with a committed lockfile. Keep the decision gate strict: adopt only if the package enforces sane bounds on page and per_page.
Weaver
How can I help you explore Laravel packages today?