Dingo Api Custom Laravel Package

Product Decisions This Supports

• Build vs. buy on the API layer — conclusion unchanged, evidence strengthened. The 3.0.0 release ("Laravel 11 support") is itself the data point: a fork with essentially no user base still had to cut a major version to stay compatible with a framework release. That is the maintenance tax of owning an API abstraction, and it lands on whoever adopts the fork. Keep budgeting for glue work in any Dingo-based estimate.
• Roadmap risk — partially reset, not removed. Laravel 11 support means the "abandoned and incompatible" scenario is off the table for now, so the immediate upgrade blocker for a Dingo service is gone. But this pins the fork to Laravel 11; the same compatibility question returns at Laravel 12. A single release is a data point, not a maintenance cadence — one release after a gap does not establish a support commitment.
• Breaking-change scoping. 3.0.0 is a semver-major bump, which by convention means breaking changes for anyone on 2.x. With no dependents and no community, there is no tested upgrade path and no migration guide worth trusting. If any service is pinned to a 2.x line, the upgrade is unscoped work, not a version bump in composer.json.
• Dependency and governance. The "do not adopt" classification stands. What changes is the reasoning we record: not "archived and dead," but "single-maintainer fork, negligible adoption, no support guarantee, tracks Laravel one major version at a time." That's a more durable rationale and less likely to be overturned by the next release note.
• Migration scoping — now unblocked. The most useful consequence of 3.0.0 is that teams previously stuck on older Laravel because of a Dingo dependency have a supported path to Laravel 11. Treat that as the trigger to schedule the migration to Laravel-native routing + API Resources, with the exit criterion unchanged: no Dingo-specific behavior left in the service.
• Use-case triage. Unchanged. Dingo's remaining legitimate value is versioning and content negotiation for public/partner APIs; internal and single-version APIs rarely need it, and Laravel's native primitives close the rest of the gap.
• Not a decision it supports: selecting this package for new work. One release does not convert a near-zero-adoption fork into a supported dependency, and version 3.0.0 in particular is the hardest moment to adopt — new major, unproven, no community.

When to Consider This Package

Consider it only in a narrow, time-boxed or read-only capacity:

• As a reference implementation. You're on Dingo/Api today, hitting the same friction, and want to see how another team patched it before deciding whether to patch, fork, or migrate.
• As a short-lived stopgap. You're on Laravel 11, mid-migration off Dingo, and need compatibility preserved for a few sprints. Accept it only with an owner, a removal date, and the migration ticket already open — never as a resting state.
• As archaeology. Inherited a Laravel codebase with odd response/versioning behavior and need to identify whether a fork like this is the cause.

Look elsewhere — specifically, don't adopt — when:

• Starting greenfield. Use Laravel's native API routing, Route::apiResource, API Resources, and Sanctum/Passport. Nothing this fork patches is still a framework gap.
• You need support guarantees. One release is not a support policy. No stated security-response process, no issue-triage commitment, no compatibility promise past Laravel 11.
• You need a bus factor. Negligible stars and zero dependents mean zero community validation and no path to an upstream fix that isn't you.
• You're planning past Laravel 11. Version 3.0.0 is scoped to Laravel 11 specifically; adopting it now shifts the compatibility question rather than answering it.
• You're on 2.x today. A major bump with no migration guide and no user base to have shaken out the edge cases is a poor trade against migrating off the fork entirely.
• The real need is response-shape consistency. That's a base controller, a formatter, and an exception handler you own — no third-party abstraction, no version-coupled fork.

How to Pitch It (Stakeholders)

For executives: The package shipped a release adding Laravel 11 support. That removes an immediate compatibility blocker but does not change the recommendation. It remains a small, single-maintainer customization layer for a PHP API library that Laravel now covers natively, with effectively no user base. The release confirms rather than resolves the core concern: every Laravel upgrade requires someone to re-cut this fork. We are not adopting it, and one release does not constitute vendor support.

For engineering leadership: The policy stands — Dingo/Api "no new adoption," this fork "do not use." Update the recorded rationale from "archived" to "single-maintainer, negligible adoption, tracks Laravel one major version at a time," which is defensible against future release notes. Two actions now become easier: (1) the Laravel 11 compatibility path is clear for services blocked on Dingo, so schedule their migration to native routing and API Resources rather than deferring it; (2) any service pinned to 2.x needs an explicit decision — migrate off the fork, don't plan a 3.x upgrade, since the major bump is unscoped work with no community-tested path. Keep the inventory of Dingo-dependent services and size migration per service against the behaviors it actually relies on.

For engineering teams: A new major version is not a revival. 3.0.0 means breaking changes, no migration guide, and no user base to have found the edge cases — and it still only promises Laravel 11. If Dingo is fighting you, the answer remains migration, not adoption or a 3.x upgrade. Use the repo as a reference for patterns if useful, but build on framework primitives so the next Laravel upgrade is routine rather than a fork-maintenance project.