Utils.common.paginable Interface Laravel Package

Product Decisions This Supports

• Build vs. buy vs. copy: This is effectively a one-method contract (paginate($limit, $offset)). The decision it informs is not "should we adopt" but "should we spec our own." Copying the concept into an internal interface costs minutes; adding a dependency costs a supply-chain slot forever.
• Standardizing a pagination contract: If the roadmap includes a shared repository / data-grid / API listing abstraction across services or packages, this package is useful prior art for defining the boundary between "data source" and "consumer" without prescribing storage or transport.
• Scoping pagination as a feature: The interface intentionally caps scope at offset+limit — no total counts, no cursor semantics, no page numbers. That's a legitimate MVP decision, but it forces an explicit roadmap call on whether the product needs total, hasMore, stable ordering under inserts, or deep-page performance.
• Dependency and lifecycle policy validation: 1 star, 0 dependents, last release 2017-05-17, tied to the Mouf / TheCodingMachine ecosystem. Use this as a calibration case for your "minimum viable dependency" checklist — an abandoned package with zero downstream usage should not clear the bar.
• Risk posture: MIT license means the legal risk of vendoring or re-implementing is nil; the only real risk is coupling to an unmaintained PHP-5/7-era namespace.

When to Consider This Package

Consider it only if:

• You are already inside the Mouf / TheCodingMachine stack and need to interoperate with an existing contract you don't control.
• You maintain a PHP 5.x/7.x codebase with packages that already type-hint this interface.
• You need a shared marker interface across independently versioned packages where even a small shared dependency is preferable to duplicated definitions.

Look elsewhere (the common case) in essentially every other scenario:

• Greenfield PHP 8 / Laravel work — Laravel ships LengthAwarePaginator, CursorPaginator, and paginate()/simplePaginate() on the query builder and Eloquent. Using them gives you counts, cursor support, serialization, and Blade/API integration for free.
• You need totals, cursors, sorting, or filtering — this contract expresses none of that, and retrofitting it means breaking every implementer.
• You require maintenance, security patching, or framework-version compatibility. Nothing here has moved since 2017.
• Default recommendation: define a two-line internal interface (or use Laravel's) rather than pull a dependency for a method signature.

How to Pitch It (Stakeholders)

For executives (one line): This is not a product or a library with features — it is a single-interface contract with one GitHub star, zero dependents, and no release since 2017. We should not adopt it; if pagination consistency matters to the roadmap, we define that contract ourselves in under an hour and own it.

For engineering: The package is a PaginableInterface exposing paginate(limit, offset). MIT-licensed, so we can vendor the idea freely. Adopting it adds an unmaintained dependency and a Mouf-ecosystem namespace for a signature we can write ourselves; it also locks us into offset-only pagination, which won't survive contact with totals, cursor pagination, or large-offset performance. Recommend: use Laravel's paginator contracts where the framework applies, and an internal interface where it doesn't.

Trade-off summary: Cost of adoption ≈ cost of imitation, but adoption carries permanent maintenance and coupling risk for zero incremental capability. The decision is "no," and the useful output of this evaluation is the pagination contract spec we write ourselves.