Unhandled request for webpack files during Next.js fast refresh

[ryandi-tiket]

Hi, thanks for your hard work on the library! Appreciate it if you could take a look at the following issue.

Environment

Name	Version
msw	0.35.0
browser	Chrome
OS	macOS 11.5.2

Reproduction

npx create-next-app --example with-msw with-msw-app
npm install msw@latest # happened with v0.29.0 as well
npx msw init public
# go to localhost:3000 and open console
# make any changes to pages/index.js

Request handlers

See: reproduction

Actual request

See: reproduction

Current behavior

Warns about unhandled request for webpack files during Next.js fast refresh

Expected behavior

No warning

Screenshots

[kettanaito]

Hey, @ryandi-tiket. Thanks for raising this.

MSW intercepts all outgoing requests on the page, including those from webpack's Fast Refresh. It's hard for us to assume which requests are internal (such as webpack's request) and which are intended by you. We delegate that decision to you instead.

You see the warnings because MSW warns you on unhandled requests by default. I understand that seeing such warnings from internal tooling pollutes the console, so you have a few options to opt out of this behavior.

(Recommended) Option 1: Whitelist internal requests

worker.start({
  onUnhandledRequest(request) {
    // Whenever there's an unhandled request which path
    // starts from "/_next", ignore it.
    if (request.url.pathname.startsWith('/_next')) {
      return
    }

    console.warn('Unhandled: %s %s', request.method, request.url.href)
  }
})

The nature of these internal events is defined by the tooling you're using (i.e. NextJS). That's why whitelisting them should live as close to the tooling as possible, being your application. This way you can adjust the whitelists according to the breaking changes in your tooling if any. Since you rarely switch from NextJS to something else entirely, you only have to do this once.

Option 2: Change the onUnhandledRequest strategy

The onUnhandledRequest option supports three strategies: "warn" (the one you're experiencing), "error", and "bypass". You can use the letter to suppress any unhandled requests warnings, allowing unhandled requests to be performed as if intended.

worker.start({
  onUnhandledRequest: 'bypass'
})

Note that this will disable warnings for all unhandled requests, decreasing your developer experience when you've forgotten to mock a certain request or made a typo in its URL, for example.

Let me know if you have any other questions.

[ryandi-tiket]

@kettanaito I’ll go with option 1, thanks!

[kettanaito]

Update on this: since 0.38.0 the onUnhandledRequest custom function now has the second argument that allows you to call default warn/error behaviors of this method. This is useful so you don't have to re-construct warnings/errors manually when using a custom function:

onUnhandledRequest(request, print) {
  if (request.url.pathname.startsWith('/_next')) {
    return 
  }

  // Otherwise, you'd like for MSW to warn you.
  // You can also use "print.error()".
  print.warning()
}

[ryandi-tiket]

ah interesting, thanks!