Allow client option for custom dispatcher into fetch requests (e.g. to disable certificate validation) about openapi-typescript

[drwpow]

Thanks for opening, but can you describe what a “dispatcher” is? Is this a concept from another library? Why won’t the custom fetch or middleware work? What prior art are you referencing?

I’m not opposed to adding this, but I want to be 100% sure before we commit to adding breaking changes to the API there’s not a simpler solution to solve the problem (and I do not understand the problem)

[mellster2012]

Thanks for the comments!

• Previously you could provide an Agent to override default configurations, such as not failing on self-signed certificates. Node's global fetch does not use the http/https stack, but an internally wired undici client and you cannot replace the global agent easily, see here: https://stackoverflow.com/questions/73817412/why-is-the-agent-option-not-available-in-node-native-fetch
• Replacing fetch with a custom implementation is a much larger change than providing a custom dispatcher - which is an undici specific Agent different from Node's http(s) Agent. Also we've ran into signature issues/incompatibilities when swapping out fetch. So this seems like the simplest solution (as suggested in the linked SO thread above) to pass custom configurations.
• We already forked openapi-fetch for this, there must be many others with the same need. AFAIK adding an optional dispatcher to the configuration option should not be breaking changes to the (public facing) API, but I could be wrong.

[mellster2012]

There actually seems to be an option to modify the globalFetch Dispatcher:
globalThis[Symbol.for('undici.globalDispatcher.1')] = yourDispatcher;
Will verify this. You can just reject the reworked (according to your comments) PR at (#1636) if you think it's not useful enough, but the above is certainly a bit of a hack and I would prefer the option to inject a dispatcher per client.

[mellster2012]

The above doesn't work, neither does setGlobalDispatcher, so we will still rely on our fork in the meantime. Note that you can also pass a dispatcher as init parameter to fetch, however openapi-fetch does discard this additional parameter here:
let response = await fetch(request); with

ObjectDefineProperty(globalThis, 'fetch', {
    __proto__: null,
    configurable: true,
    enumerable: true,
    set,
    get() {
      function fetch(input, init = undefined) {
        // Loading undici alone lead to promises which breaks lots of tests so we
        // have to load it really lazily for now.
        const { fetch: impl } = require('internal/deps/undici/undici');
        return impl(input, init);
      }
      set(fetch);
      return fetch;
    },
  });

where init can take a dispatcher object.

[mellster2012]

Specifying a custom fetch is tricky as the globalFetch does not use undici's exposed fetch method, so you have to do what node does and require the internal dependencies which necessitates the --expose-internals flag (or write it from scratch):

function fetch(input: any, init = { dispatcher }) {
  const { fetch: impl } = require('internal/deps/undici/undici');
  return impl(input, init);
}

[mellster2012]

Ok so this does work, still not really clean, but using this override plus ts-expect-error providing a custom fetch is sufficient.

function myFetch(input: RequestInfo) {
  // @ts-expect-error 'dispatcher does not exist in type RequestInit'
  return globalThis.fetch(input, { dispatcher });
}

Feel free to close this and the related PR at (#1636), or modify the proposed changes as you see fit. Thanks!