Feature Request: have an option omit status OR headers OR both from fetch response

[camillecroci]

Hello !

Context

I started working with Orval 7.1.1. I have written a custom fetch function that was a variation around the provided example:

export const customFetch = async <T>(path: string, options: RequestInit): Promise<T> => {
    // ...
    return { status: response.status, data } as T
}

A recent PR also adds headers to the response.

Problem

The headers of my responses can be quite big and I would prefer not to return them.
It is possible to use the flag includeHttpResponseReturnType to stop getting headers in the response, but it also remove status, which I need.

Feature request

It would be nice to have 2 flags or have includeHttpResponseReturnType being able to be set to none, status, headers. That would allow to have none of them, or only headers, or only status returned.

[soartec-lab]

@camillecroci

Well, we currently offer either the full response or control with a custom fetch.
If you are concerned about the size of the headers, you can solve this by returning a minimal headers object in your custom fetch.
I'd like to wait for other feedback on this issue, as I'd like to understand how many users are concerned about the header size.

[camillecroci]

@soartec-lab thanks for your answer.
My current code is basically a variation of the sample in the library but I return
return { status: response.status, data } as T.

But my generated code looks more like this:

// Type with headers
type ExampleResponseType {
  data: ExampleData | ErrorResponse
  status: number
  headers: Headers
}

// function that has a return type that includes headers
const exampleFunction (): Promise<ExampleResponseType> { return customFetch<ExampleResponseType>() }

// custom fetch that "cheats" by not returning headers
const customFetch () { return { status: response.status, data } as T } 

So its working thanks to the as T but imo it is not really correct, it is a typescript hack

[soartec-lab]

@camillecroci
Yes, the workaround I originally said is as per the code you wrote. Does this mean that you want to strictly improve the type definition?

[camillecroci]

@soartec-lab this work around works fine indeed so there is no emergency. But as T works at compile time, it loses the benefits of static type safety since the runtime object doesn’t match the declared type. Having { status, data } as T omits properties that T claims exist, which can lead to confusion or bugs if anyone relies on headers (or just looks at the types that are generated by Orval that all include headers).

[soartec-lab]

@camillecroci
Okay, so you want to remove as T?