# spatie/laravel-data: Typed Data Objects for Laravel

> spatie/laravel-data gives Laravel applications a PHP data-object layer for request validation, transformation, resource output, TypeScript definitions, and Eloquent model storage. It suits teams that want one typed structure instead of separate request, transformation, and frontend definitions.

**spatie/laravel-data** — Powerful data objects for Laravel

- Repository: https://github.com/spatie/laravel-data
- Website: https://spatie.be/docs/laravel-data/
- Stars: 1,802 · Forks: 290
- Language: PHP
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/spatie-laravel-data

## Why laravel-data Consolidates Laravel Data Boundaries

spatie/laravel-data addresses a specific repetition problem in Laravel applications: the same fields may be declared in a form request, an API resource, a data transfer object, and a TypeScript definition. The package places that structure in a regular PHP object that extends `Data`. The README presents the package as a way to describe data once and reuse that description when data enters the application, leaves it, or crosses into frontend code.

The intended users are Laravel developers who need typed structures around request handling, API resources, frontend contracts, and Eloquent models. A data object can act as a request target, become an API-resource-like output, or expose selected properties lazily. The documentation also states that validation rules can be resolved from properties and that TypeScript definitions can be generated from the objects.

This does not make every Laravel application more capable. A simple endpoint with one input array and one response may not justify an additional abstraction. The package becomes relevant when property definitions are duplicated across several boundaries, or when PHP types should remain visible as data moves through the application.

## The Data Object Model and Its Processing Flow

The core abstraction is a regular PHP class extending `Spatie\LaravelData\Data`. The README's example uses constructor properties for a title and artist:

```php
use Spatie\LaravelData\Data;

class SongData extends Data
{
    public function __construct(
        public string $title,
        public string $artist,
    ) {
    }
}
```

The constructor establishes the object shape through PHP property types. According to the README, extending `Data` enables automatic transformation into resources, lazy properties, creation from request data, validation, construction from other types, automatic validation during creation, TypeScript generation, and storage as Eloquent model properties. Those capabilities are package features rather than behavior that follows from PHP typing alone.

The useful flow is shared definition first, followed by different operations over the same object. A request can be converted into a data object and validated, the object can be transformed for an API response, and its properties can be used to generate a frontend definition. The repository also contains `config/`, `src/`, `docs/`, `stubs/`, and `tests/`, indicating that configuration, implementation, documentation, generated material, and tests are part of the package layout. The README does not document a single universal processing pipeline or the exact runtime order for every operation.

## Installing spatie/laravel-data in a Laravel Project

The README gives Composer as the installation method. Run the following command in the Laravel project where the package is needed:

```bash
composer require spatie/laravel-data
```

That command adds `spatie/laravel-data` to the project's Composer dependencies. The README then directs developers to the installation notes at `https://spatie.be/docs/laravel-data/v4/installation-setup/`. It does not provide a separate command for publishing configuration, registering a service provider, or creating a first data object, so those steps should be taken from the linked installation documentation rather than inferred.

The first object can be created as a normal PHP class. For example, the README defines `SongData` with a typed `title` property and a typed `artist` property. A project can begin by defining the fields that its request or response actually contains, then consult the version 4 documentation for the supported creation and transformation syntax. The repository's `composer test` script is documented for running the package tests, but that is a repository maintenance command rather than an application installation step:

```bash
composer test
```

The README does not state the minimum PHP version, minimum Laravel version, or Composer configuration required for installation.

## Request Validation, Resource Output, and Lazy Properties

The package targets two common Laravel boundaries where duplicated field declarations tend to drift. On input, it can create data objects from request data and validate those objects. The README also says that validation rules for properties can be resolved automatically and that validation can occur when a data object is created. These features reduce the need to maintain a separate validation definition for fields already represented by the data object.

On output, a data object can be transformed into a resource similar to Laravel API resources. That makes the object relevant to applications with API responses, because the same class can define the contract and provide a transformation target. Lazy properties add a narrower option: the README states that only requested parts of data objects can be transformed. This may help applications that do not need every property in every response, although the README does not provide a complete example of the configuration or call syntax.

