Laravel Data Object Tools Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow. The honest comparison is three-way: this package, spatie/laravel-data, or an internal Artisan generator plus a written DTO convention doc. At 66 stars, zero dependents, and a single maintainer, we are not buying a supported product — we are buying a pattern with a head start on scaffolding. A short internal generator is a credible substitute if DTO scope stays narrow, so price this as "hours saved per team" rather than "capability acquired."
• Roadmap sequencing. This is a follower of the Laravel 11 upgrade, never a driver. Any roadmap item that assumes DTO tooling must be scheduled after the framework upgrade lands, not alongside it. Putting it earlier creates a constraint that can block the upgrade itself.
• Standardisation ROI. The measurable benefit is that five teams stop inventing five DTO shapes. That is a code-review and onboarding saving — a reduction in ambiguity and rework — not a runtime metric. Frame it that way or it will lose to anything with a dashboard.
• Feature delivery. Standardising how request payloads, job payloads, and third-party API responses are modelled. Trial scope: one write-path DTO hydrating validated request input into an action; nested payloads (line items, addresses, metadata); typed fixtures in tests instead of raw arrays.
• Explicit non-goals. It is not a serialization layer (API Resources keep that job), not a validation engine (FormRequests do), and not a persistence mapper. Stakeholders who expect it to replace Eloquent casts or Spatie's feature set will be disappointed, and that disappointment becomes a scope-creep request if we don't pre-empt it.

When to Consider This Package

Adopt when:

• The application is already on Laravel 11 and PHP constraints have been verified against the package's composer.json — not inferred from release notes.
• DTO work is repetitive enough to justify scaffolding, and more than one team would otherwise invent its own shape.
• You are comfortable with a dev-tooling dependency carrying no runtime, on-call, or data-migration surface — meaning abandonment is recoverable by vendoring the base class.
• You have, or will write, an internal DTO convention doc. The package is worth more as an enforcement mechanism for that doc than as a library in its own right.

Look elsewhere or defer when:

• You are on Laravel 10 or earlier. Pinning ^1.1.0 is possible but splits the estate into two DTO dialects for no product benefit.
• You need feature breadth — validation pipelines, casts, rule inference, transformation. spatie/laravel-data is the mature alternative with a community behind it.
• You need support guarantees, documented upgrade paths, or a vendor to escalate to. There is none here.
• Your data-object needs are modest enough that plain readonly classes plus a fromArray() static method suffice. Be honest about this; it is the most common correct answer.

Mandatory gate before rollout: read the 2.0.0 composer.json directly. A semver-major whose entire changelog reads "Support for Laravel 11" almost certainly dropped Laravel 9/10 and may have raised the PHP floor. An incomplete changelog on a major version is the one item to close out before scheduling — not a reason to reject, but a reason to verify. Second gate, equally important: confirm in writing whether generated DTOs inherit from the package base class or stand alone. If they inherit, a future major invalidates existing classes and our blast radius grows materially.

How to Pitch It (Stakeholders)

To executives: This is a small, zero-runtime, MIT-licensed developer tool that reduces boilerplate when moving data between layers of a Laravel application. Three things to know. One, the 2.0 release is a major version, which in practice means older Laravel versions are dropped — so it is only relevant to us once we are on Laravel 11, and it rides that upgrade rather than leading it. Two, it is maintained by a single developer, so we treat it as a pattern we can absorb rather than a platform we depend on. Three, the cost is a Composer line item plus hours of ramp-up per developer, and the risk is low and reversible: no runtime surface, no data, no on-call exposure, and if upstream goes quiet we vendor a small base class and carry on. Recommendation: adopt as part of the Laravel 11 upgrade, not ahead of it, and standardise on one DTO convention across the estate rather than letting teams pick.

To engineering: Low-coupling Artisan generators plus a base data-object class; nothing runs on the request path. Install with composer require juststeveking/laravel-data-object-tools:^2.0 on Laravel 11 apps; explicitly pin ^1.1.0 where 2.0 won't resolve so upgrades fail loudly instead of drifting. The 1.1.0 → 2.0.0 delta is almost certainly a composer.json constraint change rather than feature work, so treat it as such: verify constraints, bump, regenerate one representative DTO, and diff it against an existing one — the cheapest BC-break detector we have. Standardise on one base class and one hydration convention; running this alongside spatie/laravel-data in the same app produces ambiguous hydration semantics, so make that choice deliberately per app. Validate before hydration, keep toModel()/toAttributes() explicit where persistence rules matter, and serialise through API Resources rather than exposing objects. The real risk is not churn but dormancy — so keep the DTO convention documented in our own repo, add a CI check on generated shape before more than two teams adopt it, and plan on the assumption that we could fork the base class if upstream goes quiet. Ramp-up is hours per developer; the conventions doc carries more of the value than the package does.