Trying to redefine Client fetch makes Typescript angry

[fernandocanizo]

I'm trying to capture some authorization headers when using urql and this snippet:

import { Client } from "@urql/core"

const client = new Client({
  fetch: async (...args: Parameters<typeof fetch>) => {
// ...

makes Typescript complain:

error| Type '(input: RequestInfo, init?: RequestInit | undefined) => Promise' is not assignable to type '{ (input: RequestInfo | URL, init?: RequestInit | undefined): Promise; (input: RequestInfo, init?: RequestInit | undefined): Promise<...>; }'. Types of parameters 'input' and 'input' are incompatible. Type 'RequestInfo | URL' is not assignable to type 'RequestInfo'. Type 'Request' is not assignable to type 'RequestInfo'. Property 'duplex' is missing in type 'Request' but required in type 'import("./node_modules/undici-types/fetch").Request'.

I've tried several approaches, however using Parameters<> seems to be the preferred solution. I did a SO post which has more information about things I've tried.

I'm crossposting here because I'm starting to think that this may be related to undici-types and some definition lying deep under urql code.

Anyway, any help in making Typescript happy will be most welcomed :)

[kitten]

Just from a quick glance, if I had to guess, the problems here are either all of or several of:

• the type is an overload of function signatures, and your type doesn't match (judging from the SO post, not all of these signatures will be compatible)
• once it is compatible, the types by undici and by the web-standard fetch diverge slightly
• there's conflicting type definitions (or implicit interface overlaps) that inconsistently apply

Mainly, I'd check why the types aren't overloading/combining/applying in the same way. That being said, to point out the obvious; no matter whether the types conflict, that's a type issue and if you try to solve this by writing a proxy function (be it on global.fetch or the fetch option in urql), I'd pay more attention to how the types have to be cast, if it's infeasible to reconcile the globally declared types rather than the ways (i.e. errors) in which they fail to match.

tl;dr in short, if it's not obvious how to reconcile the declarations in undici, @types/node, and TypeScript's built-in types, then I'd force the issue with either an aggressive, less aggressive, or proper type case instead.