Symfony Advanced Resolving Laravel Package

Product Decisions This Supports

• API contract strictness (per endpoint, and eventually per field). FromQuery::$disableTypeEnforcement turns a hard-coded behavior into a switch. That is a product decision, not just a technical one: do we reject ?page="2" (string) or coerce it? Strict = better error messages and safer downstream logic; lenient = fewer 400s and better tolerance of legacy/mobile clients. The PM now owns that trade-off explicitly instead of inheriting it.
• Query-string surface area on the roadmap. Any planned work on filtering, sorting, sparse fieldsets, include=, or pagination on public/partner APIs is directly affected. If the team is hand-rolling $request->query('x') parsing today, this package is a candidate to standardize it before the surface grows.
• Build vs. buy for request-to-DTO mapping. The alternative is in-house attribute/reflection code or manual hydration in every controller/FormRequest. Weigh the maintenance cost of a bespoke mapper against depending on a pre-1.0 package.
• Migration/legacy-client strategy. The escape hatch lets us ship a stricter v2 endpoint for new consumers while keeping an existing endpoint lenient — a per-endpoint rollout lever rather than a global flag day.
• Test and QA scope. A static (class-level) property means a value set in one test or one long-running worker can leak into the next. That is a concrete engineering ask: reset it in the test base class and confirm behavior under Octane/queues. Budget for it explicitly.
• Beta dependency risk on the roadmap. v1.0.0-beta.2 signals an unstable public API. Treat adoption as a spike or a behind-a-flag pilot, not a committed platform dependency, until 1.0 lands.

When to Consider This Package

Consider it when:

• You are on Laravel and have endpoints with more than a couple of typed query parameters — lists with filters, sorts, pagination, includes — where $request->query() plus manual casting has started to sprawl.
• You want declarative, attribute-driven mapping from query string to typed objects/DTOs, so the shape of a param is defined once rather than re-parsed per controller.
• You have mixed consumers (internal SPA, partner integrations, legacy mobile) where tolerating loosely-typed input on some endpoints is a real business need — this release makes that a per-endpoint choice.
• You are prototyping an API and want to defer the strict-vs-lenient decision without rewriting the parsing layer later.
• The team is already comfortable with attribute-based configuration and PHP 8.x typed properties.

Look elsewhere when:

• Your endpoints are simple (one or two scalar params). The dependency costs more than the boilerplate it removes.
• You need a stable, versioned contract and cannot absorb pre-1.0 breaking changes — wait for 1.0, or pin and isolate behind an internal adapter.
• Your API is schema-first / OpenAPI-driven with generated validation; a second source of truth for param typing will drift.
• You are GraphQL-first — the query-string problem largely does not exist.
• You need per-field coercion policies today. A single global static toggle is coarse; if different params genuinely need different rules, this release does not yet give you that.

How to Pitch It (Stakeholders)

To executives: We are standardizing how our APIs read and validate query parameters — the filtering, sorting, and paging that every list endpoint exposes. The alternative is custom parsing code in every controller, which is where inconsistent validation and slow-to-diagnose 400s come from. This release adds a per-endpoint switch for how strictly we enforce types, which lets us tighten our API contract for new consumers without breaking older clients in the same release. It is a beta dependency, so the recommendation is a scoped pilot on one or two endpoints, with a decision to adopt or drop once it reaches 1.0 — not a platform-wide commitment.

To engineering: The new FromQuery::$disableTypeEnforcement flag replaces an all-or-nothing behavior with an explicit opt-out, so we can be strict by default and lenient where a client needs it. Two things to own: it is a static property, so it must be reset in the test base class and verified under Octane and queue workers to avoid state leaking across requests; and the package is pre-1.0, so isolate it behind a thin adapter in our own code so a breaking change is a one-file fix rather than a refactor. Upside is that query-param parsing becomes declarative and unit-testable instead of scattered through controllers.