Laravel Data Object Tools Laravel Package

Technical Evaluation

Architecture fit. The framing that matters for a TPM is that this is authoring-time tooling, not a runtime dependency. It contributes Artisan generators, publishable stubs, configurable namespaces, and a lightweight base data-object class — it puts nothing on the request path, owns no data, runs no jobs, and exposes no service-provider behaviour that must be operated. Architecturally it is a conventions enabler sitting at the scaffolding seam between framework and domain code. The consequence is strategic: it cannot constrain application architecture, so the adoption decision is a standards decision rather than a platform decision, and should be governed as such — conventions doc, PR review, CI lint — rather than through architecture review.

Integration feasibility. Low. A composer require juststeveking/laravel-data-object-tools:^2.0, auto-discovery, no migrations, and optional config publishing best skipped unless defaults need overriding. The realistic effort estimate is "a constraint bump plus a test run," credible only for teams already on Laravel 11. Scheduling risk is therefore negligible; the schedule exposure lives entirely in the framework upgrade, not in this package.

Technical risk. Ranked, with the TPM action attached to each:

1. Unsignalled breaking surface (highest). A semver-major whose entire changelog reads "Support for Laravel 11" almost certainly drops Laravel 9/10 and may raise the PHP floor. Read composer.json directly; do not accept release notes as the compatibility statement. This is the one gate to close before rollout — not a reason to reject, a reason to verify.
2. Generated code becomes our code. If generated DTOs inherit from a package base class, a future major invalidates existing classes and our blast radius grows. If they stand alone, upstream abandonment costs a composer remove and a template. This single fact flips the risk profile and deserves an explicit engineer answer in writing.
3. Maintainer concentration. Single maintainer, low cadence, one first-time contributor on this release, 66 stars, zero dependents. For dev tooling this shapes contingency posture (vendor/fork), not the adoption decision. Record it in the dependency register; do not let it become a blocker argument.
4. Ecosystem adjacency. spatie/laravel-data owns this space in practice. Two DTO conventions in one estate produces ambiguous hydration semantics. Choose one per app, deliberately, and document the choice.
5. Scope misexpectation. Stakeholders may assume DTO tooling buys validation, casting, transformation, or serialization. It does not. API Resources keep serialization; FormRequests keep validation. State the non-goals in the rollout note.

Key questions.

• Exact illuminate/* and php constraints in 2.0.0, and which Laravel versions were dropped?
• Is the major bump a constraint reset only, or are the base class and helper signatures changed?
• Do generated DTOs inherit from the package base class, or stand alone?
• Does it coexist cleanly with spatie/laravel-data (class names, namespaces, config keys) where teams already use it?
• Is there upstream CI/test coverage, or is all verification on us?
• Who owns the internal DTO convention if upstream goes quiet?

Leverage for a TPM. Three decisions this directly supports. First, build vs. buy: the honest three-way is this package vs. Spatie vs. an internal generator plus convention doc. At this maturity we are buying a pattern with scaffolding, not a supported product, and a short internal generator is a credible substitute if DTO scope stays narrow. Second, roadmap sequencing: this is a follower of the Laravel 11 upgrade and must never be a driver, so any roadmap item assuming DTO tooling schedules after the framework lands. Third, standardisation ROI: the measurable benefit is that five teams stop inventing five DTO shapes — a review-and-onboarding saving, not a runtime metric.

Integration Approach

Stack fit. Laravel 11 on modern PHP. Conventional apps and multi-app monorepos both fit, since each app resolves its own constraint. No queue workers, scheduled jobs, storage, or request-path services. Config publishing is optional and defaults should generally be kept — an empty published config is a file we then maintain forever.

Migration path. There is no data migration and no runtime cutover. The only migration is a Composer constraint change plus optional DTO regeneration. Two credible paths:

• Conservative: pin ^1.1.0 on apps still on Laravel 10; take 2.0.0 only as each app reaches Laravel 11.
• Unified: upgrade the framework estate first, then move to 2.0.0 everywhere in one pass.

Take the unified path if more than one or two apps are involved. Splitting a code-generation tool across majors is precisely how two DTO dialects emerge, and that divergence costs more than the sequencing discipline.

Compatibility. Verify the illuminate/support range and PHP floor before scheduling. Run composer why-not juststeveking/laravel-data-object-tools 2.0.0 per app to surface transitive blockers early — the cheapest schedule-protection step available. Where 2.0.0 won't resolve, pin ^1.1.0 explicitly so upgrades fail loudly rather than drifting. Overlap between 1.x and 2.x is likely limited to Laravel 11, so mixed estates are tolerable short term but need a dated convergence point on the roadmap.

Sequencing.

1. Read 2.0.0 composer.json; record dropped Laravel/PHP versions and any signature changes.
2. Inventory Laravel versions across the estate; tag apps that cannot take 2.0.0 today.
3. Pin 1.1.0 explicitly where 2.0.0 won't resolve.
4. Land framework upgrades first — this package rides the upgrade, it does not lead it.
5. Bump the package, regenerate one representative DTO, and diff it against an existing one — the cheapest available BC-break detector.
6. Publish the internal DTO convention doc, then roll out broadly.
7. Add a CI check on generated shape (lint or golden-file diff) so drift is caught mechanically, not by review vigilance.

Pitch framing. To executives: a small, zero-runtime, MIT-licensed developer tool; the major version means older Laravel is dropped, so it is only relevant once we are on Laravel 11; single maintainer, so we treat it as an absorbable pattern; cost is a Composer line item and hours of ramp-up; risk low and reversible. To engineering: generators plus a base class, nothing on the request path; pin explicitly where 2.0.0 won't resolve; validate before hydration; keep toModel()/toAttributes() explicit where persistence rules matter; serialise through API Resources rather than exposing objects.

Operational Impact

Maintenance. Near-zero steady state — no services, queues, cron, or storage to operate. Cost is Composer updates plus occasional regeneration. The real maintenance risk is upstream dormancy, not churn, and dormancy is cheap here because the artefact we depend on is code already merged into our repo.

Support. Developer-facing only. No on-call surface, no user-visible failure mode, no SLA to negotiate. Support load is one onboarding note plus a conventions page. Escalation is internal by definition; there is no vendor to call, and the assessment should say so plainly rather than imply one exists.

Scaling. No runtime scaling dimension. The scaling concern is organisational: as teams multiply, unreviewed generator output drifts and the "standard" stops being standard. Enforce with CI, not documentation — a rule that cannot be checked will be ignored once more than two teams are involved.

Failure modes.

• Constraint lockout — most likely and most irritating: the package's Laravel constraint blocks or delays a framework upgrade. Explicit pins plus composer why-not checks in CI contain this.
• Upstream dormancy — no releases, no fixes. Recoverable by vendoring the base class and stubs into our repo; the trigger should be a dated review, not a surprise.
• Inheritance blast radius — if generated DTOs extend a package base class, a future major becomes a repo-wide refactor. Know the answer before rollout, not after.
• Dialect divergence — half the estate on this package, half on Spatie. Prevented by a per-app written choice and a CI lint on the generated shape.
• Scope overreach — teams expecting validation or serialization and hand-rolling it into DTOs. Prevented by stating non-goals in the rollout note.

Ramp-up. Hours per developer, not days. The package is small enough to read end to end, and no one needs operational training because nothing runs in production. The conventions doc carries more of the value than the package does, so budget the writing time there: what a DTO is for, where it may not be used, how hydration and persistence are handled, and which alternative is sanctioned on apps that chose Spatie. Adoption should be treated as complete only when a new developer can generate a DTO, hydrate it from validated input, and know where its boundaries are — without reading the package source.