Non-nullish data field

[musjj]

Description

I'm using openapi-fetch with ky

import ky from "ky";
import createFetchClient from "openapi-fetch";

const fetchClient = createFetchClient<paths>({
  baseUrl: "https://example.com",
  fetch(input) {
    return ky(input);
  },
});

One of the nice things about ky is that it raises an exception on non-2XX responses. This means that if a fetch call succeeds, response data is always guaranteed.

But the type system doesn't know this:

const response = await fetchClient.GET("/foo/{id}", {
  params: { path: { id: "foo" } },
});
response.data?.id // the types thinks that data may not be present

Proposal

I'm not sure what's the best way to go about it, but maybe there could be an option?

import ky from "ky";
import createFetchClient from "openapi-fetch";

const fetchClient = createFetchClient<paths>({
  baseUrl: "https://example.com",
  nonNullData: true, // <-- `data` will always be non-null
  fetch(input) {
    return ky(input);
  },
});

But it does feel a bit footgun-ish. Maybe we could also have another mini-library, something like openapi-ky as a wrapper.

Extra

• [ ] I’m willing to open a PR (see CONTRIBUTING.md)

[drwpow]

That’s a good suggestion. Tracking this as part of the 1.0 roadmap. The other maintainers and myself talked this week about what a 1.0 looks like, and long story short we’ve really hit the limit with what’s possible with pure static type inference (in a good way) and we get lots of input like yours that having a still-light-but-a-little-bit-more-runtime-aware wrapper would be beneficial.

While I don’t know yet that we’d support an openapi-ky wrapper per se, I do think we are strongly considering the direction where we make it easier for people to build their own wrappers