Hi, @phryneas. Thanks for opening this!

It would help a lot if we started from the intended usage experience. How do you see people using MSW to mock queries done via the GraphQL-over-HTTP spec? Let's design the ideal usage and then work down from there to see what implementation that would require.

From my limited understanding, all that should happen is that mocked responses from graphql.* handlers should now contain the content-type: application/graphql-response+json header. Does anything else change for the developer who wishes to mock that standard?

Update

Thanks for proposing this, @phryneas. I've refactored your approach, added tests, and now they are passing. Here's an overview of what I did.

• Removed GraphQLHandler options (not a fan of options).
• Refactored getAllAcceptedMimeTypes to adhere better to the RFC.
• Removed resolver wrapping and instead extended the run() method to patch the mocked response, if any, there.

The behavior regarding the content-type and accept headers is now as follows:

1. If request provides no accept, mocked responses are application/json.
2. If request provides accept and lists application/graphql-response+json as the only header, mocked responses are application/graphql-response+json.
3. If request provides accept and lists both application/graphql-response+json and application/json;q=0.9, mocked responses are application/graphql-response+json.
4. If request provides accept and lists both application/graphql-response+json;q=0.9 and application/json (the new mime type with lower priority), mocked responses are application/json.

The response content type is fully controlled by the client, never the mock. The mock is basically a server and it responds with whatever content type the client says it accepts and prefers.

@phryneas, could you give this change a quick review to see if it complies with the expectations behind the new content type header? I'd be most grateful!

It generally looks good, but as you removed the GraphQLHandler options, it's now impossible to mock an "old" server that didn't support application/graphql-response+json.
I'm not sure if that's good. In some tests you might want to test both a server that's not capable of the new format and a server that is, since responses from them are interpreted slightly differently.

One additional question I have after re-reading this after all that time: is it possible to mock these responses with a different response code? Where application/json can only respond with 200, application/graphql-response+json can also respond with other HTTP status codes, and tests might want to test for that.

it's now impossible to mock an "old" server that didn't support application/graphql-response+json.

You can always do that by providing an explicit content-type headers on the mocked response though.

graphql.query('GetOldServer', () => {
  return HttpResponse.json({
    data: { ... }
  }, {
    headers: {
      // Regardless of what the client accepts, use this mime type.
      'content-type': 'application/json'
    }
  })
})

We just need to add a check for explicit content-type header and skip the decorating logic altogether. WYSIWYG when it comes to mocked responses, MSW must never override your choices.

One additional question I have after re-reading this after all that time: is it possible to mock these responses with a different response code? Where application/json can only respond with 200, application/graphql-response+json can also respond with other HTTP status codes, and tests might want to test for that.

This again sounds like what you should do in your handlers. MSW will not interfere if you decide to respond with a different status for your application/graphql-response+json responses. I think there's a false assumption that MSW is "smart" and should handle all inputs like the server does. It shouldn't. It's your network boundary and you model it to behave as you wish. Whatever you have in your mock is the truth, and you use that to reproduce different scenarios.

It's the same mental model as when it comes to putting business logic in your handlers. Don't.

it('handles unauthorized users', () => {
  server.use(
    http.get('/resource', () => {
      // Any request will be unauthorized.
      return new HttpResponse(null, { status: 401 })
    })
  )
})

You don't check for what request is. You always say "this is an unauthorized behavior branch". If you so choose to bring logic to your handler, you always can, but MSW won't try to guess anything for you.

With those responses, approved ✅

Alright, pushed test + support for ignoring this logic when an explicit content-type is set on the mocked response so you can simulate old server scenarios.

Released: v2.12.13 🎉

This has been released in v2.12.13.

• 📄 Release notes
• 📦 View on npm

Get these changes by running the following command:

npm i msw@latest

Predictable release automation by Release.