Laravel Data Laravel Package

Product Decisions This Supports

• Build vs. buy on the "contract layer." Every Laravel app that has an API, a SPA/Inertia frontend, or inbound webhooks eventually hand-writes the same shape three times: validation rules, a DTO, and a response transformer. This package collapses those into one Data class, so the buy decision is essentially free (MIT, one Composer dependency) versus weeks of internal DTO scaffolding, serializer plumbing, and validation-rule derivation.
• Feature scoping for API-first and integration work. Because a single class can validate inbound payloads, cast/transform outbound responses, and emit TypeScript definitions, we can size "new endpoint + frontend types" work materially smaller. That directly affects how much API surface fits in a sprint and how confidently we commit to a partner-facing contract.
• Roadmap: frontend/backend contract drift. The TypeScript generation is the highest-leverage item for roadmap planning. If our roadmap includes shipping or expanding a TS frontend (React/Vue/Inertia) or adding third-party consumers, this package turns "keep types in sync" from recurring manual work into a generated artifact in CI.
• Platform consolidation decision. With explicit support for Laravel 12/13, Livewire 4, and Inertia (including deferred props), it's a defensible standard to adopt once across squads rather than letting each team invent its own DTO convention — which is the usual source of "every service has a different request shape" friction.
• Prioritizing integration-heavy use cases: webhook ingestion (typed, validated payloads), Eloquent model attributes stored as data objects, multi-source normalization (API → internal model), and lazy/partial serialization for expensive response fields. These are the scenarios where the ROI case is easiest to make to a skeptical tech lead.
• Sequencing the migration. It's additive, not a rewrite: adopt on new endpoints and the highest-churn existing ones first. This makes "modernize the API layer" a roadmap item that can be delivered incrementally rather than as a big-bang project.

When to Consider This Package

Adopt when most of these are true:

• The stack is Laravel (10+) on PHP 8.2+ and we expect to stay there — the package tracks Laravel releases closely (13 support landed in 4.20.0), so it's a low-risk bet within that ecosystem.
• We have a real API boundary (public API, SPA/mobile client, partner integrations, webhooks) where request/response shape correctness matters, not just an internal CRUD admin.
• We have or plan a TypeScript frontend; the codegen benefit is the clearest differentiator and the easiest thing to demo.
• There is duplication pain today: validation rules, transformers, and frontend types drifting apart, or serializers written by hand.
• The team is comfortable with convention-over-configuration and reflection-based "magic." This is the single biggest adoption predictor. Teams that insist on explicit, hand-wired code will fight it.
• We can accept deployment hygiene: internal structures get cached, and the changelog explicitly calls out needing to clear that cache on upgrade (4.14.0). That must be in the release checklist, or we'll see post-deploy surprises.
• We want vendor confidence: MIT license, Spatie-maintained, mature docs/changelog/releases, high download volume, and a fast patch cadence.

Look elsewhere when:

• The app is not Laravel (or is Laravel-adjacent PHP where a framework-agnostic serializer fits better).
• The domain is schema-first rather than code-first — if OpenAPI/protobuf/JSON Schema is the source of truth and clients are generated from it, standardizing on PHP classes inverts the workflow. (A JSON Schema exporter exists as a third-party add-on, but it's an extension, not the core model.)
• The codebase is small and stable with one or two endpoints and no separate frontend: the learning curve and indirection won't pay back.
• The team is hard-blocked on minimal dependencies or on avoiding reflection-heavy code for performance/debuggability reasons.
• We need long-term frozen APIs with no upgrade appetite — major versions have introduced breaking changes, so an unmaintained fork-in-place is a worse outcome than hand-rolled DTOs.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can remove a recurring class of integration defects — mismatched field names, missing validation, and frontend/backend type drift — with a mature, MIT-licensed, Spatie-maintained Laravel package that has effectively zero license cost and is already supported on our Laravel version. It lets us define each data contract once instead of three times, which shortens the delivery time for API work and reduces the bug surface in anything that crosses a system boundary (partner APIs, webhooks, the TS frontend). The risks are contained: it's additive, we can adopt it endpoint-by-endpoint, and it can be removed class-by-class if it disappoints. The main non-technical cost is discipline — one team convention plus a cache-clear step in deploys.

For engineering leadership: Standardize on one Data class per contract, used as form request, transformer, and TypeScript source of truth. This deletes the "resource + DTO + validator" triplication and gives us generated types in CI, so contract drift becomes a build failure rather than a production bug we discover from a customer. It's an established package (Spatie, MIT, active releases, Laravel 13 / Livewire 4 support) with a low exit cost because adoption is per-class and incremental.

For engineering teams (the honest caveats): This leans on reflection and convention, so expect a short ramp: understanding attribute mapping, lazy properties, and casts is the bulk of the learning. Pin the version, treat major upgrades as planned work, and add "clear data cache" to the deploy runbook. Start with two endpoints — one inbound webhook and one response consumed by the frontend — and measure whether it actually reduced code before standardizing.