Support for CommonJS in @automapper/nestjs after migration to ESM

[mstaniewski]

Hello,

Since NestJS is CommonJS only, how should we properly consume @automapper/nestjs after migrating to ESM?

The package documentation seems outdated and doesn't provide clear guidance on ESM compatibility.

I attempted to follow the NestJS example, but it didn’t work for me.

Currently I'm struggling with it as importing AutomapperModule from nestjs package results in:

Also tried with async imports, but no luck too

Are there any updated instructions or recommendations for using this package in an CmoonJs-based NestJS project?

Thanks!

[KyryloKupin]

Hi @mstaniewski,

I encountered the same problem. Updating my tsconfig.json to use

{
  "module": "CommonJS",
  "moduleResolution": "Node10"
}

resolved the issue. Hope that helps!

[coderatchet]

@KyryloKupin backpedaling all the advances of modern node module resolution to support a single library and lock yourself into a sub-standard algorithm doesn't quite sit right with me.

I'm keen to hear from the developers about how this could be resolved, My hunch is that there is potentially an issue with type imports being resolved to the ./src/index.d.ts directory of each folder, and the differences between nodenext and node10/bundler means that the proper definition is not found in the root index.js module file.

I'm still deep in typescript config documentation trying to get a better understanding of the module/moduleResolution attributes as their configuration is quite complex. I'll be coming back here to see if someone has solved this issue, otherwise I'm forced to use

{
  "module": "ESNext",
  "moduleResolution": "bundler"
}

Which appears to respect the import as well as support the "imports"/"exports" properties, even though I'm not bundling anything in my project for a web application.

[KyryloKupin]

@KyryloKupin backpedaling all the advances of modern node module resolution to support a single library and lock yourself into a sub-standard algorithm doesn't quite sit right with me.

I'm keen to hear from the developers about how this could be resolved, My hunch is that there is potentially an issue with type imports being resolved to the ./src/index.d.ts directory of each folder, and the differences between nodenext and node10/bundler means that the proper definition is not found in the root index.js module file.

I'm still deep in typescript config documentation trying to get a better understanding of the module/moduleResolution attributes as their configuration is quite complex. I'll be coming back here to see if someone has solved this issue, otherwise I'm forced to use

{
  "module": "ESNext",
  "moduleResolution": "bundler"
}

Which appears to respect the import as well as support the "imports"/"exports" properties, even though I'm not bundling anything in my project for a web application.

@coderatchet this limitation stems from NestJS's default CommonJS-only support and isn't specific to this library. For more details, see NestJS issues #13319, #13817.