Repository navigation
Should MaybeOptionalInit really be an Array type? #1908
Description
Description
In the type definition of ClientMethod, init parameter is a rest parameter (...init), and its type is MaybeOptionalInit<Paths[P], M>, which is an Array.
However, when this type is used, in createClient, only the first element is ever used in the return value.
For example:
/** Call a POST endpoint */
POST(url, init) {
return coreFetch(url, { ...init, method: "POST" });
},This is because init in the implementation of POST (and of all the other methods) is not a rest parameter, and so it only captures the first value.
The MaybeOptionalInit is actually always an array of 1 element (and the type is defined as such). However, when the type is captured, it's not obvious in all contexts.
Reproduction
It's a type issue, so it nothing happens at runtime.
Expected result
MaybeOptionalInit looks like it could be a simple value, not an Array. It would make it easier to capture the types of the parameters when wrapping the Client object into a decorator.
Checklist
- I’m willing to open a PR (see CONTRIBUTING.md)
Activity
drwpow commentedon Sep 12, 2024
See this comment here: the array is just a type trick to determine whether or not the 2nd param is required for GET requests:
openapi-typescript/packages/openapi-fetch/src/index.d.ts
Line 162 in fdc6d22
It’s basically an alternate method to declaring function overloads for GET, which would result in more complex inference. It’s not actually an array; it’s just a way for TS to not require you putting
undefinedas the 2nd param.I’m not sure what the issue is; this seems more like a discussion so I’ll move it there. But If I’m missing something please let me know! And/or providing a failing test would be helpful.