- How do I install cerbero/laravel-dto in a Laravel app?
- Install it with Composer using composer require cerbero/laravel-dto. The package is a thin abstraction built around an abstract base class, so there is no service provider to register, no config file to publish, and no migrations to run. You simply extend the base DTO class in your own code and start defining typed properties. That keeps setup to a single command, with the real work being the conventions you agree on for where DTOs are constructed.
- Which PHP and Laravel versions does laravel-dto support?
- The package targets modern Laravel applications on PHP 8.1 or newer, typically Laravel 9, 10, and 11, and it relies on typed properties and PHP 8 language features. Because it is a single-maintainer package with a small user base, you should confirm the exact version matrix and what the CI pipeline actually tests before committing. Treat the composer.json constraints and the GitHub Actions workflow as the source of truth rather than assuming compatibility with every Laravel major. If you run an older framework version, verify support explicitly before your spike.
- How does a DTO get hydrated from an array or an HTTP request?
- Hydration is convention-driven: the package maps input keys to your DTO's typed properties and casts the values accordingly, so a request payload or associative array becomes a typed object in one call. This works best when your property names match the incoming keys, so naming discipline matters more than configuration. Reflection-based hydration is where edge cases concentrate, so test union types, nullable properties, promoted constructor parameters, and readonly properties against your real payload shapes. A one-to-two day spike on genuine request bodies will tell you whether the behavior matches your expectations.
- Can I build a DTO directly from an Eloquent model?
- Yes, converting from Eloquent models is part of the package's stated scope alongside arrays and requests, which lets you pass typed data out of your models into actions and services. The risk area is relations: nested DTO casting combined with lazy or cyclic Eloquent relations can trigger recursion or partial hydration. Eager load the relations you intend to map, keep the DTO graph shallow and acyclic, and assert the resulting object in tests. If your model graph is deep, map to a flat DTO and compose explicitly rather than relying on automatic traversal.
- Does laravel-dto handle validation, or should I use FormRequests?
- Validation is mentioned as part of the package's feature set, but it is a lightweight layer and it does not replace Laravel's validator or your FormRequests. The safest pattern is to keep HTTP-level validation in FormRequests and let the DTO own shaping and type safety at the boundary between transport and domain logic. Confirm in the README how validation failures surface, since a DTO that throws on invalid data behaves differently from one that returns null. Decide this up front so you do not end up validating the same payload twice in two different places.
- How are nested DTOs, collections, enums, and Carbon instances cast?
- Nested DTOs and collections are supported through casting, but this is exactly where DTO packages accumulate undocumented behavior, so probe it early. Enums and Carbon add another layer: verify whether the package constructs them from strings, passes them through, or throws on mismatch. Also check what happens on a type mismatch in general, whether you get an exception, a null, or a silent coercion, because that determines how defensive your calling code must be. Write a small test for each cast type you depend on rather than assuming consistency.
- How does serialization work, and can I exclude sensitive fields from the output?
- Serialization semantics need explicit verification: how a DTO becomes an array, how it becomes JSON, and how that interacts with Laravel API Resources. The realistic failure mode is silent inclusion of fields you did not intend to expose, such as password hashes or internal identifiers, so audit the full output of any DTO that reaches a response. Write a test that asserts the exact serialized shape of each DTO you ship rather than trusting the default. If exclusion is not supported natively, control output through API Resources instead of raw DTO serialization.
- How does laravel-dto compare to spatie/laravel-data?
- Spatie's laravel-data is the closest well-known alternative and has orders of magnitude more adoption, covering validation, transformation, and resource-style output as well as hydration and casting. Cerbero Laravel DTO is the lightweight option: pick it when you want typed hydration and casting without an opinionated validation or API-resource layer. Pick Spatie if you want the DTO to also own validation and response shaping. Do not adopt both, since running two overlapping DTO abstractions is a maintenance tax with no upside.
- Is laravel-dto safe to use in production given its small user base?
- The dominant risk here is adoption, not code quality: with modest star counts and very few dependents you would be among the first production users, so there is no prior art to lean on when something behaves unexpectedly. That is a signal to evaluate, not to standardize across the codebase. Run a time-boxed spike against your real payloads, cover the DTOs that touch sensitive data with tests, and pin the version in composer.json. Reassess once you have seen its behavior on your own edge cases.
- How should I test DTOs in my own test suite?
- Treat the DTO as a boundary contract and test it directly: assert that hydration produces the expected typed properties from representative arrays, requests, and models. Add explicit cases for nullable values, missing keys, enums, Carbon dates, nested DTOs, and type mismatches so the failure mode is documented in code. Also assert the serialized output of any DTO that reaches a response, which catches accidental leakage of sensitive fields. These tests are cheap to write and they insulate you from behavior changes in a package with a small user base.