Automapper Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for the mapping layer. The decision this package informs is whether to hand-roll object-to-object transforms (request DTO → command, Eloquent/Doctrine entity → API resource, third-party payload → domain object) or adopt a declarative mapper. A library like this trades a dependency for less boilerplate and fewer "I forgot to update the mapper" bugs; the bundle itself is not the thing you'd buy.
• API and integration roadmap. Mapping cost scales with the number of distinct shapes you expose. If the roadmap includes versioned APIs, multiple client-facing representations of the same entity, or several inbound webhook/partner formats, a mapping abstraction becomes a genuine architectural decision rather than a convenience.
• Read-model / CQRS investment. Auto-mapping is most defensible when you have many small, similar read models and command objects. Fewer than roughly a dozen mapping pairs, hand-written mappers are cheaper to own than any framework.
• Framework fit is itself a decision. This is a Symfony bundle, not a Laravel package — it ships a Symfony bundle class and DI configuration, not a ServiceProvider. For a Laravel codebase the relevant artifact is the framework-agnostic jolicode/automapper core (usable directly, or via a thin service-provider wrapper) or a Laravel-native alternative such as spatie/laravel-data / CuyZ/Valinor. Adopting the bundle in Laravel is not a viable path.
• Not a candidate for adoption as-is. Effectively dormant: 0 stars, 0 dependents, and the only recent activity is a compatibility shim (8.1.0 permits AutoMapper >=8.2). Treat this as a pattern reference, not a dependency. The concept (attribute-driven conventions, generated mapping) is worth evaluating; this specific distribution is not.

When to Consider This Package

Consider it only if all of the following hold:

• The application is Symfony (not Laravel), on a PHP version the 8.1.0 / AutoMapper ≥8.2 pairing supports.
• You have a meaningful volume of repetitive, structurally similar mappings — enough that maintenance burden is measurable.
• You're comfortable pinning to a low-activity artifact whose only visible upstream work is dependency-range compatibility, and accepting that you largely own any future patches (PHP minor-version drift, security advisories in transitive deps).
• You're evaluating it as a short-term bridge or a reference implementation, not a long-term foundation.

Look elsewhere — or skip mapping libraries entirely — when:

• You're on Laravel. The bundle will not register. Use the core library, spatie/laravel-data, or plain readonly DTOs with explicit fromModel() factories.
• The package is in maintenance-only mode. The 8.1.0 release is a one-line constraints change — no features, no fixes, no roadmap. That confirms the project isn't dead, but it does not establish an active maintainer investing in the bundle. No security response cadence, no PHP-version roadmap, no upstream fixes we can count on.
• The community signal is zero. 0 stars and 0 dependents means no battle-testing, no Stack Overflow corpus, and no hiring pool that knows it. The onboarding and debugging cost lands entirely on your team.
• Your mapping surface is small. Under ~10 mapping pairs, a handful of explicit mappers is cheaper to write, review, and debug than any convention-based system — and vastly easier to trace when a field comes back wrong.
• You need precise control over serialization semantics (dates, money, enums, nullability). Convention-driven mappers are weakest exactly where correctness matters most; symfony/serializer normalizers or explicit constructors are more predictable.

Verdict: do not adopt for our stack. The 8.1.0 compatibility bump is a genuine (if minimal) positive — it removes the "abandoned, will not track upstream" objection and confirms the bundle is aligned with the current core. Framework mismatch and near-zero adoption still decide it.

How to Pitch It (Stakeholders)

To executives: We re-checked this candidate for standardizing how data moves between our database, our domain objects, and our APIs. Still a no. A new release landed, but it only widens the supported version range of the underlying mapper — no new capability, no maintainer investment, and still no visible users. Combined with the fact that it's a Symfony component and we're on Laravel, adopting it would mean owning a niche dependency forever to save some repetitive code. The idea behind it is sound; we'll pursue it through a maintained library or a small in-house convention instead.

To engineering: This is a Symfony bundle wrapping jolicode/automapper, and 8.1.0 just bumps the allowed AutoMapper version to >=8.2. So the earlier "archived" read was too strong — the bundle is being kept compatible with core — but that's the entire scope of the work, and it still doesn't apply to our Laravel codebase. Recommendation stands: don't take the dependency. If mapping boilerplate is actually hurting us, benchmark the effort against spatie/laravel-data or explicit readonly DTOs with named constructors — both are maintained, both are traceable, and both avoid the "magic mapper produced a wrong field and nobody can tell why" failure mode. Revisit only if we can point to a concrete, recurring cost in the current code, not an anticipated one.