Rest Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for thin REST layers — revised, but not reversed: v4.2.1 shows this package is not purely a ceremony wrapper. Correctly paginating and counting across a to-many join is a genuinely non-trivial problem (row fan-out inflates COUNT, and LIMIT on multiplied rows returns short, non-deterministically wrong pages). The fix — COUNT(DISTINCT root.id) plus aggregate-based ordering (MIN asc / MAX desc) grouped by the root identifier — is real engineering, not boilerplate. This informs the build-vs-buy calculus: if the team ever hand-rolls pagination over joined collections, this is the specific class of bug they will ship. Budget for it explicitly, or accept a dependency that has already solved it.
• Roadmap triage: The recommendation stands. GPL-3.0, a single maintainer, low stars and no dependents still disqualify it as a production dependency for a commercial product. What changes is the reason: the risk is no longer "possibly abandoned/experimental" but "credible, competent, and legally/operationally unsuitable." That is a harder rejection to defend internally and should be documented as such.
• Feature prioritization for an internal API toolkit: The release notes are a useful scope document. They articulate three requirements worth adopting as acceptance criteria for any pagination work we do: (1) totals must count entities, not SQL rows; (2) page size must be deterministic regardless of sort column or duplicate position; (3) the solution must add to an existing QueryBuilder rather than rewrite it, so existing queryCallback logic using groupBy/having/distinct keeps working, and query count stays at two. That third criterion is the discriminating one — Doctrine's Paginator fails it, and most in-house implementations fail it silently.
• Use cases where it fits: Unchanged — small internal tools, prototypes, Symfony-only greenfield services, teams already fluent in Symfony bundles and able to accept copyleft obligations. It remains not a Laravel package; surfacing it in a Laravel evaluation is still a taxonomy signal about the discovery pipeline.
• Risk register input: Partially softened. The new release is evidence of active maintenance, with stated coverage across Symfony 6.4 through 8.1 and PHP 8.2/8.4, 452 tests and 100% coverage — a materially better signal than the prior snapshot. Two items remain open: the previously observed future-dated release metadata (2026-08-29) is still unexplained, and a single-maintainer project can be healthy and still be a bus-factor-1 dependency. Keep both on the register; the metadata-quality review of the approved-package pipeline is still warranted.
• Backward-compatibility assessment: The release explicitly scopes its blast radius — sorting on a plain column or across a to-one relation is unchanged; only queries traversing a collection change SQL shape, and those were returning incorrect results before. That is a favorable upgrade profile: no migration work, no changed behaviour for correct call sites. It does not, however, offset the license constraint.

When to Consider This Package

Adopt only if all of the following hold:

• The stack is Symfony, not Laravel. There is no Laravel integration; treating it as a Laravel package is a category error.
• The product can accept GPL-3.0 copyleft — realistically internal-only tooling never distributed to customers, and even then with legal sign-off. For distributed products or any scenario with source-obligation exposure, this is a hard stop regardless of code quality.
• The team explicitly wants a minimal, convention-light REST layer and has rejected API Platform as too heavy.
• There is appetite to vendor or fork the code. The maintenance signal is now stronger (recent substantive release, broad CI matrix, high coverage), but a single maintainer still means bugs are ultimately ours.
• The API genuinely needs paginated, sorted collection endpoints over joined relations. This is now the package's strongest justification and the only one that meaningfully distinguishes it from framework-native alternatives.
• The scope is small in every other dimension: no hypermedia, no versioning strategy, no OpenAPI generation, no content negotiation.

Look elsewhere when:

• You need API Platform-class features: OpenAPI/JSON-LD/Hydra, filtering, validation integration, GraphQL, built-in pagination contracts.
• License hygiene matters (most commercial products): GPL-3.0 remains a hard stop for distributed code and a legal escalation for internal use.
• You cannot absorb bus-factor-1 risk — zero dependents still means near-zero field testing outside this maintainer's own suite.
• Release provenance cannot be verified; the prior future-dated release should be explained before the package is trusted in any pipeline that consumes versions automatically.
• You are on Laravel, where the idiomatic answer is route groups + API Resources + Form Requests, and where the pagination equivalent is Eloquent's distinct/groupBy handling rather than Doctrine aggregates.

How to Pitch It (Stakeholders)

Executives: We re-reviewed gollumsf/rest-bundle following v4.2.1. The new release is a real correctness fix — paginated lists over joined collections were returning wrong totals and short, non-deterministically incomplete pages; the package now counts distinct entities and orders by aggregates so pages are complete. This is competent work with a broad test matrix and 100% stated coverage, and it materially improves our read on the maintainer's capability. Our recommendation is unchanged: do not adopt as a production dependency. GPL-3.0 creates distribution exposure, and a single-maintainer project with no downstream dependents concentrates support risk on us. The cost of adoption is low; the cost of ownership and legal review is not, and the capability it provides is one we can absorb deliberately rather than inherit.

Engineering: The release fixes two coupled defects. Joining a to-many relation multiplies rows, so COUNT over the joined set over-counted (40 authors became 56), and LIMIT applied to multiplied rows returned fewer hydrated entities than requested (limit 5 → 4 entities), non-deterministically depending on duplicate position in the window. The fix uses COUNT(DISTINCT root.id) and orders collection-traversing sorts on an aggregate of the joined column — MIN ascending, MAX descending — grouped by the root identifier, so fan-out disappears. Notably, it deliberately avoids Doctrine's Paginator, which would fix both problems but rewrites the query into subqueries and breaks when a queryCallback has already applied groupBy, having, or distinct; the aggregate approach only adds to the QueryBuilder, keeps existing callbacks working, and holds at two queries. To-one relations and plain-column sorts are untouched, so the upgrade profile is clean.

The engineering takeaway is not "adopt it" — it's "don't underestimate this problem." If we build collection pagination ourselves, we need to solve row fan-out in counting, determinism of page boundaries under join-induced duplicates, and composability with caller-supplied query modifiers, without escalating query count. If we do take the dependency, vendor it and pin it; if we don't, port the pattern, not the code, into an internal MIT/Apache-licensed convention package.

Decision: Reject for production; license and bus-factor remain disqualifying. Use as a read-only reference for pagination design, and adopt its three acceptance criteria — entity-accurate totals, deterministic page size, additive-only query modification — into our own API toolkit requirements. Separately, close out the package-discovery pipeline flag: a GPL Symfony bundle surfaced in a Laravel-oriented evaluation with previously future-dated release metadata still indicates sourcing criteria that need tightening.