Mapper Laravel Package

Technical Evaluation

• Architecture fit: rekalogika/mapper is a PHP object-mapping package with Symfony-oriented dependency signals, not a Laravel-native package from the release notes. It can fit Laravel/PHP applications as a Composer library behind an application-level mapping service, useful for DTO/entity/domain mapping and reducing hand-written hydrators.
• Integration feasibility: Feasible only after validating Composer constraints against the Laravel app’s locked Symfony components. v3.0.0 is primarily a compatibility release: it allows Symfony 8.x except symfony/property-info, which remains pinned to 7.x, and it drops Symfony 6.x. It is not a drop-in upgrade for apps still on Symfony 6 components.
• Technical risk: Medium for upgrades, lower for greenfield projects if constraints align. The Symfony 6 drop is a breaking dependency change. Symfony 8 support is partial, with a known interface change planned for the next major version for property-info/type-info 8.x. The hash change from xxh64 to xxh128 may invalidate persisted proxies or cache-derived identifiers if those hashes are stored. Dependency bumps, especially phpdocumentor/reflection-docblock, could affect docblock-based metadata parsing.
• Key questions: Which Laravel versions and Symfony component versions are in the target apps? Does the package require full Symfony framework integration or only selected components? Is there a Laravel service provider/container binding, or must it be built internally? Is symfony/property-info required for our mapping use cases? Do we persist mapper-generated proxies/caches that depend on hash values? What is the timeline and migration path for the next major interface change?

Integration Approach

• Stack fit: Suitable for Laravel/PHP applications that need structured object mapping and can tolerate Symfony component dependencies. It should be introduced behind an internal mapper abstraction so Laravel code does not depend directly on package APIs. Apps locked to Symfony 6 components should not adopt v3.0.0 without upgrading those constraints.
• Migration path: From v2 to v3, first run Composer constraint analysis, remove Symfony 6 requirements, keep symfony/property-info on 7.x, update the package, clear generated proxies/caches, and rerun mapping tests. For greenfield use, pilot in one bounded context rather than adopting package-wide.
• Compatibility: Build an explicit compatibility matrix for Laravel version, PHP version, Symfony component versions, and property-info version. Do not assume full Symfony 8 compatibility; v3.0.0 explicitly excludes property-info 8.x. Validate behavior with Laravel’s existing Symfony transitive dependencies.
• Sequencing: Inventory Symfony constraints and package usage; branch the upgrade; run composer why-not checks; update dependencies; run static analysis and integration tests; clear caches/proxies; deploy to a canary workload; monitor mapping errors and cache invalidation; then plan for the next major interface change.

Operational Impact

• Maintenance: Active maintenance is indicated by tests, static analysis, dependency bumps, and a deliberate interim release. However, the two-phase Symfony 8 support creates a known future migration. Maintain an internal compatibility matrix and track the next major release.
• Support: Expect community/GitHub support rather than vendor SLA. Laravel-specific support is not evidenced in the release notes, so assign an internal owner for integration, upgrades, and troubleshooting.
• Scaling: Object mapping is typically CPU/memory-bound at request or batch time. The xxh128 change may improve hashing performance, but benchmark representative payloads and verify cache behavior before relying on it at scale. Cache mapping metadata where possible.
• Failure modes: Composer dependency conflicts, especially with Symfony 6 or property-info 8.x; stale proxies/caches after the hash change; mapping exceptions after docblock/type metadata changes; unsupported dependency combinations; and future breakage from the planned interface change.
• Ramp-up: Moderate. Laravel developers can learn the mapping model, but Symfony-oriented configuration and metadata behavior require onboarding. Start with a small pilot, document mapping conventions, and include cache-clearing and dependency-upgrade steps in runbooks.