-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
new FAQ page: How to use ESM-only packages in Nestjs CJS #3093
Comments
Would you like to create a PR for this? |
@Kimblis looks like your tsconfig doesn't have the expected |
I recently spent a lot of effort trying to use an ES module in a NestJS application. This would have saved me a bunch of time. One thing I would add is that Jest doesn't seem to work with dynamic imports. In my case, I didn't want to test that dependency anyway, so I'm using a mock in its place, but I'm sure others will face situations where their code is working, but they can't test it, because the dynamic import crashes Jest. I don't know what the solution is, but if possible, I think it would be good to add advice on how to deal with this in Jest. |
Should we mention that https://x.com/JoyeeCheung/status/1839312043490578562 as well? |
We faced the same issue and decided to upgrade the entire toolchain using swc, esm and vitest like in https://github.com/AlbertHernandez/nestjs-service-template. Surely not a silver bullet, but that options also exists and is still using nestjs tooling (swc, vitest). |
From time to time people ask on our Discord community about it even tho this isn't exactly a nestjs issue. So I think that it would be good to have this mentioned somewhere in the docs site until we address the PR nestjs/nest#8736.
If we conclude that we won't add this to the docs, I'll publish an article at https://dev.to
typescript users may face several issues when trying to use the
import()
expression to load ESM-only packages in a CommonJS project.example
In a default standard nestjs app (typescript) we just can't do
import superjson from 'superjson';
:the reason is well explained in this StackOverflow answer: https://stackoverflow.com/a/75287028
solution
As mentioned in SO, we can address this is three ways:
moduleResolution
andmodule
in our tsconfig file so thatimport()
won't be translated torequire
import
intorequire
--experimental-require-module
NodeJS's flagAnd the docs we must show both of them because sometimes we can't change the
module
entry.Another issue is that the docs should clarify is that depending on the package being loaded we must access the
default
property (more on this bellow).We should also double-check if those solutions works for Jest/Vitest -- specially regarding mocking features
code snippets
I'm not sure about the best way to show-off the solutions to this yet but I think that we should avoid abstractions so the dev can understand the bare bones and write their own.
Working examples of the approach (1):
Working example of the approach (2):
The text was updated successfully, but these errors were encountered: