Dto Validator Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for the validation layer. If the roadmap includes a typed DTO/contract layer between HTTP (or queue/CLI) input and domain logic, this package is a candidate to replace hand-rolled FormRequest rules and ad-hoc array validation with attribute-driven rules declared next to the data they constrain. Evaluate it as a thin buy: it removes boilerplate, not a category of work.
• Platform support matrix / upgrade sequencing. The v1.1.4 change lowers the floor from PHP >=8.2 to >=8.1. This directly unblocks adoption in services still on PHP 8.1 and removes "upgrade the runtime first" from the critical path. It also means a single dependency can be shared across a mixed-version fleet, which simplifies standardization and reduces the number of version-pinned forks you maintain.
• Migration and rollout order. Because the package now installs on 8.1, it can be introduced before the platform upgrade rather than after — decoupling two workstreams that would otherwise be serialized. Useful when a PHP 8.2+ migration is gated on other commitments.
• API contract consistency. A shared DTO validation convention is a prerequisite for consistent error payloads, OpenAPI/schema generation, and client-facing error contracts. This package supports that standard rather than defining it — the product decision is the convention, the package is the cheap enforcement mechanism.
• Dependency risk posture. A single-maintainer, narrowly scoped package is a low-blast-radius bet if it stays small and its rules are expressed in plain PHP attributes. It becomes a liability if you start encoding business rules that only it can express.
• Roadmap hygiene. Patch-level (v1.1.4) with no breaking changes: no migration work, no deprecation backlog, no re-plan. It is an enabler signal, not a feature signal.

When to Consider This Package

Consider it when:

• You are on Laravel (or a compatible PHP framework setup) and PHP >=8.1, and you want validation rules colocated with DTO properties instead of duplicated in request classes.
• You are standardizing request/command payloads into DTOs and want validation to travel with the type rather than living in a separate rules file that drifts.
• Your rule set is largely declarative (required/type/length/range/enum-style constraints) and expressible via attributes. The package is a convenience layer — its value is inversely proportional to how much custom rule logic you need.
• You want a small, replaceable dependency: low install footprint, no service dependencies, no vendor lock at the data layer.
• You have a mixed PHP 8.1/8.2/8.3 fleet and want one dependency version across it — the v1.1.4 floor change is exactly this case.

Look elsewhere when:

• You need a maintained-by-a-company dependency with an SLA, security-response guarantees, or a published support window. This is a single-maintainer project; treat it as community-supported and plan an exit path.
• Your validation is dominated by custom, cross-field, or database-backed rules — you will end up writing the same imperative code, plus a layer of indirection.
• You are not on Laravel/PHP, or you are below PHP 8.1 (the new floor still excludes older runtimes; do not read v1.1.4 as broad backward compatibility).
• You require framework-native behavior that only FormRequest/Validator gives you (authorization hooks, after hooks, custom message resolution via lang files) and are unwilling to bridge it.
• Security/runtime caveat for the new floor: PHP 8.1 is end-of-life for security support. Support for 8.1 is a migration convenience, not a target state. Adopt on 8.1 only as a bridge, and keep the runtime upgrade on the roadmap — do not let the lowered floor become a reason to defer it.

How to Pitch It (Stakeholders)

For executives (one paragraph): We are evaluating a small, focused validation library for our PHP/Laravel services. The latest patch release (v1.1.4) lowers its minimum PHP version from 8.2 to 8.1, which means we can adopt it across services that have not yet completed their runtime upgrade — removing a sequencing dependency rather than adding one. Cost is near zero (open-source, no infrastructure, no license), risk is low and reversible (patch-level change, no breaking changes, small footprint, rules are plain PHP), and the benefit is less duplicated validation code and more consistent API error behavior. The main caveat is that the project is maintained by a single author and supports an end-of-life PHP version, so we would treat it as a convenience dependency with a documented exit path, not as a platform commitment.

For engineering leads: v1.1.4 is a version-constraint-only release — "php": ">=8.2" → ">=8.1". No API changes, no deprecations, drop-in upgrade. Practical effect: you can install a single version across a mixed 8.1/8.2/8.3 fleet, and DTO validation can land ahead of the runtime migration instead of behind it. Two asks before adoption: (1) confirm the attribute-based rule surface covers ~80% of our actual validation rules — if not, we are buying indirection; (2) confirm our error-response contract is owned by us, not by the package's output format, so swapping the library later is a contained change. Pin the version, keep validation rules expressible in plain PHP, and do not encode business logic that only this package can read.

Trade-off statement: this is a low-cost, low-ceiling improvement. It does not change what we can build; it reduces the cost of building the validation layer we already intend to build, and it slightly widens the window in which we can start.