`setConfig` can break types

[not-my-profile]

This is as expected since changing a parameter value cannot magically change the type of previously initialized variables. However with this in mind I think responseStyle should be omitted from setConfig for the sake of type safety.

[mrlubos]

Did it trip you up @not-my-profile? It's tricky because there are multiple options that alter types in runtime (eg. interceptors). I chose to give you the flexibility over type correctness, but open to hearing arguments against it

[not-my-profile]

Not really I just noticed it as unidiomatic in TypeScript. With interceptors I'd also expect type mapping to be possible but for the mapped types used for the client creation to make it into the generic type parameters of the client so that with setConfig you can later only set interceptors with the same return type. TypeScript is able to infer the generic type parameters:

class Mapper<A, B> {
  mapFn: (a: A) => B;

  constructor(mapFn: (a: A) => B) {
    this.mapFn = mapFn;
  }

  map(input: A): B {
    return this.mapFn(input);
  }
}
const mapper = new Mapper((s: string) => s.length);
let num = mapper.map("hello")
console.log(num); // 5
mapper.mapFn = s => s.length * 2;
num = mapper.map("hello")
console.log(num); // 10

// @ts-expect-error
mapper.mapFn = s => s;

[mrlubos]

Yeah, it's a trade off. I think you should be able to fix the reported issue if you pass and use the same client instance everywhere in the app, eg. setConfig would return the new instance.

Otherwise, you're working with a client that can have side effects applied to it anytime, from anywhere. There's no way to improve types as far as I know.

Are you passing around a single client instance in your app?

[not-my-profile]

Your reply is confusing me. setConfig does not return a new client instance, I think it modifies the config instance and would assume it then returns the same instance.

There's no way to improve types as far as I know.

I don't see any problem with improving the types?

Are you passing around a single client instance in your app?

Currently we're just using the generated client instance but this issue is not about our setup but about your API.

[mrlubos]

I'd be open to a pull request improving this!