-
-
Notifications
You must be signed in to change notification settings - Fork 7.6k
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
ESM support #13319
Comments
that's not a good argument tho.
you can use ESM-only packages in CommonJS projects just fine. It's a nodejs feature, not related with nestjs. See #8736 |
This comment was marked as off-topic.
This comment was marked as off-topic.
https://github.com/wooorm/npm-esm-vs-cjs more and more are moving to ESM, inconvenient to use more and more |
What about migrating to esm is so hard? I mean the way has already been paved with: Benefits of esm modules are:
For me and my team it's a dealbreaker if there is no support for esm with nestjs as we don't want to work our way arround this package or monkey patch everything. Thanks for the effort and in advance |
More packages use commonjs than esm atm. You can still use
Using Nest in the browser makes zero sense
CJS was the standard way of doing modules for 10 years and it's not going anywhere
What use case does it cover which is not already covered by Nest?
It hurts us as it adds a significant maintenance burden. Maintaining both is a huge waste of time and we can't yet drop support for CJS as it would hurt lots of NestJS users all around the globe.
@magicdawn this graph isn't accurate, see wooorm/npm-esm-vs-cjs#9 Also, in the latest version of Node.js (should be backportable to v20) you can |
Completely understand that this is not going to change in the short term and the arguments made by @kamilmysliwiec are very valid. Given this is a 'batteries-included' framework though there is a slow erosion of the framework's simple config premise occurring with more and more community packages migrating. Whatever the exact statistics of the state of the current ESM / CJS split - anecdotally at least - it seems to me packages that are actively maintained and thus more likely to be consumed are migrating or considering migrating in increasing numbers. Eg. A little while back I a added markdown parsing service via So adding newer packages; be it to get new APIs, patch vulns, meet node compat requirements whatever will push more packages down this route. Perhaps the answer is to simply lean on node's |
I'm not saying we will never migrate - I'm just trying to emphasize it doesn't seem reasonable atm. |
Okay, never mind, it is just one more step in the right direction I guess. |
nestjs version: |
We are about to abandon NestJS for lack of ESM support. More and more packages are ESM only (lucia, superjson) and they simply do not work, even with hacks. It's unfortunate really, nestjs is a great framework but becoming more of a headache than it's worth. |
Is there an existing issue that is already proposing this?
Is your feature request related to a problem? Please describe it
Some modules does not support old commonjs modules. We are stuck on older versions.
Describe the solution you'd like
Move to ESM, it is 2024
Teachability, documentation, adoption, migration strategy
Flawlessly
What is the motivation / use case for changing the behavior?
Standardize as many things among the world. Less diversity in questions that are almost the same leads to simplicity and less learning, kind of optimization. This is similar problem like in some countries people don't use standardized measuring system and there is different time date format for every country.
The text was updated successfully, but these errors were encountered: