Automapper Plus Bundle Laravel Package

Product Decisions This Supports

• Architecture bet: do we invest in a DTO / mapping boundary layer? The bundle's real product value is not the container wiring — it is the enforcement of a declarative mapping contract (registerMapping(Employee::class, EmployeeDto::class) plus forMember(...) closures) living in versioned configurator classes. That supports a roadmap decision on whether entities ever leak past the service boundary, and whether API/view-model contracts are explicit code or ad-hoc array shaping.
• Build vs. buy for transformation code. The realistic shortlist is: (a) this bundle + mark-gerarts/automapper-plus, (b) spatie/laravel-data, (c) Eloquent API Resources, (d) a ~200-line in-house mapper. This package is the cheapest buy option to evaluate — MIT, one Composer require, no vendor contract — so it is worth a timeboxed spike purely to price the build alternative against something concrete.
• Platform scoping — the decision a PM actually owns here. This is a Symfony bundle, not a Laravel package. Its value proposition is a Flex-registered bundle plus AutoMapperConfiguratorInterface autoconfiguration and an automapper_plus.configurator tag with priorities — machinery with no path into Laravel's service-provider model. On a Laravel stack the leverageable asset is the framework-agnostic core library behind a thin custom provider, which is new engineering we must budget for. A PM should frame this as "adopt the mapping pattern and possibly the library," never "adopt the bundle."
• Risk-appetite / dependency-policy decisions. 65 stars, 0 dependents, single maintainer, patch-level releases (1.4.1 through 1.6.0 are Symfony/PHP compatibility bumps). That forces two governance decisions we would need anyway: do we accept single-maintainer dependencies on non-differentiating plumbing, and do we pin to patch versions?
• Use cases it makes cheap if we already have DTOs: API versioning and response-contract shaping, read models for admin/reporting surfaces, import/export transforms, and translation between internal and partner/microservice payloads. Custom-member closures and fromProperty('some.nested[child]') paths cover most real transformation logic without hand-written loops.
• A cheap "no" decision. Evaluating this is a fast way to confirm that API Resources or spatie/laravel-data already cover our needs — a useful, low-cost closure on a recurring backlog question.

When to Consider This Package

Consider it when:

• The stack is Symfony 3.4–8.x / PHP-suitable, or the team explicitly agrees to run the core library under a custom Laravel provider.
• A DTO or clean-architecture layer is already a commitment — mapping is the missing plumbing, not a solution seeking a problem.
• Manual mapping duplication is measurable (audit first): repeated entity→payload construction, scattered conditional field logic.
• Transformations are non-trivial — nested paths, computed members, null/substitution rules (skip_constructor, ignore_null_properties, use_substitution) — where a DSL earns its learning curve.
• One named internal owner exists for the mapping profiles, and the team accepts a pin-to-patch policy.
• Strictness is desirable: SymfonyPropertyAccessorBridge refuses to touch private properties without accessors, which is a defensible default for contract integrity.

Look elsewhere when:

• The target is Laravel and the ask is a drop-in. It is not one; treat it as custom work.
• The app is simple CRUD already served by Eloquent API Resources.
• The team has standardized on spatie/laravel-data — switching costs exceed any gain from a 65-star dependency.
• Mapping sits on a hot path (bulk 1,000+ record transforms); reflection-based mapping needs benchmarking and manual code may win.
• Procurement requires an SLA, vendor escalation, or a security-review trail with a named maintainer.
• Nobody will own the profiles. Unowned mapping config drifts from the schema and surfaces as runtime failures.

How to Pitch It (Stakeholders)

To executives — one paragraph: This is a small, MIT-licensed Symfony bundle that standardizes how we convert internal objects into API and view models, replacing duplicated hand-written transformation code with declarative, testable configuration. Cost to trial is one Composer dependency and roughly a sprint of a single engineer's time; cost to reject is near zero. We should treat it as a timeboxed spike with explicit exit criteria, not a platform commitment — it has 65 stars, zero known dependents, and one maintainer, so it carries abandonment risk that we must own internally. Expected upside is reduced duplication and consistency in our API contracts; expected downside is bounded to the spike.

To engineering — the practical case: One service, automapper_plus.mapper, or just type-hint AutoMapperPlus\AutoMapperInterface. Register mappings in classes implementing AutoMapperConfiguratorInterface; with autowire/autoconfigure enabled the bundle tags them for you, and you can split profiles across as many configurators as you like with tag priorities. Options are configurable via config/packages/automapper_plus.yaml or set directly on the Options object in a configurator. The Symfony PropertyAccessor bridge gives strict-by-default behavior with a DecoratedPropertyAccessor escape hatch for private properties, and both enable nested fromProperty paths. The bundle tracks Symfony 3.4 through 8.x, so it will not block platform upgrades.

The ask: One sprint, one module, one owner. Deliverable is a benchmark (bulk mapping latency vs. hand-written), a mapping-assertion test pattern we can reuse, and a written recommendation. Decision gate before rollout: confirm stack fit, confirm the DTO layer is genuinely on the roadmap, and identify the profile owner. If any of those three fail, we stop and standardize on the incumbent — and we will have learned that cheaply.