- What is cerbero/dto and what problem does it solve in Laravel?
- Cerbero DTO is a lightweight PHP/Laravel package for building type-safe data transfer objects from arrays and HTTP requests. It adds typed properties, casting, validation, nested DTO hydration, and serialization so you can pass structured objects instead of associative arrays across service boundaries. It is a convenience abstraction for the request-to-action seam, not a framework or ORM replacement.
- How do I install cerbero/dto with Composer?
- Install it with Composer using composer require cerbero/dto. The package is Composer-installable, MIT licensed, and has a small surface area, so a proof of concept is usually a same-day task. Pin an explicit version because the API may be pre-1.0 and unstable.
- Which PHP and Laravel versions does cerbero/dto support?
- Confirm the exact PHP and illuminate/* constraints in the package's composer.json before adopting, because the evaluation did not verify them against your stack. It targets Laravel 9 through 11 and PHP 8.1+ style service-layer codebases, but you should check the release history for how quickly new Laravel majors are supported. A hard illuminate/support constraint can block a future Laravel upgrade.
- Does cerbero/dto validate input, or should I keep using Form Requests?
- The package supports validation, but that does not mean it should replace Form Requests. Many teams keep Laravel's validator and Form Requests as the authoritative input gate and use DTOs only for typed hydration and transport. Decide explicitly where validation lives so you do not end up with two competing validation layers.
- How does cerbero/dto handle nested DTOs, collections, and nullable properties?
- Cerbero DTO supports nested DTOs and property casting, including collection-style inputs, but the exact treatment of unknown keys and optional or nullable properties should be verified in the source and tests. Reflection-based hydration can silently coerce types or skip unexpected keys, which is a correctness risk in payment, pricing, and identity flows. Write explicit tests for null, missing, and extra fields before relying on it.
- How does cerbero/dto serialize DTOs to arrays and JSON?
- DTOs can be serialized to arrays and JSON for output, which makes them convenient for responses and logging. However, the output must match your existing API Resource contracts or clients will break at the edges. Run a contract test that compares DTO serialization against your current response fixtures before switching endpoints.
- Is cerbero/dto production-ready, and is its API stable?
- Treat it as unproven rather than merely niche: the repository has around 17 stars, zero dependents, and a single maintainer, so there is little production validation outside the author's usage. Check CI status, test coverage, the latest commit, and release dates as part of due diligence. Assume a single-maintainer package may eventually become internal code you own.
- How does cerbero/dto compare to spatie/laravel-data or readonly classes?
- Spatie's laravel-data is more widely adopted and has a larger ecosystem, while hand-rolled readonly classes have zero dependency risk but more boilerplate. Cerbero DTO is smaller and less opinionated, which is an advantage if you only need typed hydration and casting. Avoid running two DTO idioms in one codebase; pick one and standardize naming, nullability, and conversion points.
- Does cerbero/dto work with PHPStan and Larastan?
- Reflection-driven hydration often needs PHPStan or Larastan stubs, baseline entries, or type hints before static analysis is clean. Add PHPStan/Larastan at your current level and check for new suppressions before merging. Wrapping the package behind an internal base class also gives you a single place to annotate types.
- Will cerbero/dto block Laravel upgrades, and how do I keep it replaceable?
- A hard illuminate/support constraint can turn a convenience into a migration blocker, so pin the version and let Dependabot or Renovate surface conflicts early. Wrap the package in an internal base class such as App\Support\Data\BaseData so DTO definitions depend on your class rather than the vendor namespace. That makes replacing the vendor a one-file change, and you should introduce DTOs at one boundary first, ideally an unstable external payload.