Request Object Resolver Bundle Laravel Package

Technical Evaluation

What it actually is. Despite being evaluated as a "Laravel/PHP package," mops1k/request-object-resolver-bundle is a Symfony bundle, not a Laravel package. The -bundle naming convention, the description's explicit framing ("deserialize incoming request parameters from symfony http request object"), and its stated purpose of replacing "new symfony request DTO resolvers" all point to an implementation that registers a Symfony Bundle subclass, a services.yaml definition set, and most likely a ValueResolverInterface/argument-resolver implementation wired into HttpKernel. Laravel ships symfony/http-foundation transitively, so the Request object is compatible — but the bundle bootstrapping, DI container, and argument-resolution hook are not. v2.0.0 does not change this. The release adds a configurable resolver chain and some attribute handling work, both of which live inside the Symfony container/kernel model. There is still no Laravel ServiceProvider, no package discovery metadata, and nothing targeting FormRequest.

Architecture fit. Poor as a drop-in dependency; moderate as a reference implementation or extraction source. The core value proposition — mapping request payloads into typed DTOs with type coercion and nested hydration — is genuinely relevant to Laravel teams, since Laravel's native FormRequest returns a validated associative array, not a typed object, and spatie/laravel-data remains the de facto community answer. But nothing in this package targets Laravel's service container, middleware pipeline, FormRequest lifecycle, or route-model binding. Adoption therefore requires an adapter layer we own, not a composer require + package discovery.

v2.0.0 delta. Two changes are claimed, both relevant but neither transformative:

