Api Bundle Laravel Package

Product Decisions This Supports

• Framework-fit decision. This is a Symfony bundle (ApiBundle), not a Laravel package. Evaluating it forces the real question: do we spend engineering time building a compatibility layer for a third-party Symfony abstraction, or do we use what Laravel already ships? The answer is the latter, and that decision should be recorded so it isn't re-litigated. The 0.5.1 patch does not touch this constraint — it is Symfony HTTP-kernel plumbing.
• Build vs. buy for API scaffolding. The package's scope ("API stuff for most Happyr projects") overlaps with capabilities Laravel provides natively: Eloquent API Resources for serialization, Form Requests for validation, Sanctum/Passport for auth, throttle middleware for rate limiting, and the exception handler for error envelopes. The 0.5.1 change — mapping AccessDeniedHttpException to a 403 Forbidden — is precisely the kind of thing Laravel's exception handler already does out of the box. The decision remains build on native primitives, not adopt.
• Dependency-risk calibration. 1 star, 0 dependents, single-organization ownership, ~7 years dormant between the 2018-10-10 release and 0.5.1. A lone patch release after that gap is a maintenance blip, not a maintenance signal: no version-support statement, no dependency or PHP-version bump, no new downstream consumers, no CI/security posture announcement. Keep this as the worked "reject" anchor on our package-review rubric and a check that our scoring is behaving (0.165 remains directionally right).
• Behavior semantics worth noting (and not adopting for). Returning 403 on access-denied is correct HTTP behavior, but it was already the default expectation in Laravel's handler. If anything, the patch confirms the package is still chasing baseline framework behavior rather than offering differentiated value.
• Roadmap hygiene. No feature or epic should be scheduled on top of this. If any inherited Happyr-derived code relies on similar conventions, the line item is migration, not fork and extend. The 0.5.1 release gives us no reason to revise that line item.
• Procurement/legal. MIT is permissive and presents no licensing obstacle. The blocker remains abandonment and framework mismatch, not law — worth separating explicitly in review docs.

When to Consider This Package

Adoption criteria (all must hold):

• You are running Symfony 3.x/4.x-era code, not Laravel.
• You are rebuilding a Happyr-internal service that already depended on these conventions.
• You have a named maintainer prepared to fork, own, and patch it.
• You can pin to a 2018-era codebase and accept that one 0.5.1 patch does not imply a support commitment, PHP 8.x compatibility, or a security-patch stream.

Look elsewhere when:

• You are on Laravel — the framework mismatch alone disqualifies it, and that is unchanged by 0.5.1.
• The API is greenfield or customer-facing.
• You need PHP 8.x support, security patching, or any support expectation.
• The team has no spare capacity to own a fork indefinitely.
• Your only requirement is "return 403 on access-denied" — every mainstream framework, including Laravel, already does this.

Alternatives to evaluate instead: Laravel API Resources + Sanctum + Form Requests + throttle middleware + the native exception handler for our stack; API Platform or FOSRestBundle if a Symfony surface ever appears; or a thin in-house layer, which is likely smaller than the adapter this package would require.

How to Pitch It (Stakeholders)

Recommendation: do not adopt. Unchanged by the 0.5.1 release. happyr/api-bundle is an internal Symfony convenience bundle with 1 GitHub star and 0 dependents. Two independent problems persist: it targets the wrong framework for our Laravel stack, and it has been effectively unmaintained for roughly seven years. The MIT license is clean, so legal is not the constraint — operational risk is.

What 0.5.1 changes: one patch that returns a 403 Forbidden when an AccessDeniedHttpException is thrown. That is a reasonable fix, but it is baseline behavior our framework already provides, and a single dormant patch does not constitute a support commitment, a dependency refresh, or a PHP 8.x readiness signal. We should not read a maintenance revival into it.

Cost of declining: effectively zero. Nothing depends on this package, and the capabilities it gestures at are already first-class in Laravel. Cost of adopting: an adapter layer, a permanent maintenance obligation, and an unpatched dependency in our API surface.

Action: close the evaluation, standardize on framework-native API tooling, log 0.5.1 as a data point that did not change the decision, and keep this package as the worked example in our dependency scorecard for what a reject looks like.