Type inferrence and optional clients

[saska]

Hey,

Prefacing this by saying not a the biggest typescript expert.

Using @hey-api/client-fetch, the generated functions are of the form (client generated with openapi-ts -i openapi-schema.json -o client/ -c @hey-api/client-fetch)

export const foo = <ThrowOnError extends boolean = false>(options: OptionsLegacyParser<fooData, ThrowOnError>) => {
    return (options?.client ?? client).post<fooResponse, fooError, ThrowOnError>({
        ...options,
        url: '/foo'
    });
};

which typescript can't infer the return type of (just gives any, ts 5.6.3, also tried with 4.9.5). Using latest on both (@hey-api/client-fetch==0.6.0, @hey-api/openapi-ts==0.61.1).

Possible avenues:

1. Should inference work out of the box and I'm just doing something wrong?
2. Is there a documented way to do this without type assertions or the like that I'm missing?
3. I don't really need to have a default client (or I guess can modify the default and not provide one), so is there a way I could e.g. generate something along the lines of the following snippets?

import { createClient, createConfig, type OptionsLegacyParser, Client } from '@hey-api/client-fetch';

export const foo = <ThrowOnError extends boolean = false>(client: Client, options: OptionsLegacyParser<fooData, ThrowOnError>) => {
    return client.post<fooResponse, fooError, ThrowOnError>({
        ...options,
        url: '/a'
    });
};

export const foo = <ThrowOnError extends boolean = false>(options: OptionsLegacyParser<fooData, ThrowOnError>) => {
    return client.post<fooResponse, fooError, ThrowOnError>({
        ...options,
        url: '/foo'
    });
};

[mrlubos]

@saska Hi, the easiest way for me to see would be to have a reproducible example in StackBlitz, but I'd also suggest turning on the experimental parser with -e and see if that helps by any chance

[saska]

Didn't do anything; I could at least try and produce a minimal example of an openapi schema if the expected behavior is for inferrence to just work?

[saska]

Or do you think it's more likely a problem somewhere else in the setup?

[mrlubos]

Reproducible example would work best. Do you have @hey-api/client-fetch installed in your dependencies?

[saska]

Found the issue after trying to replicate in a fresh env; the DOM defs are apparently necessary for something somewhere and were excluded in our original config. So changing

{
    "compilerOptions": {
        ...
        "lib": [
            "ES2022"
        ],
        ...
    }
}

to

{
    "compilerOptions": {
        ...
        "lib": [
            "ES2022",
            "DOM"
        ],
        ...
    }
}

fixed the issue.