stas-plov/dto-validator-bundle
stas-plov/dto-validator-bundle adds DTO-based validation to PHP applications, letting you define rules for data transfer objects and keep request/input handling clean and reusable. A lightweight bundle for structured validation workflows.
StasPlovDtoValidatorBundle is a small, single-maintainer PHP package that provides DTO-centric request validation — mapping inbound payloads into typed data-transfer objects and validating them, as an alternative to Laravel's array-based FormRequest validation. The v1.1.4 release is a single-line change: the Composer platform constraint moves from "php": ">=8.2" to "php": ">=8.1".
Architecture fit. The package occupies the input-boundary layer, which is exactly where Laravel applications already have a native answer (FormRequest, Validator::make, or now the casts/ validated() pattern). Adopting it is a deliberate architectural choice to shift validation into typed objects — beneficial if the codebase already leans on DTOs, value objects, and readonly properties, and largely redundant if it does not. This is a convention-level dependency, not an infrastructure one; it is cheap to add and cheap to remove, which is the most favourable property a package here can have.
Integration feasibility. Composer-only, no service provider surface area mentioned beyond bundle registration, no runtime services, no persistence. For a Laravel app this is a same-day spike: install, convert one FormRequest to a DTO, measure ergonomics. The v1.1.4 constraint relaxation specifically unblocks adoption on PHP 8.1 fleets that were previously excluded — a real, if narrow, expansion of the addressable base.
Technical risk. The principal risk is that lowering a declared constraint is not the same as lowering a supported floor. Declaring >=8.1 while the codebase may still use 8.2-only constructs (readonly classes, DNF types, constants in traits, json_validate()) would produce a package that installs on 8.1 and then fails at parse or runtime. Equally, if the CI matrix was not extended to 8.1, the 8.1 path is untested and the constraint is an unverified claim. Both are resolvable by inspection but must not be assumed. Secondary risks are the usual ones for a single-maintainer micro-package: bus-factor of one, no LTS commitment, and a semver surface that is effectively "the whole library" (any validation-semantics change is breaking), so 1.x minors deserve a read rather than a blind bump.
Key questions.
>=8.1 floor itself defensible long term, given 8.1 is past security end-of-life? A package advertising 8.1 support may become the thing that anchors the platform to an unsupported runtime.Stack fit. Laravel 10+ / PHP 8.1+. The package is framework-adjacent rather than framework-deep, so it composes with existing validation, form requests, API resources, and exception handling rather than replacing them. Best fit is a JSON API with a stable, versioned contract where typed DTOs double as documentation and as the input to OpenAPI generation. Poor fit is a mature application with hundreds of array-shaped FormRequest rules and no DTO layer — the migration cost there is unbounded and the benefit marginal.
Migration path. Do not migrate wholesale. Run a strangler pattern: pick one new or actively-churning endpoint, define a DTO, validate through it, compare failure ergonomics (422 shape, field-level messages, nested/array rules) against the existing FormRequest behaviour. If the observable API error contract is preserved, expand to endpoints touched by the same team; otherwise stop and revert — the removal cost is one Composer line plus the DTOs.
Compatibility. Verify the PHP floor claim before relying on it: run composer why-not php 8.1 in the target app, then run the package's own test suite and your integration test on an 8.1 image. If your fleet is 8.2+ already, the constraint change is inert and v1.1.4 is a no-op for you — it neither helps nor harms, and is not on its own a reason to bump.
Sequencing. (1) Confirm 8.1 is genuinely exercised in the package's CI and static analysis, and confirm your own runtime version. (2) Dependency-review the v1.1.3 → v1.1.4 diff — expect one line in composer.json. (3) Pin the exact version in composer.json rather than floating ^1.1, given the single-maintainer risk profile. (4) Only then run the single-endpoint spike. (5) Gate wider adoption on the spike plus a written note on the fallback path back to FormRequest.
Maintenance. Near-zero operational surface: no migrations, no queues, no background processes, no data at rest. The carrying cost is dependency hygiene — patch releases must be reviewed manually because a "compatibility" bump can silently change what the library claims to support. Budget a quarterly check rather than automated patch-level merging for this dependency.
Support. Single maintainer, no commercial backing, no paid support tier, community issues only. Treat it as a library you may have to fork. If the adoption becomes load-bearing, the responsible move is to vendor or fork it — it is small enough that a fork is a realistic option, which is itself the strongest argument that the risk is containable.
Scaling. No runtime scaling concern; validation cost is proportional to request volume and rule count, same order as Laravel's native validator. The scaling limit that matters is organisational: the number of engineers who understand the DTO conventions. Beyond a certain team size this needs an internal style guide, or the codebase splits into DTO-shaped and array-shaped validation with no rule for which applies where.
Failure modes. (a) Phantom 8.1 support — installs on 8.1, fatals on 8.2-only syntax; mitigated by testing on the actual target runtime. (b) Error-contract drift — DTO validation returns a different 422 shape than FormRequest, quietly breaking API clients; mitigated by asserting the response contract in integration tests before rollout. (c) Abandonment — maintainer goes quiet, a future Laravel major breaks the bundle; mitigated by pinning and by accepting the fork burden up front. (d) Unsupported-runtime anchor — the >=8.1 floor becomes the reason a team defers its own PHP upgrade; mitigate by keeping the package's floor strictly below your platform's floor and treating 8.1 support as a convenience, not a commitment.
Ramp-up. A competent Laravel engineer is productive in under a day; the concepts (DTO, typed properties, validation rules) are already familiar. The real ramp-up cost is on reviewers: they must internalise when DTO validation is expected versus when FormRequest is acceptable. Publish that rule before the second team adopts it.
Assessment of v1.1.4 specifically. A low-risk, compatibility-widening patch. It does not change validation behaviour, introduces no deprecations, and requires no action for teams already on PHP 8.2+. It is worth recording as the version at which the PHP 8.1 floor was claimed, and worth verifying that the claim is backed by CI before any 8.1-dependent adoption is approved. No change to the overall recommendation: adopt narrowly behind a spike, pin the version, and keep the exit path cheap.
How can I help you explore Laravel packages today?