Optionless endpoints still require 2nd param

[drwpow]

For simple endpoints that don’t require any parameters or requestBodies, the 2nd param is still required:

import { paths } from './v1';

const { get } = createClient<paths>();
get('/self');
// ~~~~~~~~~~
// ^ Expected 2 parameters, but got 1.

The solution is adding an empty {} to the call, like so:

- get('/self');
+ get('/self', {});

This is because it’s an intersection of { params: … } & { body: … } & RequestInit, which are all required options, but in some scenarios end up having all keys optional which results in an empty object ({}). However, if we make the root types always optional, then the types break, and this library would be pointless.

If there’s a way to solve this without jeopardizing the types, PRs are welcome!

Though note that this is only a cosmetic issue. There are no actual performance or runtime bugs with providing an empty object as the 2nd param.

Counterpoint to fixing: Many APIs won’t have any endpoints with absolutely zero parameters. For the schemas that do, only a few endpoints realistically will deal with this. Further, simply having the 2nd param there can reduce Git diff noise if/when options are ever needed to be passed to that endpoint.

[yinzhenyu-su]

Hello, I have found that using openapi-typescript is a fantastic library that has greatly assisted me in my work. I have also experienced the similar issue you mentioned earlier. Hopefully, my solution can be helpful to you. Please refer to this link for my solution: https://github.com/yinzhenyu-su/api-typing/blob/3ba2c3e7e3ee278d54df46c36de6c501fc943bfa/src/core-type.ts#L131

[drwpow]

@yinzhenyu-su yes thank you! That helped me fix some type bugs in the 0.1.0 release. There are still a few instances where this happens, but I think we can fix this easily in an upcoming release.