The limitation is important. Automatic resolution is not the same as saying that every property is validated correctly. The package can derive rules from a property, but the application still has to define the intended domain constraints, custom messages, nested structures, and conditional rules. The README does not document those details, so they must be checked in the version 4 documentation before relying on a validation strategy.

## TypeScript Generation and Eloquent Model Storage

The README identifies frontend contract generation as one reason to use the package. A data object can generate TypeScript definitions, which removes the need to maintain a handwritten frontend definition for the same PHP structure. This is especially relevant when an API's fields are already declared in PHP and the frontend needs a corresponding type.

The package also supports saving data objects as properties of an Eloquent model. That gives an application a way to keep a typed data structure attached to persisted records. The README does not explain the column schema, casting configuration, serialization rules, or relationship behavior needed for this use case. Those details are material because a successful PHP object definition does not by itself establish how the data is stored or restored from the database.

TypeScript generation also needs an explicit integration decision. The repository includes a `types/` directory and a `stubs/` directory, but the README does not document the generation command or output path. The application should therefore treat frontend type generation as a documented workflow to verify, not as an automatic side effect of installing the Composer package.

## Maintenance Signals, Upgrade Surface, and MIT Terms

The repository is not archived, and its last push was on 2026-09-01. Recent listed releases include 4.23.0 on 2026-05-08, 4.22.1 on 2026-04-27, and 4.22.0 on 2026-04-16. Those dates indicate recent repository activity and versioned releases. They do not establish compatibility with every Laravel application or remove the need to review upgrade notes.

The repository contains `CHANGELOG.md` and `UPGRADING.md`, so upgrade-specific information is maintained in project files. The README does not summarize the breaking changes between these releases, the supported Laravel matrix, or the PHP compatibility range. An adopting team should inspect those files and the version 4 installation documentation before changing an existing dependency.

The project is released under the MIT License. That permits use and modification under the license's conditions, while applications still need to review the actual `LICENSE.md` text and preserve required notices. This is a licensing note, not legal advice. No paid service, hosted feature, or separate commercial license is described in the README.

## Spatie/laravel-data Compared with Separate Laravel Structures

The practical alternative is to keep separate Laravel form requests, API resources, data transfer objects, validation rules, and handwritten TypeScript definitions. That approach has no additional data-object dependency and leaves each representation explicit, but it creates repeated declarations and more opportunities for the server and frontend contracts to diverge.

spatie/laravel-data takes a different approach. It uses an extended PHP class as the shared representation, then delegates operations such as request creation, validation, transformation, lazy output, TypeScript generation, and Eloquent model storage to package functionality. The trade-off is increased framework and package coupling. The application depends on the package's conventions for how a `Data` class behaves, rather than relying only on Laravel's individual components.

The package is therefore a better fit when the duplication problem is repeated and the project accepts that shared abstraction. Separate structures remain easier to inspect when a project has only one narrow use case, unusual validation that does not fit the object model, or a team that does not want generated frontend types and automatic transformations in its workflow.

## Conclusion

Adopt spatie/laravel-data when a Laravel application has data structures repeated across requests, API output, and frontend types. Do not choose it for a small application where a plain PHP class is enough or when its documented features are unnecessary. Verify first that the package version, PHP and Laravel compatibility, validation behavior, and generated TypeScript workflow fit the application.

## FAQ

### What is spatie/laravel-data used for?

It provides rich PHP data objects for Laravel applications. The README lists request creation and validation, resource transformation, lazy properties, TypeScript definition generation, and storage as Eloquent model properties among its features.

### How do I install spatie/laravel-data?

The README gives `composer require spatie/laravel-data` as the installation command. It links to the version 4 installation and setup documentation for further configuration details.

### Does spatie/laravel-data replace Laravel form requests and API resources?

The README says a data object can be used instead of a form request or API transformer. It also says that extending `Data` enables transformation into resources, so the package can cover both input and output roles in a shared data structure.

## Sources

- [License: MIT](https://github.com/spatie/laravel-data/blob/main/LICENSE)
- [Project website](https://spatie.be/docs/laravel-data/)
- [README](https://github.com/spatie/laravel-data/blob/main/README.md)
- [Releases](https://github.com/spatie/laravel-data/releases)
- [spatie/laravel-data on GitHub](https://github.com/spatie/laravel-data)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/spatie-laravel-data