> If you want to avoid this issue altogether, consider using a source generator library like Mapster. That way, mapping issues can be caught at build time rather than at runtime.
The only winning move is not to play. Mapping libraries, even with source generators, produce lots of bugs and surprising behavior. Just write mappers by hand.
Every time I've worked on a project that used AutoMapper, I've hated it. But I'll admit that when you read why it was created, it actually makes sense: https://www.jimmybogard.com/automappers-design-philosophy/
It was meant to enforce a convention. Not to avoid the tedium of writing mapping code by hand (although that is another result).
2025 version: write mapping functions by llm.
Agree, mapping libraries make things only more complicated and harder to debug.
We've been using Mapperly (https://mapperly.riok.app/), after a migration from AutoMapper, in our production application. I'm having a good experience, and we kind of like the holistic of this library.
So far, there have been no surprises, and the library warns about potential issues very explicitly, I quite like it.
Of course, if it's just a handful of fields that need mapping, than write manually is the way to go, specially if said fields require a custom mapping, where the library would not facilitate.