- How do I install shureban/laravel-object-mapper in a Laravel app?
- Install it with composer require shureban/laravel-object-mapper. The ObjectMapperServiceProvider is registered automatically through Laravel package auto-discovery, so no manual setup is required. If auto-discovery is disabled in your project, add Shureban\LaravelObjectMapper\ObjectMapperServiceProvider::class to the providers array in config/app.php. The package works out of the box, and you only need to publish the config when you want to change type mappings.
- Does laravel-object-mapper support readonly DTOs and constructor promotion?
- Yes. Instead of passing an object instance, you pass a class name and the mapper builds the object through its constructor, resolving every constructor parameter from the source data. That makes it suitable for modern readonly DTOs with promoted properties, and you can use the MapFrom attribute to bind a property to a differently named key. Static constructors can wrap this to give you named factory methods on your DTOs.
- What is the difference between using MappableObject, MappableTrait, and ObjectMapper directly?
- All three approaches expose the same mapping methods, so the choice is mostly about how much coupling you want. Extending MappableObject gives you the methods through inheritance, while the MappableTrait lets a class that already extends something else use the mapper. Using new ObjectMapper($dto) directly keeps your DTO completely free of package code, which is useful when you want mapping to stay in the service or repository layer.
- How do I map FormRequest data into a DTO and only include validated fields?
- Call mapFromRequest($request) on your mappable object, or on an ObjectMapper instance wrapping your DTO. By default the mapper reads $request->validated(), so only validated input reaches the object. Pass false as the second argument to map $request->all() instead, which you should generally avoid for anything that writes to a model. There is also a universal map() method that detects JSON strings, arrays, and FormRequests automatically.
- Which Laravel and PHP versions does laravel-object-mapper v2 support?
- Version 2.0.1 explicitly adds Laravel 13 support, which shows the package is tracking the current Laravel release train. The full compatibility matrix for v2 is not fully spelled out in the patch notes, and a major release often narrows the supported range, so check the require constraints in the package composer.json before adopting. Because readonly properties are part of the feature set, expect a PHP 8.1 or higher floor, and verify that in the same place.
- How do I upgrade from laravel-object-mapper v1 to v2 safely?
- Treat the move from ^1.2.0 to ^2.0.1 as a major upgrade rather than a patch bump. The v2.0.1 notes only mention Laravel 13 support, so read the v2.0.0 changelog and migration guide to find renamed methods, changed defaults, or dropped config keys. Then audit every mapper call site and published config in your codebase, upgrade on a staging branch, and run your transformation tests including edge cases before cutting over.
- Can laravel-object-mapper map nested objects, arrays, and custom property names?
- The mapper resolves properties by reflection and applies the same naming rules all the way down, so nested DTOs and array properties are handled through their declared types. Use the MapFrom attribute on a property or constructor parameter when the incoming key does not match the property name, such as mapping full_name to a name property. For type conversions that are not automatic, publish the config and adjust the type mappings rather than casting by hand.
- Do I need to publish the config file for laravel-object-mapper?
- No, the package is designed to work out of the box with sensible defaults. Publish the config with php artisan vendor:publish --provider="Shureban\LaravelObjectMapper\ObjectMapperServiceProvider" only when you need to change type mappings. Publishing also gives you a versioned file to diff during upgrades, which is helpful if you customize mappings.
- Is laravel-object-mapper production ready and how does it perform with large payloads?
- It is a lightweight reflection-based mapper maintained actively, with Laravel 13 support added quickly, which lowers abandonment risk. For typical request and API payloads the overhead is negligible. For bulk work such as mapping 10,000 or more records in a job, benchmark it in your own environment and consider chunking, since reflection cost is per object rather than per field.
- What are the alternatives to laravel-object-mapper for turning arrays into DTOs?
- Common alternatives are spatie/laravel-data, which adds validation, casts, and resource-style transformation on top of DTOs, and spatie/array-to-object for lighter array-to-object hydration. Many teams also write small manual hydrators or use named constructors when the mapping logic is simple. Compare them on how much they couple the DTO to the package, how they handle nested objects, and whether you need validation and serialization in the same layer.