Does the Transformer Plugin support dates?

[PieterBoeren]

Not sure if this is a bug or working as intented, but whenever I use a Date in one of my models, the transformer plugin breaks.

class SomeModel {
  public id = 0;

  //@AutoMap()
  public dateTimeMessage: Date;

  public constructor() {
    this.dateTimeMessage = new Date(0);
  }
}

With this model, I get this result:

ERROR in ./src/models/monitoring/test.vm.ts
[build:webpack] Module build failed (from ./node_modules/ts-loader/index.js):
[build:webpack] TypeError: Cannot read property 'initializer' of undefined
[build:webpack]     at ..\node_modules\@automapper\classes\experimental\transformer-plugin\src\lib\model-visitor.js:60:112
[build:webpack]     at Array.map (<anonymous>)

When I add the "AutoMap" decorator (as commented out above), the error goes away.

It gets even more interesting (I make a mistake when configuring the plugin) when you don't supply any "modelFileNameSuffix" (just pass in an empty array), then there is no error at all and it seems to work (without having to supply the decorator).

In my webpack config:

automapperTransformerPlugin(program, { modelFileNameSuffix: [] }).before,

So to summarize:

1. Are Date types indeed not supported by the Transformer Plugin and do you always have to supply the decorator for those?
2. Why is it working without decorator when I remove all the file name suffixes?

[nartc]

Hi @PieterBoeren,

1. The plugin code tells me that I do intend to support Date type but I don’t have that as a test case. I’ll give that a quick look in couple of hours. This might be some AST issue. Now, I’m just curious, can you share the compiled code of that model, with the plugin turned on, and without AutoMap decorator? I want to see what the plugin currently generates for a Date
2. With an empty array, the plugin basically doesn’t scan any of your models, aka no work is being done on your models. The reason why it works without the AutoMap decorator in this case is because you assign default value to the property in your constructor (this essentially is almost the same as having AutoMap on).

[PieterBoeren]

1. How do I get the compiled code if the compilation fails (it's Friday afternoon here, so my head is already in the weekend ;))? I can take a look again tonight, but I can't promise anything. Sorry for that.
2. My models do more look like below, I guess that's the same:

class BaseMessageViewModel {
  public id!: number;
  public dateTimeMessage!: Date;
}

[nartc]

It's ok @PieterBoeren . Can you provide a reproduce repo?

I just added date: Date to my plugin test model and it seems to work fine. So there might be some TypeScript configuration that I need to consider for. A reproduce would be the best thing to allow me to pinpoint (and fix) the problem.

[PieterBoeren]

Reproduction repo: https://github.com/PieterBoeren/automapper-transformer-plugin-date-issue

[nartc]

@PieterBoeren Thank you for the repro. I did some investigation and found that when TypeScript encounters Date type, it would try to look up for the type in the globals Symbols. This is where things go wrong (which I'm not entirely sure WHY yet).

The globals object when I run your repo only has 2 records: globalThis and undefined where as the globals object when I run my test (in node environment) has 1000+ symbols. Hence, TypeScript was never able to lookup Date.

Since I don't know exactly the reason why, I can't provide a definitive fix. However, I released 6.1.4 with a workaround to this:

• TypeScript sees Date as a TypeReference instead of DateKeyword (string, number, boolean etc... are seen as StringKeyword and so on), then it does the lookup. That said, the AST still provides the text of the Date type. The plugin will now try to look for this "text" if the lookup fails.
• I also added a null check for val.initializer (which is causing the fatal error)
  d447783

Thank you again for reporting! Keep me updated after you give 6.1.4 a try

PS: I can confirm that your repo compiles successfully with 6.1.4. The following screenshot shows the compiled output of the plugin with someDate has the typeFn: () => Date

[PieterBoeren]

Thanks for the quick fix! I'll test it out on Tuesday.

In the mean time I tried to reproduce this with a standard create-react-app, which also show the same issue with 6.1.3 (and not with 6.1.4). I used "craco" to be able to alter the webpack config, with this recipe, making sure ts-loader sticks to 8.2.0 (since the latest versions don't support Webpack 4 anymore). Don't have time to create a proper reproduction repo, but maybe it helps you further investigate the issue.