Make console.warn configurable for resolvers that do not return a mocked response.

[chiller-whale]

I am using supertest to test an API that integrates with a 3rd party http service. I have unhandled requests configured to error, but noticed that an error was being caused by a requests being sent with supertest. I was able to resolve this by using conditional mocking with:

rest.get('http://127.0.0.1:*', () => {
  return;  
})

This solved the issue of erroring, but I now get a console.warn for each of those tests reading:
[MSW] Expected a mocking resolver function to return a mocked response Object, but got: undefined. Original response is going to be used instead.

It would be great if this warn could be disabled. If not globally, then through the res parameter so it could be handled on a per handler basis.

[chiller-whale]

After digging through the source, it looks like the header x-msw-bypass could be used as a work around.

[kettanaito]

Hey, @chiller-whale. Could you please include your mocks (request handlers, how you call setupServer) and your test that uses supertest, which surfaces an issue?

Returning undefined is a correct strategy for response resolvers since 0.28.1. Please, could you check that you're running the latest version of msw?

$ npm install msw@latest
# or
$ yarn add msw@latest

[Nivl]

I have the latest version and returning undefined does trigger a warning. I can see that in the codebase there's a jest mock to prevent the message from appearing in jest, but not sure how to do this for the browser.

What I'm trying to do is:

• unhandled requests => trigger a warning (this works)
• Passthrough requests => silent because expected. (this doesn't work, they return a different type of warning)

[kettanaito]

Hey, @Nivl. Thanks for the update on this. It's a known issue and we're working on making the DX around unhandled requests better. Our idea here is to introduce a designated API to passthrough requests instead of returning nothing from the resolver. That way we'd be able to distinguish between intentional and unintentional scenarios when a resolver returns no mocked response.

You can contribute to the implementation of this, if you'd like, in #962/#923.

[kettanaito]

This is a known issue (see #676) and it's currently being addressed in #962/#923.