Request Bundle Laravel Package

Technical Evaluation

Architecture fit — the stack question is now closed, and it closes against adoption. Release 0.3.3 confirms the original read: this is a Symfony bundle, not a Laravel package. The brief's framing should be corrected in the record. More importantly, the release sets the platform floor at Symfony 7.2 and above, exclusively ("7.2 and higher only"). That single constraint removes the only scenario in the prior assessment that had a genuine gap to fill.

Restating the decision tree with the new constraint applied:

• Symfony 6.3–7.1 — cannot install. Previously this was the "redundant but technically workable" band.
• Symfony 5.4 / 6.0–6.2 — cannot install. This was the only band where the package addressed something the framework did not.
• Symfony 7.2+ — installable, but this is precisely where MapRequestPayload / MapQueryString are mature and first-party.

The package's supported surface is now a strict subset of the range in which the framework already solves the problem natively. There is no version of Symfony on which this dependency is both installable and additive. That is a stronger conclusion than the prior assessment reached — it is no longer a judgement call about overlap, it is a structural redundancy.

Integration feasibility — unchanged at "low and not worth the glue," now for a simpler reason. We would be writing a service provider and resolver wiring to duplicate a first-party attribute on a Symfony version that ships the attribute. The prior assessment's fallback — "if the gap is real, write the ~100-line resolver in-house" — becomes the only viable path, because the package cannot be installed anywhere the gap might exist.

Technical risk — high and, on the release-discipline axis, higher than before. Two signals moved:

1. Platform support was narrowed in a patch release. The changelog shows 0.3.2 → 0.3.3 with a change that drops all Symfony versions below 7.2. Under 0.x semver a patch bump conventionally signals compatibility-safe change; this is not. Any consumer on 7.0/7.1 upgrading "safely" would hit a composer constraint failure at best. It is a small ecosystem and a small package, so this is not a crisis — but it is a reliable indicator of how the maintainer thinks about backward compatibility, and that thinking will apply to future releases we would depend on.
2. The maintainer has adopted an explicit latest-version-only policy. The wording "7.2 and higher only" reads as intent, not accident. Combined with a single-author origin and one credited contributor (@vadim-gap), the realistic operating model is: the package tracks whatever Symfony version the author is currently on, and older branches are dropped without a major bump.

Maturity signals are marginally better than recorded — there is now a visible 0.3.2 → 0.3.3 progression and at least one outside contributor, so the "single release, possibly abandoned on arrival" framing was slightly pessimistic. That does not offset the narrowing. Refresh stars/dependents before finalising, but the direction of travel is clear: the project is being actively narrowed, not broadened.

Key questions (revised — most are now moot, two are not):

• Which Symfony versions are supported? Answered: 7.2+ only.
• Is this Symfony-only or framework-agnostic? Answered: Symfony-only.
• Is latest-version-only a stated support policy, or an incidental consequence of one PR? This determines whether 7.3/8.0 support arrives promptly or the package strands again.
• Will a 6.4 LTS branch ever be supported? Our estate's centre of gravity is likely 6.4 LTS, which is supported upstream into late 2027 — the package currently cannot install on the version most of our services actually run.
• Does the resolver still collide with MapRequestPayload on priority ordering, given both now target the same Symfony versions? (Academic if we do not adopt.)

Integration Approach

Stack fit — decision tree now collapses to two branches.

1. Laravel — do not integrate. FormRequest plus typed DTOs via container binding. Unchanged, and the 0.3.3 release notes remove any remaining ambiguity about this being a Symfony artifact.
2. Symfony, any version we run — do not integrate. On 6.4/7.0/7.1 it will not install; on 7.2+ use MapRequestPayload. There is no third branch.

Migration path. Not applicable — nothing to migrate from, and no adoption path to migrate along. The prior assessment's "internal seam" guidance (own interface, package as one implementation behind it) remains good engineering advice for request-object mapping generally, but it is no longer a mitigation for this dependency because the dependency is not entering the codebase.

Compatibility. This is where the release is decisive. Check our supported Symfony matrix: if it includes 6.4 LTS — and for most estates it will — then the package's constraint (^7.2) excludes the majority of our fleet. The remaining services on 7.2+ already have a first-party equivalent. The compatibility story is not "narrow," it is "disjoint from our needs."

Sequencing.

1. Immediate: cancel the planned Week 2 spike. Its entry condition was a pre-6.3 Symfony estate, which 0.3.3 has made unreachable. Running the spike now would spend two days confirming a foregone conclusion.
2. Same week: close the evaluation as not adopted — covered natively. Record that the previously documented revisit condition ("stuck on pre-6.3 Symfony") has been invalidated by the maintainer, not by us, and therefore expires.
3. Optional, low cost: log the release-discipline observation (platform drop in a patch bump) in the dependency-evaluation notes as a worked example of what to screen for. It is a cheap calibration data point for future third-party reviews.
4. If mapping requirements recur internally: build the small resolver/DTO seam ourselves against the Symfony version we actually run.

Operational Impact

Maintenance. Upstream maintenance capacity is small but not zero — the project is alive. The problem is not liveness, it is direction: the maintainer is optimising for currency on their own stack, and the 0.3.3 patch release demonstrates willingness to drop platform support without a major version. Had we adopted 0.3.2, this release would have stranded us on Symfony ≤7.1 with a composer update as the failure trigger. We did not adopt, so the exposure is zero — but it is the clearest available evidence of what owning this dependency would have meant. We would have owned a fork by policy, not by exception.

Support. Unchanged: GitHub issues, no SLA, no vendor, no documented security disclosure process. The contributor credit is mildly reassuring about bus factor; it does not create an escalation path. For a component on the request path, that remains an unacceptable support posture regardless of version support.

Scaling. Unchanged and still a non-issue. Per-request reflection and deserialization, stateless, no shared cache or connection pool. This package would never have been the throughput bottleneck; the risk was always correctness and ownership.

Failure modes. The 0.3.3 change adds one and retires the rest:

• (new, and the one that would have bitten us) Composer-level platform breakage on a patch upgrade. A routine composer update fails or, worse, silently resolves to an older pinned tag, leaving two services on different mapping code paths. This is now the headline failure mode and it is release-management-driven, not code-driven.
• (retired) Type/deserialization mismatches surfacing as 500s rather than 422s — not reachable, no integration.
• (retired) Resolver priority collisions with MapRequestPayload after a framework upgrade — not reachable.
• (retired) Abandonment pinning us to an old Symfony — not reachable.
• (residual, generic) Validation-semantics divergence across services if teams hand-roll mapping instead of using the framework attribute. Worth a one-line convention note in our Symfony guidance: use first-party mapping, wrap it in our own DTO conventions, do not invent per-team resolvers.

Ramp-up. No change in the technical learning curve, and no longer relevant. The remaining organisational cost is trivial: a short note closing the evaluation and correcting the "Laravel/PHP package" premise in the intake record so the same package is not re-queued next quarter. That is a fifteen-minute write-up, and it is the only work this release should generate for us.

Bottom line for the steering decision: 0.3.3 is a narrowing release that eliminates the sole condition under which adoption was defensible. The package now supports only Symfony versions on which the framework's own request-mapping already exists, and cannot be installed on the LTS most of our services run. Recommendation stands and hardens: close as "not adopted — covered natively," cancel the spike, and treat the revisit condition as expired by upstream action rather than ours. Re-open only if the maintainer reintroduces a 6.4 LTS branch and a concrete gap is demonstrated against MapRequestPayload — neither of which is on the current trajectory.