Automapper Laravel Package

Product Decisions This Supports

• Feature delivery: Speeds up building API request/response DTOs, domain-to-presentation mapping, webhook/event payloads, import/export transforms, and integration adapters where object shapes differ.
• Roadmap: Useful if the roadmap includes public APIs, modular monolith boundaries, third-party integrations, or stricter separation between Eloquent models and API contracts.
• Build vs. buy: Favors buying/adopting over building an internal mapper when mapping code is repetitive, error-prone, and performance-sensitive. The MIT license and code-generation approach lower licensing cost and runtime overhead.
• Architecture standard: Supports a decision to standardize a mapping layer instead of scattering toArray(), manual hydrators, and ad hoc transformation logic across controllers, jobs, and services.
• Use cases: Eloquent model → DTO, DTO → entity, API resource → domain object, queue payload → command DTO, and versioned API response mapping.
• Risk decision: The package is niche (≈220 stars) and not Laravel-first, so adoption should be scoped to a pilot or isolated behind an internal mapping interface rather than made a platform-wide dependency on day one.

When to Consider This Package

Consider it when:

• You have many repetitive object-to-object mappings and manual mapping is creating bugs or slowing delivery.
• Mapping sits on a hot path where runtime performance matters and generated mappers are preferable to reflection-heavy alternatives.
• You want typed DTOs and clean boundaries between Laravel/Eloquent models and API, domain, or integration layers.
• The team is comfortable with PHP code generation, cache directories, OPcache, and deployment warm-up concerns.
• You can wrap it behind an internal service/provider so the rest of the Laravel app is not tightly coupled to the package API.
• You need a focused mapper rather than a full validation/serialization framework.

Look elsewhere when:

• You only have a handful of mappings; manual mapping or Laravel API Resources will be simpler.
• You need first-party Laravel conventions, validation, and transformation in one tool; evaluate spatie/laravel-data or native Resources first.
• You require large community adoption, long-term vendor support, or extensive Laravel-specific documentation.
• The mapping logic is highly contextual, polymorphic, or rule-heavy and generated mappings would be harder to debug than explicit code.
• The team cannot own generated-code debugging, cache lifecycle, and deployment configuration.
• The package’s mapping features do not cover your edge cases and you would end up fighting it rather than gaining leverage.

How to Pitch It (Stakeholders)

For executives: This is a low-cost, MIT-licensed PHP mapper that can reduce boilerplate and inconsistency in API and integration work. It is best positioned as a targeted productivity tool: pilot it on a bounded mapping-heavy feature, measure delivery speed and defect reduction, and avoid making it a platform dependency until the team has validated operational fit.

For engineering: JoliCode AutoMapper generates mapping code on the fly, which can make DTO/entity/API transformations fast and explicit without hand-writing every mapper. In Laravel, integrate it through a service provider, keep generated code in a writable/cacheable path, and isolate it behind an internal mapping contract. The main trade-offs are modest ecosystem adoption, non-Laravel-specific documentation, and the need to own code-generation/deployment behavior. Use native Laravel Resources or spatie/laravel-data where they already fit; use this package where mapping volume and performance justify a dedicated mapper.