Is your feature request related to a problem? Please describe.
No direct problem, nothing is broken. I love mapperly.
I would like to document/justify why certain property mappings are ignored when using [MapperIgnoreSource(nameof(Car.Id))] and related attributes.
Describe the solution you'd like
From a code generator (output) point of view there is no API change.
I would like to be able to specify the business case/reason why specific properties are not mapped from source to target or the other way around, possibly by extending the existing mapper attributes; here on the example of MapperIgnoreSourceAttribute
public sealed class MapperIgnoreSourceAttribute : Attribute
{
public MapperIgnoreSourceAttribute(string source)
{
Source = source;
}
public string Source { get; }
+ public string? Justification { get; set; }
}
Describe alternatives you've considered
We can put comments next to the ignored attribute, but that makes it harder/near impossible to enforce.
Another way is to create a custom attribute, something like IgnoreJustificationAttribute, which can then be used in code analysis to enforce all (*) ignored properties have a justification.
* - Mapping and handling multiple ignored properties might be a bit of a headache from an analyzer POV.
Additional context
The usage would be comparable to JetBrains.Annotations where we could use freetext to specify why certain properties are not mapped and could build a corresponding analyzer to ensure that all property ignores have a reason why they are not mapped. Currently this information might be lost.
Note: I did not consider the impact this could have in the code-gen itself, when it must look-up metadata for a mapping and if it could cause problems when discovering the attached metadata, if there is suddenly more syntax nodes appearing (the , Justification = "Must never expose PII from a public endpoint")
Note2: This is a very-very nice-to-have feature since there is definately other workaround available; but I think it would be a nice extension to mapperly and I would also be happy to contribute towards the implementation.
Is your feature request related to a problem? Please describe.
No direct problem, nothing is broken. I love mapperly.
I would like to document/justify why certain property mappings are ignored when using
[MapperIgnoreSource(nameof(Car.Id))]and related attributes.Describe the solution you'd like
From a code generator (output) point of view there is no API change.
I would like to be able to specify the business case/reason why specific properties are not mapped from source to target or the other way around, possibly by extending the existing mapper attributes; here on the example of MapperIgnoreSourceAttribute
public sealed class MapperIgnoreSourceAttribute : Attribute { public MapperIgnoreSourceAttribute(string source) { Source = source; } public string Source { get; } + public string? Justification { get; set; } }Describe alternatives you've considered
We can put comments next to the ignored attribute, but that makes it harder/near impossible to enforce.
Another way is to create a custom attribute, something like
IgnoreJustificationAttribute, which can then be used in code analysis to enforce all (*) ignored properties have a justification.* - Mapping and handling multiple ignored properties might be a bit of a headache from an analyzer POV.
Additional context
The usage would be comparable to
JetBrains.Annotationswhere we could use freetext to specify why certain properties are not mapped and could build a corresponding analyzer to ensure that all property ignores have a reason why they are not mapped. Currently this information might be lost.Note: I did not consider the impact this could have in the code-gen itself, when it must look-up metadata for a mapping and if it could cause problems when discovering the attached metadata, if there is suddenly more syntax nodes appearing (the
, Justification = "Must never expose PII from a public endpoint")Note2: This is a very-very nice-to-have feature since there is definately other workaround available; but I think it would be a nice extension to mapperly and I would also be happy to contribute towards the implementation.