Json Request Bundle Laravel Package

Product Decisions This Supports

Primary decision: build vs. buy for JSON request handling — unchanged by v1.0.0. This package sits in the "JSON payload → validated, typed request object" slot, between an inbound API call and domain code. The v1.0.0 release does not resolve the buy/build question in the package's favor; if anything it sharpens the answer.

• Vendor/roadmap decision: do not plan on it. The new release is a re-tag, not a resumption of maintenance. Its entire content is a rebase onto the original SymfonyBundles/JsonRequest bundle at commit fa0e3d2. There is no feature work, no dependency refresh, no stated framework-compatibility matrix, and no maintained backlog. Treat it as unavailable for roadmap planning.
• What v1.0.0 actually tells us: a major version number with no migration notes is a red flag, not a milestone. For a 2020-era package, 1.0.0 implies namespace/structural breaks with zero upgrade path documented, and it re-bases the code onto a second unmaintained upstream. A dependency whose provenance is now split across two dormant repositories is harder to own, not easier.
• Framework fit is now a product risk, not just a version pin. The upstream is a Symfony bundle, not a Laravel package. There is no evidence in the release of a Laravel service provider, config surface, or middleware integration. Adopting it means betting that a Symfony-bundle port behaves like a Laravel-first package — that bet is unpriced and unnecessary.
• Feature scoping: use it as a requirements checklist, not a component. The package's scope (request parsing, validation binding, DTO hydration) remains a useful strawman for writing acceptance criteria for a new API. One afternoon of reading, zero lines of dependency.
• Build vs. buy, resolved: build in-house (thin) or adopt a maintained alternative. JSON request → validated DTO is a small, well-understood effort with no external maintenance surface. That cost is lower than owning an abandoned, twice-removed port.
• Tech-debt decisions it informs: if this package is already present in a codebase, v1.0.0 is a remediation prompt, not a keep signal. A major bump on an archived package is the moment to schedule removal, not upgrade.
• Not a differentiator. No ecosystem validation — it cannot be cited as "industry standard" in an architecture review, and will not reduce hiring/onboarding friction.

When to Consider This Package

Adoption criteria — this package still fails all of the non-negotiable ones:

When to consider it at all: only as reference material — reading the source to sanity-check your own design for request validation and DTO mapping. Non-production, non-installed, no Composer entry.

When to look elsewhere (i.e., essentially always):

• Any production system, including internal tools — archived dependencies become CVE-orphans the moment transitive deps move.
• Any greenfield API on a current Laravel version — an unversioned Symfony-bundle port is a coin flip on whether it installs at all.
• Any team without a dedicated owner — forking a 2020 package ported from a dormant Symfony bundle is a worse trade than writing the ~200 lines yourself.
• Preferred alternatives to evaluate instead: first-party Laravel FormRequest + expectsJson() for validation; a maintained DTO package (e.g. spatie/laravel-data) for typed hydration; or a thin in-house request-object base class. Run this same criteria table against those before committing.

Decision rule going forward: archived, single-maintainer, or sub-10-dependent packages are auto-reject for production dependencies unless a named internal owner and a written fork strategy exist. Refinement from this release: a version bump with no changelog is not evidence of maintenance. Judge packages on commit activity and support responsiveness, not on tag recency. This package is the clean example to socialize that rule.

How to Pitch It (Stakeholders)

For executives (30 seconds): A third-party PHP package we evaluated for handling JSON API requests published a new "1.0.0" release. On inspection it contains no new features — it simply re-imports code from an older, also-abandoned package. The dependency is still unmaintained, still has no users in the ecosystem, and still receives no security patches. Recommendation: do not adopt; remove it if it is already in the codebase. We can cover the same need with a small internal component or a maintained alternative — days of effort, not weeks — and keep an unpatched dependency out of our attack surface.

For engineering leads: v1.0.0 is a single-commit rebase onto SymfonyBundles/JsonRequest@fa0e3d2 — no changelog, no migration notes, no compatibility matrix, no dependency refresh. It introduces a breaking major version on an unmaintained package, which is worse for us than no release at all: it invites an "upgrade" that buys us nothing. Also verify upstream license/attribution before lifting any code. If currently installed, keep the removal ticket and expect Composer conflicts on Laravel 10+. Replacement path: FormRequest for validation plus a maintained DTO package or a thin internal request-object class.

Bottom line: high-confidence reject, unchanged. A release is not a revival; the maintenance and support risk is the same as before, now with an unadvertised breaking change on top.