ESM vs CommonJS in your Node Projects

[@GeorgiGrigorov-n5y]

The link for the github repo in the description is empty. Can you please share it with us?

[@covalence-io]

Sorry about that! Link shared

[@Ibrahim-1234]

THANK YOU! Watched the first minute of the video and you already helped solve by bug! God bless you :)

[@Oblivianos]

i dont like adding .js inside .ts files it feels wrong, can we avoid it natively without some tooling package?

[@HappyCheeryChap]

are you using typescript?

[@Oblivianos]

@@HappyCheeryChap whats your first clue?

[@HappyCheeryChap]

@@Oblivianos Mad detective skillz I guess (was tired). I solved this by setting in tsconfig.json compilerOptions: "module": "ES2022", "moduleResolution": "bundler", Allowed me to continue omitting the .exts in the imports. Not sure if it will work which whatever your runtime setup is. I use tsx to execute my .ts node code directly without dealing with emitting .js files at all.

[@Oblivianos]

@@HappyCheeryChap i had module ESNext and module res to nodenext i think as I didnt want to use much or any tooling., long story short i added vite for my react compilation needs and since its a personal project removed typescript and use node's --experimental-strip-types to still have types for intellisense, no build step for my backend, typescript/typescript-eslint/tsconfig2022 removed from deps

[@sr-juhahn]

Hi, trying to get a bit more in this topic as I ignored it completely until now in my professional life. Could you include a view words about the pros and cons with using ESM or CommonJS? That's kind of what I expected from the titel. My current knowledge is only, that ESM supports treeshaking which could reduce your js package. That's why we're considering ESM over Common. But as stated, ESM has some "drawbacks" as the stated, "weird" import statements, less variables in node and so one. Could you clear that topic up a little bit, either with a follow up or just in text form? Thanks already!

[@covalence-io]

If Node were rebuilt today it would most likely be built using ESM first. The fact it was built originally using CommonJS is what causes any and all of the "drawbacks." My guess is that over time more and more NPM packages will choose to support ESM over CommonJS and some may even eventually phase it out altogether. Node may move in the same direction although I feel they'll be supporting both and creating tooling around both for a VERY long time. IMO the main benefit is really just consistency and potential interoperability but there are a few minor benefits having to do with import optimization and code size, but for 99.9% of backends this doesn't matter. At the end of the day, I honestly think deciding between the two is just a personal preference for your development team at this time.

[@jamesalphonse1099]

@@covalence-io Can you link to something more like a udemy course or maybe longer youtube video that goes more in depth on this stuff? I can see what someone is doing on their screen and listen to what they're saying but a lot of times much of what is said goes over my head. I understand synchronous vs async for example, but what does that have to do with require and import statements? People say that CJS and EMS do them differently, but actually how and what is the tangible difference in outcome? No one really ever explains this, they just mention it briefly and expect you to understand. Along with this, there is a bunch of other things that are confusing as well. Tree-shaking, how exactly the target and module work in the typescript settings and why they are two different settings for what seem like what should be the same outcome, which is how node compiles the files... and honestly more I can't even think of. I need some kind of in depth course that will explain all these things and really take the time to show you the differences.

[@covalence-io]

@@jamesalphonse1099 i would recommend checking out our courses at covalence.io. They may not specifically go into everything you mentioned above, but once you're in our community Discord channel, finding out more information about all of this should be easy.

[@NancyLopez-u4o]

5384 Abbigail Mill