feat: add IgnoreObsoleteMembers and MapProperty maps ignored Target

[TimothyMakkison]

Resolves #284 and #450.

• Created MapperIgnoreObsoleteMembersAttribute and added IgnoreObsoleteStrategy to MapperAttribute. Updated MembersMappingBuilderContext to add the derecated members to there respective Ignored*MemberNames.
• Updated FieldMember and PropertyMember to expose the underlying symbol.
• Added unit tests
• Mapper attribute config is overriden by the method configuration.
• By default IgnoreObsoleteStrategy is none so deprecated members are treated as normal.
• The method attribute has a default parameters of Both

[MapperIgnoreObsoleteMembers] partial B Map(A source);`

blanket ignore all obsolete members except when [MapProperty] is used?

Haven't done this yet, I'm not 100% sure how MemberConfigsByRootTargetName works to match the obsolete members to the respective explicitly mapped member.

I'll wait for #390 and then update the relevant logic.

[TimothyMakkison]

Does Mapperly support ignoring nested properties?

// Where ProducerDto has getter setter methods and a parameterless constructor.
[MapperIgnoreSource("Manufacturer.Id")]
[MapperIgnoreTarget("Producer.Id")]
[MapProperty(nameof(Car.Manufacturer), nameof(CarDto.Producer))] // Map property with a different name in the target type
public static partial CarDto MapCarToDto(Car car);

Generates

 public static partial global::Riok.Mapperly.Sample.CarDto MapCarToDto(global::Riok.Mapperly.Sample.Car car)
{
    var target = new global::Riok.Mapperly.Sample.CarDto();
    if (car.Manufacturer != null)
    {
        target.Producer = MapToProducerDto(car.Manufacturer);
    }

    target.Name = car.Name;
//...
private static global::Riok.Mapperly.Sample.ProducerDto MapToProducerDto(global::Riok.Mapperly.Sample.Manufacturer source)
{
    var target = new global::Riok.Mapperly.Sample.ProducerDto();
    target.Id = source.Id;
    target.Name = source.Name;
    return target;
}

[latonz]

@TimothyMakkison nested ignored properties are currently not supported. Is there a use-case for this?

[TimothyMakkison]

@TimothyMakkison nested ignored properties are currently not supported. Is there a use-case for this?

Mb I thought it did, wasn't sure if i had messed up the member paths. I wanted to reuse some of the logic to let explicit mappings override ignored deprecated members.

I think nested ignores would be a good addition to mapperl, It already has nested explicit mappings.

[latonz]

Thank you for another great contribution 🌞

• Good looking tests 😊
• Could you also update the documentation?
• TBD: Should obsolete enum members also be ignored (to be discussed, if implemented, implement it in another PR). Should it be automatically or via a separate configuration? I think the best way would be to do it the exact same way, without any additional configuration. If it should be overwritten for an enum, it could get overwritten on an enum mapping method with the same attribute. WDYT?

[latonz]

@TimothyMakkison

I think nested ignores would be a good addition to mapperl, It already has nested explicit mappings.

Mapperly doesn't really have nested mappings, it does only have flattening/unflattening.
Can you show a concrete use-case for this? Probably open a new discussion about this topic to not bloat this PR.

[latonz]

@TimothyMakkison FYI: an issue to the nested ignored properties just got opened: #395

[latonz]

@TimothyMakkison feel free to re-request a review when ready 😊

[TimothyMakkison]

ignore all obsolete members except when [MapProperty] is used?

Discovered #450 when trying to implement this. I could fix the bug so MapProperty will map ignored target properties just like obsolete target properties.

[TimothyMakkison]

• MapProperty now always maps ignored obsolete members.
  • In the process resolved Inconsistent mapping for MapProperty when Source or Target properties are ignored #450 decided to make it so MapProperty overrides ingored target properties just like it already did for ignored source proeprties.
• Updated PublicAPI.Shipped file.
• Added MapProperty tests.
• I haven't added to the docs, should I create a brief summary, and if so where?

[codecov]

Codecov Report

Merging #392 (e99c604) into main (18dec45) will increase coverage by 1.20%.
The diff coverage is 98.79%.

❗ Current head e99c604 differs from pull request most recent head 9ad8722. Consider uploading reports for the commit 9ad8722 to get more accurate results

@@            Coverage Diff             @@
##             main     #392      +/-   ##
==========================================
+ Coverage   91.04%   92.24%   +1.20%     
==========================================
  Files         166      151      -15     
  Lines        5627     4851     -776     
  Branches      711      618      -93     
==========================================
- Hits         5123     4475     -648     
+ Misses        351      256      -95     
+ Partials      153      120      -33     

Impacted Files	Coverage Δ
src/Riok.Mapperly/Symbols/FieldMember.cs	73.33% <0.00%> (-12.39%)	⬇️
src/Riok.Mapperly.Abstractions/MapperAttribute.cs	100.00% <100.00%> (ø)
...stractions/MapperIgnoreObsoleteMembersAttribute.cs	100.00% <100.00%> (ø)
...Riok.Mapperly/Configuration/MapperConfiguration.cs	100.00% <100.00%> (+1.38%)	⬆️
...ly/Configuration/PropertiesMappingConfiguration.cs	100.00% <100.00%> (ø)
...ers/BuilderContext/MembersMappingBuilderContext.cs	100.00% <100.00%> (ø)
...lders/NewInstanceObjectMemberMappingBodyBuilder.cs	79.75% <100.00%> (-0.25%)	⬇️
...pingBodyBuilders/ObjectMemberMappingBodyBuilder.cs	100.00% <100.00%> (ø)
src/Riok.Mapperly/Helpers/DictionaryExtensions.cs	100.00% <100.00%> (ø)
src/Riok.Mapperly/Symbols/PropertyMember.cs	80.00% <100.00%> (+1.42%)	⬆️

... and 61 files with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[latonz]

Thank you for the updates, I added my feedback.
Could you also update the documentation (I would add a new section in 01-mapper.md in ## Properties / fields).

[TimothyMakkison]

Note that in order to support MapProperty mapping obsolete targets, I fixed #450 in this PR.

Now if a target is Ignored but is explicitly mapped with MapProperty a mapping will be created. Perhaps a warning should be created?

[latonz]

I'd add a warning diagnostic if an explicit ignored property is mapped manually (but not if a property is ignored because it is obsolete). I think this could be done in another PR.

Could you adjust the PR body that it resolves #450?

[latonz]

@TimothyMakkison I created #512 to implement the diagnostic.
Whats still missing:

• Update the documentation (I would add a new section in 01-mapper.md in ## Properties / fields)
• Update integration tests

Otherwise this MR looks good 😊

[latonz]

@TimothyMakkison looks good to me. A few linter issues need to be fixed...

[TimothyMakkison]

@TimothyMakkison looks good to me. A few linter issues need to be fixed...

Thanks, please don't merge this just yet, I haven't added the integration tests

[latonz]

Oh thanks, I would have missed that 🙈

[github-actions]

🎉 This PR is included in version 2.9.0-next.3 🎉

The release is available on:

• GitHub release
• v2.9.0-next.3

Your semantic-release bot 📦🚀

[github-actions]

🎉 This PR is included in version 3.0.0 🎉

The release is available on:

• GitHub release
• v3.0.0

Your semantic-release bot 📦🚀