- How do I install romanzipp/laravel-dto?
- Install it with Composer via composer require romanzipp/laravel-dto. The package is a lightweight abstraction built around an abstract DTO base class, so it does not require service-provider registration or configuration publishing. You simply extend the base class in your own App\Data namespace and start declaring typed properties. Check the composer.json constraints before installing to confirm the package supports your Laravel and PHP versions.
- Which Laravel and PHP versions does laravel-dto support?
- The package declares its supported versions through its composer.json constraints on illuminate/* and php, so read those first. Adoption is low, which means version drift against new Laravel and PHP majors is the main risk rather than code quality. Confirm the constraints cover the exact Laravel and PHP runtime you have in production before you commit. If they do not, the evaluation ends there or you vendor the class internally.
- How do I hydrate a DTO from a Laravel request?
- The package provides hydration from plain arrays, so you can pass $request->validated() or $request->all() into the DTO constructor factory. The typical flow is FormRequest validation first, then hydration into a typed DTO that is passed to your service or action layer. This keeps the HTTP layer at the boundary and gives your domain code a predictable object instead of a loose array. Prefer validated data so you are not relying on the DTO to enforce business rules.
- Can a DTO contain nested DTOs or collections of DTOs?
- Yes, cast nested DTOs and collections of DTOs is one of the core features of the package. You declare the property with the nested DTO class type and the hydration logic maps incoming arrays into that type. This lets you model a request payload as a small object graph rather than a flat associative array. Keep nesting shallow, since deep graphs make debugging casting failures harder.
- Does laravel-dto validate data or only cast types?
- It is a type casting and hydration layer, not a validation framework. Type mismatches are about structure and declared property types, while rules like required, email, or unique belong in Laravel FormRequests or the Validator. The intended pattern is to validate first and hydrate second, so the DTO receives known-good data. That separation is what makes the DTO safe to pass into domain services.
- What happens when a value does not match the declared property type?
- Because casting is reflection-based, the behavior on a mismatch is the thing to verify in the source before adopting. You need to know whether it throws an exception or coerces the value, since silent coercion turns a schema change into a subtle data bug. Write a small test per DTO covering a wrong-type input and assert the exact behavior you expect. Failing loudly is strongly preferable for anything crossing a layer boundary.
- How does laravel-dto handle unknown or extra keys during hydration?
- Whether extra keys are silently dropped or trigger an error is a behavioral detail worth confirming in the code and pinning with a test. Silent dropping hides client mistakes and API drift, while throwing can break otherwise harmless payload additions. Decide which behavior you want and encode it in a shared base class or a test suite. This matters most when you consume third-party or mobile client payloads that evolve independently.
- Is laravel-dto a good alternative to spatie/laravel-data?
- They solve overlapping problems, but spatie/laravel-data has the larger community, richer documentation, and built-in validation integration. romanzipp/laravel-dto is a thinner, smaller surface that you can audit end to end in an afternoon, which is its main advantage. If you need validation rules, resource transformation, or a large body of production war stories, spatie is the safer pick. If you only want typed property hydration and nothing else, the smaller package earns its keep.
- Does laravel-dto work with PHP 8 enums, readonly properties, and union types?
- Reflection-based casting is exactly where newer PHP type features tend to break first, so test these explicitly before relying on them. Write DTOs with an enum property, a readonly property, and a union-typed property, then hydrate them and assert the results. If any of them fail, that constrains how you model your data rather than blocking adoption entirely. Pin the behavior with tests so a PHP upgrade does not silently change hydration results.
- Is romanzipp/laravel-dto maintained and safe to use in production?
- It has very low adoption, around 11 stars and zero dependents, which means no community corpus of production experience and no downstream projects testing compatibility for you. The realistic posture is fork-and-own rather than bet-the-architecture. Create an internal App\Data\DataTransferObject that extends or copies the package class, and use only that internally, so you can swap the parent or vendor the file with zero application-level changes. Name an owner and budget a small number of days per year for version bumps and PHPStan compatibility.