mattjanssen/api-response-bundle
A PHP bundle for building consistent API responses, with helpers for standardized success and error payloads so your application returns clean, predictable JSON across endpoints.
Architecture fit — still poor, and the release does not touch the blocking layer. The v1.0.0 diff is dependency metadata only: no source files, no event-listener changes, no API changes. mattjanssen/api-response-bundle remains a Symfony bundle whose entire mechanism is hooking kernel.view and kernel.exception. Laravel dispatches neither. The nearest Laravel analogs — Responsable, HTTP middleware, Handler::renderable() — still have to be written by us. The release changes what Composer will resolve; it does not change what the code does, and what it does is still framework-incompatible.
Integration feasibility — still low, for a different and more precise reason. The previous assessment's hard stop was "Symfony 3.4/4.x constraints won't resolve against Laravel's Symfony 6/7 pins." That specific stop is now softened: symfony/symfony accepts ^5, and sensio/framework-extra-bundle accepts ^5. But three new facts replace it:
"php": "^5.4|^7". There is no PHP 8 support declared — not 8.0, not 8.2. Every supported Laravel (9/10/11) requires PHP 8.0+. This alone is a hard stop, and it is now the primary one. It also means Symfony 5's own floor (PHP 7.2.5) is the practical target, i.e. PHP 7.4.symfony/symfony meta-package is a whole-app pin. It replaces every individual Symfony component at its own version. Requiring it alongside a Laravel that pins symfony/http-kernel ^6.x is an unsatisfiable conflict — you cannot take Symfony 5 for this package and Symfony 6 for the framework. Adopting it means pinning the entire application's Symfony components to 5.x. This is a new, sharper articulation of why "install as-is" fails, and it survives any future PHP 8 bump.kernel.view — and Laravel 8 and PHP 7.4 are both out of security support. Do not let this window be mistaken for viability in review.Technical risk — high, and the release adds a dependency-lifecycle risk it did not previously have. The v1.0.0 tag is a semver milestone, but the diff shows a maintainer widening constraints without visible code changes. Two readings, both concerning: either the code was already compatible and untested (so Symfony 5 support is asserted, not demonstrated), or it is not compatible and the constraint is aspirational. The require-dev additions — symfony/phpunit-bridge, mockery ^1, phpoption/phpoption — suggest CI was modernized, which is a mild positive signal, but we have no evidence the suite actually runs on PHP 7.4/Symfony 5. Separately, sensio/framework-extra-bundle is deprecated upstream; accepting ^5 of it adds a transitive liability to an already-dormant tree. And jms/serializer-bundle ^3 widens the serialization surface, which is the layer most likely to interact badly with PHP minor-version drift. Zero dependents remains unchanged and remains the most informative metric.
Key questions for the maintainer / spike (revised):
"php": "^5.4|^7" intentional, or an oversight left by the constraint bump? Will PHP 8 be declared?phpunit-bridge addition implies yes — ask for the build link.symfony/symfony be narrowed to individual components (http-kernel, http-foundation)? Without that, the meta-package conflict is permanent regardless of PHP version.sensio/framework-extra-bundle ^5 introduce controller-annotation parsing into the transform path? That is the piece most likely to break and least likely to be documented.jms/serializer-bundle ^3 widening change serialization output (key ordering, null handling) versus ^1? A silent envelope change is a client-breaking change.Stack fit — unchanged in the conclusion, changed in the reasoning. Against Laravel 10/11 on PHP 8.2: incompatible, now on the PHP constraint rather than only the Symfony constraint. Against Laravel 8 on PHP 7.4: possibly resolvable, architecturally non-functional, and on unsupported runtime. Neither is a fit. The v1.0.0 release moves the blocker; it does not remove it.
Migration path. No change to the recommendation — plan past this package, not to it:
^5 bump slightly improves the fork's starting point (modern PHPUnit, Mockery 1) but the fork remains 100% ours with no rebase target worth tracking, since upstream ships roughly once per five years.Compatibility verdict. Downgrade the previous "treat as incompatible pending spike" to "incompatible — PHP 8 not declared, and the meta-package pin is structurally fatal." The spike's purpose has narrowed: it is no longer "will it install?" (we can answer that from the constraint diff: no, on any current Laravel) but "did upstream actually validate Symfony 5?" That is a maintainer question, not an engineering spike.
Sequencing. The 1-day Composer spike is now optional and lower value — the diff answers the resolution question well enough to skip it for Laravel 10/11. If leadership wants a formal close-out, redirect that day into Option B's skeleton instead: JsonApiResponse implements Responsable, a Handler::renderable() exception map, and one contract test. Sequence ahead of any API-surface work so controllers are written against the final envelope from day one. Do not open a work item to track upstream's PHP 8 support; note it and move on.
Maintenance — unchanged, with a new caveat. One maintainer, zero dependents, no security-response channel, first release in ~5 years. The v1.0.0 tag is a metadata event, not evidence of cadence; the correct read is "one commit after half a decade," not "actively maintained." The new caveat: constraint widening without corresponding source or test evidence is a classic dormancy pattern — enough motion to look alive, not enough to rely on. Any CVE in the transitive tree (PSR-7, willdurand/negotiation, sensio/framework-extra-bundle, annotation parsing) remains ours to remediate by forking.
Support. Effectively zero, unchanged. 7 stars, no issue-triage cadence, no Stack Overflow corpus. The v1.0.0 release does not create a community; it creates one more version to reconcile against a fork that already diverged.
Scaling. Unchanged — the transform layer is thin and not a throughput concern. The real risks are transformer-induced N+1 queries on list endpoints and payload size from verbose JSON:API envelopes (data/relationships/included) against mobile clients. Mitigate with an eager-loading requirement in the transformer contract and query-count assertions in CI.
Failure modes to design against:
^5 constraint may not reflect tested reality. Anyone treating "supports Symfony 5" as a settled fact in a design doc is propagating an unverified claim.symfony/symfony is required, every future framework upgrade becomes a joint upgrade with a dormant dependency. This is the failure mode most likely to cost real time, and it is invisible at install time.Accept handling may mishandle vendor media types and q-values; JSON:API 1.1 output is unverified.Ramp-up. Conceptual ramp-up stays low — the pattern is standard and graspable in an afternoon. What costs time is the undocumented portion, and that is unchanged: whoever forks or ports becomes sole authority. Assign a named owner, write the transformer contract as a short ADR, and land contract tests before the first consumer ships.
Bottom line for the decision record: v1.0.0 is a dependency-constraint bump and a version tag, not a capability change. It removes none of the architectural blockers, leaves PHP 8 unsupported, and introduces whole-application Symfony pinning via the meta-package. Recommend do not adopt; fund Option B as a small internal library, or Option C if JSON:API compliance is a hard requirement. Prior score of 0.155 stands, with the primary blocker restated as the PHP constraint rather than version drift.
How can I help you explore Laravel packages today?