What to you think about adding this bootstrap approach as a way of loading a ESM package from a complete legacy commonjs codebase?

// bootstrap.js
import('node-fetch').then(({
  default: fetch,
  Headers,
  Request,
  Response
}) => {
  globalThis.fetch = fetch
  globalThis.Headers = Headers
  globalThis.Request = Request
  globalThis.Response = Response
  require('./app.js')
})

Shorter version:

// bootstrap.js
import('node-fetch').then(({
  default: fetch,
  ...rest
}) => {
  Object.assign(globalThis, rest, { fetch })
  require('./app.js')
})

This had me thinking... can you use preload?

-r, --require module#

Preload the specified module at startup.

If you're going to assign globals within an asynchronously executed function, then you might as well just await it and get the values that way:

const {
  default: fetch,
  Headers,
  Request,
  Response
} = await import("node-fetch")

This would be best executed within asynchronous functions since CommonJS does not support top-level await.

I where thinking about linking to https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c but it seems highly debatable about good and bad things and includes a few negative comments.
It's a very good guide. I almost wish it was locked and had all some comments removed... i wish it was targeted more at a general scale and didn't had so many comments about Typescript, React vs Javascript comments

There is also a few forks worth mentioning: https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c/forks

We also have: https://blog.sindresorhus.com/get-ready-for-esm-aa53530b3f77 and https://blog.sindresorhus.com/hello-modules-d1010b4e777b

@Richienb i fixed all your suggestions, please have another look

is 40 lines of documentation what's preventing us from making v3 stable?

is 40 lines of documentation what's preventing us from making v3 stable?

kind of... this is the only thing left in the v3 milestone
ppl have had concerns/problem importing pure ESM package in beta-10. This address those problem + the docs where a bit outdated

Only need 1 more acceptances from one of the maintainers and then we can release/tag v3 as stable

...Feels like some of the maintainers don't have much time or interest anymore that's why updates comes so rarely
Should maybe invite new maintainers