- What is juststeveking/laravel-data-object-tools used for?
- It is authoring-time tooling for Laravel that adds Artisan generators, publishable stubs, configurable namespaces, and a lightweight base data-object class. It helps teams scaffold and standardize DTOs so application data flow stays clean, type-safe, and consistent. It does not put anything on the request path or provide runtime services. It is a conventions enabler at the scaffolding seam between framework and domain code.
- How do I install laravel-data-object-tools in a Laravel app?
- Run composer require juststeveking/laravel-data-object-tools:^2.0. Laravel package auto-discovery handles the service provider, and there are no migrations. Publishing config is optional and best skipped unless you need to override defaults. Integration effort is essentially a constraint bump plus a test run, assuming you are already on Laravel 11.
- Which Laravel and PHP versions does version 2.0 support?
- The 2.0 major is framed as adding Laravel 11 support, which almost certainly drops Laravel 9 and 10 and may raise the PHP floor. Do not rely on release notes as the compatibility statement; read the package's composer.json for exact illuminate/* and php constraints. This is the key gate to close before rollout. If you are not on Laravel 11 and modern PHP, stay on the prior major or avoid adoption.
- Do generated DTOs extend a package base class or stand alone?
- That depends on the published stubs and base class usage, and it is the single fact that flips your risk profile. If generated DTOs inherit from the package base class, a future major can invalidate existing classes and grow your blast radius. If they stand alone, upstream abandonment costs a composer remove and a template change. Get an explicit engineer answer in writing before adopting. Also ask whether the major bump is a constraint reset only or changes base class and helper signatures.
- Can I use this package alongside spatie/laravel-data?
- They can technically coexist, but spatie/laravel-data owns the DTO space in practice and two DTO conventions in one estate produce ambiguous hydration semantics. Choose one convention per app deliberately and document the choice. Check class names, namespaces, and config keys for collisions where teams already use Spatie. For most teams the safer standard is one DTO approach, not both.
- Does laravel-data-object-tools handle validation, casting, transformation, or serialization?
- No. It is authoring-time scaffolding, not a runtime validation, casting, transformation, or serialization engine. API Resources keep serialization responsibilities, and FormRequests keep validation responsibilities. State these non-goals in your rollout note so stakeholders do not expect DTO tooling to buy those features.
- How should I configure namespaces and stubs for generated data objects?
- The package provides publishable stubs and configurable namespaces. Publishing config is optional and best skipped unless defaults need overriding; publish stubs only when you want to customize generated code. Keep the namespace convention in your internal standards doc and enforce it in PR review or CI lint. Treat configuration changes as convention decisions, not platform changes.
- Is this package production-ready and actively maintained?
- It is dev tooling with a single maintainer, low cadence, 66 stars, and zero dependents, so treat it as a pattern with scaffolding rather than a supported product. Upstream CI and test coverage may be limited or unknown, so plan to verify generated output in your own test suite. Maintainer concentration shapes contingency posture such as vendor or fork, not the adoption decision. Record it in the dependency register and assign an internal owner for the DTO convention if upstream goes quiet.
- What is the realistic effort and risk to adopt this in an existing Laravel 11 codebase?
- Integration feasibility is low: composer require, auto-discovery, no migrations, and optional config publishing. The real effort is a constraint bump plus a test run, and schedule exposure lives in the Laravel 11 upgrade, not this package. The highest technical risk is an unsignalled breaking surface in the semver-major, so verify composer.json constraints first. Then confirm generated DTO inheritance and document the one-DTO-convention choice.
- When should I choose this package vs. Spatie vs. an internal generator?
- Build vs. buy here is a three-way decision: this package, spatie/laravel-data, or an internal generator plus a convention doc. At this maturity you are buying a pattern with scaffolding, not a supported product, and a short internal generator is credible if DTO scope stays narrow. Choose one per app and document it. Roadmap sequencing matters too: this is a follower of the Laravel 11 upgrade and must never be a driver.