@xxczaki
This logic should also be adjusted

@Richienb, @LinusU could you review this?
looks finish

@gr2m

Did you test that the import of node-fetch is working for you? I'll try to give it a try myself

No i haven't tested node-fetch but i have tried out formdata-polyfill and fetch-blob that is a ESM only pacakge. They are ESM only package and only have a main

the fetch-blob package have stuff like: fetch-blob/from.js and fetch-blob/file.js
formdata-package has formdata-polyfill/esm.min.js, formdata-polyfill/formdata-to-blob.js that you can import/use aswell

Small side note: don't really like the look of this import mapping: "./response": "./src/response.js"
Just so you can get rid of src
NodeJS is adding support for http loader so you can load a package without using NPM, think it would be missleading if we recommend (in the readme) that you can use node-fetch/response when you sould actually be using .../node-fetch/src/response.js when using a http loader instead.
Browser and Deno do not have support for NPM packages, they can only load other packages using urls. so you should not keep changing filename and moving files around much...

so my reasoning is: don't mess with exports property in package.json if you are going to support loading a package/module that can work for both Browser, Deno & NodeJS using http loader

Alldoe it could be a good idea to do something like "exports": "src/*"

I won't die on my exports with explicitly defined exports hill 😁 If you feel strong about leaving main let's do that and see how it goes. It's a problem when it's a problem, we shall find out.

I don't have so strong feelings for it either. (even doe it might sound like it)
but yea, "It's a problem when it's a problem" then we will fix it