Why the switch to ESM?

[immjs]

Looking around the issues and discussions, I see none that seem to tackle the question, if there are I'll gladly look into them.

So, why? Why the switch to ESM when ESM is backwards compatible? Using CJS would have been painless for people who code in CJS. I might find myself rewriting all of my code because it is recommended to switch to ESM.

Moreover, this doesn't seem to affect ESM users positively, if at all.

So yeah, why did the switch happen?

_{I'm sorry if the message might sound arrogant or unthoughtful, it has been lingering in my mind for a bit now, but I truly want to understand.}

[jimmywarting]

ESM is a standard, cjs isn't. That is mostly it.

If we could influence more ppl to switch to writing ESM instead of cjs then that would mean that more code would also be more cross compatible with Deno and also browsers. Writing things as a ESM also allows for HTTP import without the need for local package manager where only NPM has the monopoly.
ESM is also strict about path resolution requiring you to write full explicit path such as ../index.js instead of just ../ or ../index cuz remote HTTP import can't scan the file system for the correct path/file to load instead of having to scan the folder of what file you meant to import which i think is a good thing. Ryan Dahl (founder of nodejs and deno) thought it extension-less and index files where a neat feature but it later regretted his design decisions. and i agree with him that it was bad. it's not how the web "works"

ESM have other features that cjs do not such as top level await
Also if you think about ESM and how it imports files in the web it makes it seemingly easier to import other dependencies cuz it's relative to the remote file and not to the websites domain. so CDN imports are much more easier. anyone knows this that have had a dependency on some CDN library that sometimes sets up a web worker and done something like:
new XYZ({ assets: 'http://cdn...' }) now you can just write something like new Worker(new URL('./worker.js', import.meta.url))

ESM is going to be the new facto way of writing modules in the feature. So it's just about sucking it in and start emprising it. The newer updated nodejs docs also shows ESM flavored syntax now.

Now i know node-fetch is written exclusively for NodeJS programs only so it could as well have been written in cjs flavored syntax but we wanted to embrace standards, work with web standards and not have to deal with down leveling from esm to cjs with build tools such as babel or rollup. we felt that a dual package with both cjs & esm support was a hazard. and it is: https://nodejs.org/dist/latest-v18.x/docs/api/packages.html#dual-package-hazard
if one package where to load node-fetch as cjs and another dependency loaded it as esm than the readable stream would not be the same instances and you would not be able to pipe data from a cjs readable stream into a esm writable stream cuz you now have two types of classes that aren't the same. eg: require('node-fetch').Blob === (await import('node-fetch').Blob so we decided against a dual structure. + it allowed us self to import other modules that being written in ESM (mostly by myself) such as the formdata and blob package that where already written in ESM flavored syntax.

We spoke about making the switch to ESM for a long time before making the switch and everyone involved in node-fetch was onboard with it at the time and nobody was against it when we decided to write it as ESM and starting to ditch babel. it wasn't singly one sided goal cuz everything we do here is being reviewed by other members before being merged. and you can't review/accept your own PRs.

[jimmywarting]

Also want to point out that you do not have to rewrite everything into ESM, you can still load ESM modules from cjs using async import (due to its nature of how esm modules are loaded)

// index.cjs
import('node-fetch').then(...)

alternative you could just update to newer NodeJS version (18+) that now has fetch built in.

[GabenGar]

Strong doubt you "code" in CJS, chances are you are writing "ESM" (syntactically invalid ESM, but it's okay because the transpiler will gobble it up anyway) code and CJS is merely an implementation detail of the build step. Kinda strange to expect a package implementing one of the ECMAScript spec features not to eventually follow the module system of ECMAScript.

[jimmywarting]

Strong doubt you "code" in CJS, chances are you are writing "ESM" (syntactically invalid ESM...

What do you mean by that? can you give an example?

[GabenGar]

Any code having require() and import statements in the same file. It is basically written under assumption that a bundler will transpile imports away and thus leaving CJS resolving logic only. Which gets broken once the bundler is set up to output ESM, thus leaving the imports in, which subsequently get rejected by NodeJS running in ESM mode.
Don't have examples atm, because it's mostly related to build artifacts, but next-i18next was outputting ESM like this and it was crashing when trying to run tests against ESM bundle.

[immjs]

..... right but thay doesn't make all CJS code invalid

EDIT: Also I doubt anyone actually codes like this, as I have never done it myself.