node-fetch unusable with esm package

[michael-lloyd-morris]

Given an index.js file with import fetch from "node-fetch"
When I run cli command node -r esm index.js
Then I should see the script import fetch and run.

Version 3 gives this error.
 at Object.Module._extensions..js (internal/modules/cjs/loader.js:1080:13) {
 code: 'ERR_REQUIRE_ESM'
}

Now, I've read the similar threads on this. One thing that hasn't been mentioned, that the maintainers overlook, is there are still MAJOR projects out there that can't be used with ESM directly. Cucumber.js is one of them. The top level project must be CJS for cucumber to work, but you can convince it to work seemlessly with the ESM package.

[jimmywarting]

Hi.

The top level project must be CJS for cucumber to work

I don't know much about cucumber but they have announced that they have experimental support for esm https://github.com/cucumber/cucumber-js/blob/main/docs/esm.md

Could you take a look in #1279 if you find some helpful solution/workaround?

Also, have you taking it up with cucumber that you have problem to import node-fetch or any other esm-only module?

[michael-lloyd-morris]

I'm trying to get up to speed to actually contribute code on the Cucumber project, and ESM support is one of the branches I'm following to get a feel for what needs to be done. So I'm aware of the ticket and the problem that the Cucumber test library needs the project to be CJS to run correctly unless node is ran using the esm package.

I don't expect any maintainer to test everything in the wild, that's why I filed a bug. If you aren't interested in maintaining interoperability with other projects that's your prerogative.

Honestly, if you're going to do such a break it would be better to follow the path the moment.js team did - they created a new package named luxon.js and marketed moment as bug-fix only. In a similar manner you could make a new package node-fetch-esm and declare the current branch as entering a bug fix only phase with no new features, also set an end of life for the project around 3 to 5 years out from now.

[mattkrick]

Would you be open to v2 having feature parity of v3 but compiled down to cjs?
Making the business case to migrate an entire app to ESM is difficult.

I'm OK with sticking the v2, but would love to get typescript typings backported to that version.
@types/node-fetch is just a stub at ^3.0.0 and at 2.5.12 it had bad typings for the AbortController.

I'm afraid if it's not usuable, it'll just divide the ecosystem, we'll have a handful of packages published like node-fetch-usable and one of them is bound to have a security vuln.

[jimmywarting]

We can't possible bring everything from v3 to v2 as some stuff would be breaking.

[tenbits]

We were also forced to downgrade to v2 due to this issue. Why you don't consider to build the library to a single file? This would increase the load performance, compatibility and decrease the size of the library.

[jimmywarting]

Why you don't consider to build the library to a single file? This would increase the load performance, compatibility and decrease the size of the library.

It's not beneficial, read this thread #1227

[tenbits]

This is extremely opinioned position, which shouldn't be the case for the lib, as both should be supported, while they are and will be both first-class module systems. A consumer should be able to use the library disregarding of which module system he/she uses. This is even disrespectful to those, who for any of the reasons use cjs.

[mattkrick]

We can't possible bring everything from v3 to v2 as some stuff would be breaking.

I could be wrong, I often am, but if the choice is between a breaking change in a minor version and having 2 unusable versions, i'd vote for breaking semver once.

[mariusa]

In a similar manner you could make a new package node-fetch-esm and declare the current branch as entering a bug fix only phase with no new features, also set an end of life for the project around 3 to 5 years out from now.

That's why we have major versions. Can't create a new package every time something major changes.

there are still MAJOR projects out there that can't be used with ESM directly

Use node-fetch 2.x then

I just migrated a small project to ESM and happily using node-fetch 3.x. node-fetch is usable with esm. Not sure why this issue was reported / is still open.

[jimmywarting]

we also have similar cjs/esm issues open that are basically a dupl of this, so closing this one...
There isn't any issue with node-fetch itself
This (now) ESM-only package works as intended. if you have a problem with using ESM-only packages or any other solution highlighted in #1227 then it's really up to you to fix it

There is also a discussion about having a exposed cjs file that only export fetch (not headers, Response and Request)
that is related to this: #1327