• Pluggable resolver chain ("add your own resolvers"). This is a genuine architectural improvement for our purposes. A composable chain implies the resolution logic is now behind a contract rather than hardcoded into a single kernel-coupled resolver. That materially lowers extraction cost — we could potentially register our own Laravel-backed resolvers instead of rewriting the dispatcher. It also implies a public interface we should read before forking, since the contract shape is what we would be adopting.
• "Working around attributes." The phrasing is ambiguous and should be treated as a yellow flag, not a feature. "Working around" suggests a workaround for attribute-based resolution (likely PHP 8 attributes or Symfony's attribute-driven DTO mapping) rather than first-class support. Workarounds are precisely where silent coercion and edge-case bugs concentrate. This is unverified marketing until we read the diff.

A major version bump also means the resolver API is presumed unstable. The upstream 1.x → 2.x surface has almost certainly changed, any third-party example code online is stale, and the fork baseline must be pinned to a specific v2.0.0 commit SHA rather than a branch.

Integration feasibility. Unchanged in shape, marginally improved in cost. Feasible in a day or two of spike work if the deserialization logic is cleanly separable from the kernel hook — and v2.0.0's resolver chain increases the odds that it is. The realistic path remains: vendor or fork the resolver internals, confirm its dependency surface (almost certainly symfony/serializer, symfony/property-access, symfony/property-info, possibly symfony/validator), and expose it through a Laravel ServiceProvider plus a custom FormRequest::toDto() or a request-scoped resolver bound to the container. If the logic is entangled with RequestAttributes, ArgumentMetadata, or kernel event subscribers, extraction cost rises materially — the new pluggable chain is the best available signal that it is less entangled than the 1.x line, but that is an inference, not a verified fact.

Technical risk — still the dominant finding. The package retains the full profile of an unmaintained single-maintainer artifact: 9 stars, 0 dependents, a composite score of 0.045. v2.0.0 is a sign of life and should update the "dead since December 2023" characterization — but a single feature release after a long dormancy is not maintenance. It is one commit by one person, with no accompanying evidence of CI, security policy, or a roadmap. Zero dependents still means zero external production validation — no one has stress-tested the edge cases, filed the coercion bugs, or pressured a security response. The description's claim to be "a better alternative" to Symfony's native resolvers remains self-asserted and unverified. Bus factor is 1. There is no CVE-response capability and no upgrade path when Symfony 8 or PHP 8.5/9 lands. The MIT license remains the one clean signal: forking is legally unencumbered, which makes extraction the preferred consumption mode over dependency. If anything, a major-version release with a 0.x-quality ecosystem footprint raises the probability that the API churns again before it stabilizes.

Key questions to answer before committing engineering time.

• What exactly does the resolver-chain extension point look like — is it a stable public interface we can implement against, and is it documented?
• Does the resolver depend on HttpKernel argument metadata, or can the deserializer be instantiated standalone?
• What broke in 1.x → 2.x? Read the diff; a CHANGELOG may not exist.
• What does "working around attributes" actually mean — first-class PHP attribute support, or a conditional workaround that bypasses normal resolution?
• Which Symfony/PHP version constraints are pinned, and does that collide with our framework versions?
• Is there meaningful test coverage, and does it include failure paths (missing keys, type mismatch, nested DTOs, collections)?
• How are validation failures surfaced — typed exceptions we can map to RFC 7807/422 responses, or raw serializer exceptions?
• Does it perform strict typing, coercion, or silent null-on-missing? Silent coercion is the highest-risk behavior for API contracts.
• Are there any advisories or open issues indicating security-relevant deserialization issues?

Integration Approach

Stack fit. Laravel's Request extends Symfony\Component\HttpFoundation\Request, so the input object is a non-issue. The conflict is entirely at the wiring layer: Symfony bundles self-register via Kernel::registerBundles(), whereas Laravel requires a ServiceProvider and composer.json extra.laravel.providers. This package will not auto-discover and will not boot. Plan for an adapter, not an installation. The v2.0.0 resolver chain gives us a slightly cleaner seam to adapt at, but the seam is still on the Symfony side of the boundary.

Migration path. Recommend a fork-and-extract strategy over direct dependency, pinned to the v2.0.0 tag:

1. Spike (1–2 days). Clone at the v2.0.0 tag, run the test suite, instantiate the resolver outside a kernel, and document the true dependency surface and API — specifically the new resolver-chain contracts.
2. Extract. Lift the deserialization core and the resolver-chain abstraction into app/Support/RequestDto/ (or a small internal package under our namespace), stripping bundle registration and kernel hooks and adding symfony/serializer + property-info as explicit first-party dependencies. Prefer registering our own resolver into the chain over rewriting the dispatcher.
3. Wrap. Register a container binding and a ResolvesRequestDto trait or middleware in our base FormRequest, so DTO hydration is a single call after validation.
4. Harden. Wrap the call site with our own exception mapping into the standard 422/400 envelope, and add contract tests covering missing fields, nested objects, enums, collections, and — given the "attributes" note — at least one attribute-driven DTO shape.
5. Retire the upstream link. Keep the MIT attribution and the v2.0.0 commit SHA in the file header for provenance.

If the spike reveals kernel entanglement or absent tests, fall back to spatie/laravel-data or hand-rolled constructor hydration — both are lower total cost than rescuing an abandoned bundle.

Compatibility and sequencing. Pin the extracted code against our Symfony component versions explicitly; because the components ship as Laravel dependencies, minor-version drift can change serializer coercion semantics. Treat the v2.0.0 API as unstable and vendor the source rather than declaring a Composer constraint — a future 3.x could break the resolver contracts under us. Sequence the work behind any in-flight framework upgrade. Roll out on one internal, low-traffic endpoint first — ideally a GET with simple scalars — before touching write paths.

Operational Impact

Maintenance. Total and permanent. Once extracted, we own the code: PHP version bumps, serializer API changes, and bug fixes are ours. v2.0.0 is welcome evidence that someone is still working on it, but one feature release does not constitute a support relationship, and there is no maintainer bandwidth we can appeal to and no community to absorb fixes. Budget this as internal library ownership (a few hours per quarter plus upgrade work), not as a third-party dependency with vendor support.

Support and ramp-up. No commercial support, no documentation beyond the README, no Stack Overflow corpus. Onboarding cost is low-to-moderate but knowledge will be concentrated in whoever performs the extraction. Mitigate with a short ADR plus contract tests so a future engineer can reason about behavior from tests rather than from source. The small codebase remains an advantage: fully auditable in an afternoon, and the new resolver-chain interface should make intent easier to read than a single monolithic resolver did.

Scaling. Effectively a non-issue. This is pure in-process CPU work — deserialization and property mapping on a payload already in memory. Cost scales linearly with payload size and nest depth; there is no I/O, no state, and no shared resource. A chain of resolvers adds a small per-request walk over the chain, negligible at realistic chain lengths but worth a sanity check if we register many custom resolvers. Watch only for pathological payloads (deeply nested arrays, large collections) if we do not enforce request size limits upstream.

Failure modes to instrument and guard.

• Silent hydration. Missing or misspelled keys resolving to nulls or defaults instead of failing — the most damaging mode, because it produces 200s with wrong data. Enforce required-property checks with explicit exceptions.
• Coercion drift. "1" vs 1 vs true handling changing across serializer versions; pin versions and assert behavior in tests.
• Chain ordering ambiguity. Now that resolvers are pluggable, a custom resolver and a built-in resolver can both claim the same type; the winner depends on registration order. Make ordering explicit and covered by a test.
• Attribute workaround behavior. Given v2.0.0's "working around attributes" claim, verify that attribute-annotated DTOs hydrate identically to conventionally-configured ones. Workarounds are where asymmetric edge cases hide.
• Validation bypass. If DTO hydration runs before or independently of FormRequest validation, we lose Laravel's rule engine and authorization checks. Always validate first, hydrate second.
• Exception leakage. Raw serializer/property-access exceptions bubbling to the client, exposing class names and property paths. Map all failures to a single response shape.
• Nested/collection partial failure. One bad item in an array of DTOs should fail the whole request deterministically, not partially hydrate.
• Abandonment cliff. No upstream security response means our fork is the security perimeter; add it to the dependency-scanning inventory even though composer audit will no longer cover it once vendored.

Recommendation. Unchanged in direction: do not add this as a Composer dependency. Treat it as a candidate reference implementation for a 1–2 day spike, and read the v2.0.0 diff as part of that spike — the pluggable resolver chain is a real point in its favor for extraction, while "working around attributes" and the unversioned, undocumented nature of both changes are points against. Adopt only if extraction is clean and test coverage exists, otherwise default to spatie/laravel-data or native typed FormRequest accessors. The 9-star / 0-dependent / 0.045-score profile still says the ecosystem declined this option; one release does not overturn that.