1) When using naming conventions, the naming convention configuration override will be incorrect during InitialMapping, I think because it uses the namingConvention provided at the mapping level. This can result in some funky behavior when initial mapping happens, like separating my_thing into ["my","_Thing"].
2) If it finds a similarly named field in the destination (in the example above, "my", it will try to treat that field as an object even when it is not an object, resulting in hasProperty throwing an error due to the obj parameter being undefined.
This PR fixes only issue (2) from the list above. There seems to be another issue that namingConventions overrides are loaded too late for initial mapping. However, once something is actually mapped, it works as expected, resulting in the following output:
There are a few issues I noticed when debugging the same error found in these issues:
https://github.com/nartc/mapper/issues/525 https://github.com/nartc/mapper/issues/551
1) When using naming conventions, the naming convention configuration override will be incorrect during InitialMapping, I think because it uses the namingConvention provided at the mapping level. This can result in some funky behavior when initial mapping happens, like separating my_thing into ["my","_Thing"]. 2) If it finds a similarly named field in the destination (in the example above, "my", it will try to treat that field as an object even when it is not an object, resulting in hasProperty throwing an error due to the obj parameter being undefined.
Example code that causes an issue:
This PR fixes only issue (2) from the list above. There seems to be another issue that namingConventions overrides are loaded too late for initial mapping. However, once something is actually mapped, it works as expected, resulting in the following output:
{ something_else: 'else', currency_code: 'USD', value: 100 }
ISSUES CLOSED: #525, #551