feat: update fetch configuration logic

[sublimator]

Superceded by #66

Closes:

• Closes Fix mistral client when using recent node version #42
• Closes Use builtin fetch for Node if exists #60
• Closes Don't override global fetch & fix tests #63
• Closes Using node-fetch makes some Node.js libraries incompatible with this library #44

Update fetch detection logic (See: #63 (comment)):

• Add client._fetch hook point for tests rather than using a global
• Use top level await, per here and here (this won't work in commonjs)
• Use native fetch when available on node
• Support service workers such as manifest version 3 Web Extensions

[fuegoio]

I think here we can remove the condition on isNode and haveNativeFetch as the second part of the condition will catch this anyway

[fuegoio]

I think here we should only use the haveNativeFetch condition no? Is there a case where isNode would be false and haveNativeFetch be false as well?

[sublimator]

Back on laptop :) Thanks for the prodding

const configuredFetch = globalThis.fetch ??
  (await import('node-fetch')).default;

Went with this and killed off haveNativeFetch/isNode entirely by just using feature detection, and adding a comment

// When using node-fetch or test mocks, getReader is not defined
if (typeof response.body.getReader === 'undefined') {

[sublimator]

On mobile/email.

I believe you are correct regarding the logic but it would depend on how offended you are by not reducing as to whether it should be corrected. As I age I find more explicit code easier to work with. A mix of pragmatism and slowing. That said, can change it.

…

Message ID: ***@***.***>

[sublimator]

This should work now in service workers (mv3 web ext), and in newer versions of node with fetch available natively

[sublimator]

Actually, this (top level await) won't work with commonjs (which this library should ideally support in the future)