Issues when mapping type from String -> BigNumber

[josh-richardson]

I have the following two classes:

import { AutoMap } from '@automapper/classes';
import { BigNumber } from 'ethers';

export class SlippageDetails {
  @AutoMap(() => BigNumber)
  amountTryBought: BigNumber;
  @AutoMap(() => BigNumber)
  actualAmountBought: BigNumber;
  @AutoMap(() => BigNumber)
  amountTrySold: BigNumber;
  @AutoMap(() => BigNumber)
  actualAmountSold: BigNumber;
}

and

import { AutoMap } from '@automapper/classes';

export class SlippageDetailsResponse {
  @AutoMap(() => String)
  amountTryBought: string;
  @AutoMap(() => String)
  actualAmountBought: string;
  @AutoMap(() => String)
  amountTrySold: string;
  @AutoMap(() => String)
  actualAmountSold: string;
}

(side note, I didn't think I'd need to provide the type to map to/from in SlippageDetailsResponse, but if I don't do that I get warnings)

I want to map from SlippageDetailsResponse -> SlippageDetails.

To do this I've used the following setup:

        const mapper = createMapper({
          strategyInitializer: classes(),
        });
        createMap(
          mapper,
          SlippageDetailsResponse,
          SlippageDetails,
          typeConverter(String, BigNumber, (str) => BigNumber.from(str)),
        );

And to convert:

        const dto = mapper.map(response.data, SlippageDetailsResponse, SlippageDetails);

However, I'm hitting the following error when the conversion code is executed:

Uncaught (in promise) Error: Mapping is not found for function String() {
    [native code]
} and class {
// BigNumber code (compiled from TS -> JS)

I'm wondering if I'm doing something wrong here, or if there's an issue with the library? Thanks!

[micalevisk]

please share the source object (response.data) as well

[josh-richardson]

ForMember does work but unfortunately I then have to refer explicitly to each object member which is exactly what I'm trying to avoid. I guess I can try to figure out the issue and submit a PR.

[nartc]

I have a feeling the problem is BigNumber symbol itself. I can take a closer look at provide my investigation here. If it's an easy fix, I can let you take it if you're up for it. If not, we can discuss the solution :D

[josh-richardson]

I think this is to do with using vite.
https://stackoverflow.com/questions/68570519/why-cant-reflect-metadata-be-used-in-vite

Looking through the source code:
The line

Reflect.getMetadata('design:type', target, propertyKey);('design:type', target, propertyKey);

(automap.ts#37)

Is always returning null.

[josh-richardson]

Actually, scratch that. Upon closer inspection, it seems the problem is something to do with the library. Even when using a compiler which supports reflect-metadata, the issue persists.

[josh-richardson]

Managed to reproduce this in this repo by cloning & extending the integration tests, so I'm fairly sure it's as @nartc suspected.

[nartc]

This is indeed a bug (and fix has been released with v8.3.4)

So the problem was not in the typeConverter. Since this bug needs some explanation, I'll try to keep it concise

When you call createMap(), AutoMapper will "attempt" to construct an array of MappingProperty of:

• matching properties (Source#foo and Destination#foo)
• matching properties WITH namingConventions (Source#foo#bar and Destination#fooBar)

class Source {
   @AutoMap() // josh, the reason you need () => String here is probably because of Vite. Usually, for primitives, you don't need it
   foo: string;
}

class Destination {
   @AutoMap(() => BigNumber)
   foo: BigNumber;
}

createMap(
   mapper, 
   Source, 
   Destination, 
   typeConverter(String, BigNumber, str => BigNumber.from(str))
);

Here, a MappingProperty between Source#foo and Destination#foo will be created. All MappingProperties that aren't created by forMember() will have TransformationType.MapInitialize as its internal type. Based on this type, AutoMapper knows to run the MappingProperty through normal mapping pipeline (with nested object / array logic etc...) or to run it through the forMember()

typeConverter() patches the MapInitialize instead of creating its own dedicated TransformationType

if (typeConverter) {
    const originalMapInitializeFn = transformation[
        MappingTransformationClassId.memberMapFn
    ][MapFnClassId.fn] as Selector;
    
    transformation[MappingTransformationClassId.memberMapFn][
        MapFnClassId.fn
    ] = (srcObj: TSource) =>
        typeConverter!(originalMapInitializeFn(srcObj)); // you can see here that typeConverter just patches the underline transformation fn
}

In other words, MappingProperty with typeConverter() still goes through the normal mapping pipeline with automatic nested object/array detection. So what's wrong here?

BigNumber is an object. When Destination#foo is mapped from Source#foo, it runs through the typeConverter (str => BigNumber.from(str)) which makes Destination#foo a BigNumber. Because it is an object, AutoMapper attempts to auto-map it with nested-object logic

if (typeof mapInitializedValue === 'object') {
    const nestedMapping = getMapping(
        mapper,
        sourceMemberIdentifier as MetadataIdentifier,
        destinationMemberIdentifier as MetadataIdentifier
    );
    // ...
}

So the library fails when it tries to find a Mapping between String, BigNumber because that is the relationship between Source#foo and Destination#foo.

With 8.3.4, if a property is subject to type converter, it is treated as-is, like a primitive.