Pure ems bundle prevents node-fetch usage in libraries/frameworks about node-fetch

[darkbasic]

I closed the issue because I decided that it wasn't going to achieve anything at the end of the day and I didn't want to be controversial for no reason, but since you've answered I'll tell you my view.

I guess you don't provide cjs because of dual package hazard concerns. While that is true you also suggest to use async imports in a library which is going to output commonjs code. Even if we don't consider the fact that this is only viable in async contexts, that same hazard exists for esm-only packages that get imported in commonjs projects via async imports so your suggestion goes against the reason why you decided to bundle pure esm in the first place and my library could bite other users because of that!
Also in my case the whole graphql ecosystem bundles dual packages and thus using instanceof is already a big hazard (let's not talk about yarn link which creates a similar issue).
The developer experience for esm modules on Typescript is still suboptimal because importing commonjs modules with default exports is a mess and the js extension in the imports is counterintuitive to say the least.
I personally think that it's still too early to target pure esm in a library but at the same time you cannot ignore deno/bun existence so dual package is the lesser evil. Just my two cents.

[jimmywarting]

You can use async import to load esm modules in cjs
#1279