How to prevent msw from catching some URLs: improve docs?

[sneko]

Hi,

I looked multiple times at the addon docs but also the main docs and it was not obvious at all from the initialize() function I would be able to let pass some specific URLs thanks to passthrough():

initialize({
  onUnhandledRequest: (request, print) => {
    if (request.url.pathname.startsWith('/node_modules/')) {
      request.passthrough();
    } else {
      // For all others, show a warning
      print.warning();
    }
  },
});

It did not come to mind since https://mswjs.io/docs/api/request/passthrough talks about request, but in the examples https://msw-sb.vercel.app/?path=/story/guides-getting-started--page#configuring-msw it only talks about method and url.

It's maybe not an issue, but I hope it can save some time to others :D

Thank you,

[yannbf]

Hey @sneko thank you so much for opening this issue! I'll discuss with @kettanaito about it and I'll see if we can improve the documentation. This sounds like a very interesting use case!

[kettanaito]

Hey! Thanks for proposing this.

I would like to learn more about what you're trying to do. The code snippet you shared above is not going to work and request.passthrough() is going to do nothing unless it's returned from a response resolver.

I suspect multiple things are mixed here. I will do my best guessing what they are.

How to suppress unhandled request warnings from some resources?

Use the onUnhandledRequest option.

initialize({
  onUnhandledRequest(request, print) {
    if (request.url.pathname === '/some-resource') {
      return
    }

    print.warning()
  }
})

Note that MSW won't do anything by default if you provide a function as the value for this option. If you wish to ignore the unhandled requests' warnings, just do an early return in that function and you're all set.

How to bypass a request only in some cases?

So you have a mock for GET /resource but you actually want it to reach production only in some cases (e.g. if there's a certain URL query parameter). You use req.passthrough() for that:

rest.get('/resource', (req, res, ctx) => {
  if (req.url.searchParams.has('someParam')) {
    return req.passthrough()
  }

  // Otherwise, respond with a mock.
  return res(ctx.text('Hello world!'))
})

I don't want for a certain resource group to ever be mocked

Once again, you can utilize req.passthrough() and the fact that you can short-circuit the handler lookup phase of the library.

rest.get('/some-path/*', (req) => {
  return req.passthrough()
})

With this, any requests under /some-path will be performed as-is, even if there are handlers mocking them. As long as this particular handler is defined first.

---

I think none of these things belong to the add-on's documentation because this is not add-on-specific knowledge. You can find these APIs in the MSW documentation and I'm currently working hard on improving the docs experience.

[sneko]

It's been some time. I think I just wanted to clarify that in your documentation you deconstructed the input object and at that time I thought it would be useful to see all the possibilities of the parameters request and print.

You can close this if does not make sense 🚀

Thanks for answering 👍

[yannbf]

@kettanaito would it be useful from the addon's perspective to provide a default initial handler that does something like:

rest.get('/node_modules/*', (req) => {
  return req.passthrough()
})

To help with possible HMR clash issues and also to improve performance as a positive side effect?

[kettanaito]

@sneko, no worries! I am thankful for your input.

@yannbf, I think that wouldn't bring many benefits because you don't typically serve node modules. HMR requests are often those to a running WebSocket server that has nothing related to node_modules so the handler above wouldn't catch it anyway.

I would love to ship some defaults not to spam people with warnings on requests that are implementation details of the framework they are using (such as HMR) but the issue is that those requests are precisely that—implementation details. They may change without any notice, and it would be virtually impossible to keep up with how every framework structures their features when it comes to HTTP requests that implement them. But I'm open to suggestions, still.