Union type for error disappears in typescript-fetch v0.10

[zaru]

Description

The union type for the error object returned by fetch has changed in typescript-fetch v0.10 and later versions.

Reproduction

I updated typescript-fetch to v0.10.1.

After the update, the type inference for the error object returned by fetch changed as follows:

Before v0.9.7

• const error: { message: string } | Record<string, never> | undefined

v0.10.0 and Later

• const error: { message: string } | undefined

OpenAPI YAML

I change the error response based on the type of error. For example, in the case of a 404 error, only a message is returned. For a 422 error, error messages are returned for each field.

# Partial YAML
      responses:
        '404':
          description: NotFound
          content:
            application/json:
              schema:
                type: object
                properties:
                  message:
                    type: string
                required:
                  - message
        '422':
          description: Bad parameters
          content:
            application/json:
              schema:
                title: ''
                type: object
                properties:
                  errors:
                    type: object
                    properties: {}
                required:
                  - errors

Expected result

It would be great if the error type could be the same as in previous versions:

const error: { message: string } | Record<string, never> | undefined

Checklist

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

[drwpow]

This was an intentional change in 0.10.0 that stemmed from some changes in how the error union was formed.

It’s now an approach for errors where it’s “take the first you find” because many schemas have a single defined error type, and some other responses being null or an impossible union. That seemed to be a more common pattern than different response codes returning a completely different error shape. i.e. many error responses are unintentional/accidental,

data was kept as a union because typically those are more intentional by comparison, and the union is something handled.

Unfortunately there’s not really a way to make both behaviors work—either keeping the error union results in many schemas being unusable because of irreconcilable unions. Or keeping this “take the first match” behavior results in some error types being left out. But this change felt safer because the worst case scenario is “represent one shape correctly” rather than “misrepresent all shapes incorrectly.”

Removed the bug label, but happy to gather feedback from people, or possible solutions that make both scenarios easier for people. At its root it’s just multiple conflicting approaches to schema design, neither being “right” or “wrong.”

[dusty]

Would this change effect non-errors? I tried upgrading today and noticed a similar problem. We have an API endpoint that takes a PATCH.

On updates it returns an empty 202.

However, if a 'complete' property is sent as true, then it returns a 200 with a body of a particular shape.

I found that the data property of this response was set to never. Even if I were to check the response status to differentiate between 200 and 202, it was still never.

eg: this didn't work

if (response.status === 200) {
  console.log(response.data.something)  // ts error on something
}