test: add type test for HttpResponse.error

[jacquesg]

No description provided.

[jacquesg]

As expected, the CI is failing now due to the type error :)

[kettanaito]

Thanks for writing the tests, @jacquesg!

I think this hints at a more fundamental issue with how we annotate responses in MSW. See, this is the underlying type that everything depends on:

msw/src/core/handlers/RequestHandler.ts

Lines 38 to 45 in 7cf34c1

	export type ResponseResolverReturnType<
	ResponseBodyType extends DefaultBodyType = undefined,
	> =
	| ([ResponseBodyType] extends [undefined]
	? Response
	: StrictResponse<ResponseBodyType>)
	| undefined
	| void

And it expects a ResponseBodyType which is of type DefaultBodyType. For ResponseResolverReturnType to produce a non-strict, regular Response, the response body type argument must be undefined, which is valid per the DefaultBodyType type.

The issue happens when the response body type is supposed to be a union of types, like in case of GraphQL responses:

• Either a strictly typed GraphQL JSON response;
• Or a generic Response returned by Response.error().

I don't believe that type likes the union as the argument. We also don't teach it how to handle unions by doing something like X extends [undefined] or other dark TypeScript magic.

---

Here's an isolated playground.

[kettanaito]

We can implement a fix like so and it will work.

It creates a different problem violating this expectation:

msw/test/typings/graphql.test-d.ts

Lines 97 to 103 in 7cf34c1

	it('graphql query does not allow incompatible response body type', () => {
	graphql.query<{ id: string }>(
	'GetUser',
	// @ts-expect-error incompatible response body type
	() => HttpResponse.text('hello'),
	)
	})

Because the union produced to support Response.error() (return type of which is Response) now lets the HttpResponse.text() return type to pass even though its [bodyType] type is incompatible (it matches the generic Response type and since it's allowed, makes TS happy).

Preventing wrong mocked responses on the type level is a great feature to have. Unfortunately, Response.error() returns a generic Response type that cannot be discriminated against. This makes it impossible to tell apart a generic response type and an non-matching HttpResponse.* type because they come down to a generic Response anyway.