Msw: Requests not properly resolving with axios in the browser

[andrewswerlick-hmn]

Describe the bug

One the latest version of axios (0.19.2), and with any version >= 0.18.0 of msw any calls to axios.get do not ever resolve the promise. There are no errors in the console, and MSW and networks logs indicate the request was handled correctly

I haven't had time to make an isolated reproducible case yet, but will try to do so. In my app the request in question is one where I'm not actually mocking anything, just letting it pass through to the server, but I'm not sure that it's relevant.

Environment

• msw: 0.18.0
• npm: 6.13.4

Please also provide your browser version.
Replicated in Firefox 77.0.1 and Chrome 83.0.4103.61

To Reproduce

Steps to reproduce the behavior:

Should be reproducible with axios code like

axios.get("/foo").then(res=> console.log(res))

Expected behavior

Should log the response out to the console, but instead we never seem to make it inside the then statement.
A clear and concise description of what you expected to happen.

[kettanaito]

Hey, @andrewswerlick-hmn. Thanks for letting us know about this issue.

Yes, I'd be very thankful for a minimal reproduction scenario on your side. Meanwhile, I'll try to test this and see what's happening.

[andrewswerlick-hmn]

Just a quick update, I've struggled to create a minimal repro so far. I'm using https://github.com/andreawyss/msw-tester and making modifications and here's what I've tried

1. Modify the tester project to set axios.defaults.baseUrl = "/" and axios.defaults.baseUrl.withCredentials = true
2. Modify the test project so it makes an axios get call on startup immediately after the await worker.start() call

Neither resulted in a minimal reproduction. I'll try to explore a few more avenues today

[kettanaito]

Thanks for your effort. We've also have a set of official examples that should help you get started in preparing a preproduction case. Could you please try using React REST API example repo for this?

Fork it, install axios, and add the request call where it's happening in your actual app. Thanks.

[AndrewSwerlick]

Got a reproduction! https://github.com/AndrewSwerlick/examples.

The gist of it is that it appears if you ever call setupServer from msw/node in the browser it borks axios. I was trying to consolidate and organize my code by having a single module that exported both a nodeSever and a browserServer and then I imported and started the right one depending on the environment I was running in (jest vs browser). I assumed setupServer was side effect free, and nothing would happen until we called listen, but looking at the code it appears that's not the case.

It may be worth modifying the setupServer function to include a warning if running in a browser environment, or something like that.

[kettanaito]

@AndrewSwerlick thanks for putting that example down. You're right, setupServer mustn't be called in a browser (designed for NodeJS only). I agree that we need to put a human-friendly error when someone intentionally (or unintentionally) calls it in a browser 👍

What .listen() does it just applies a request intercepting middleware, but the setupServer itself relies on Node modules. I find it valid that it breaks, since one should fail fast in this case. It's the matter of improving the error propagation to the developer.

Does this mean that once you replace it with setupWorker (and have the npx msw init <PUBLIC_DIR> executed) the issue is gone?

[AndrewSwerlick]

@kettanaito yeah everything is working fine. Basically I had one file that had my handler definitions, my worker setup and my server setup. I broke it into 3 seperate files, and ensured that I only imported the one in the bundle used in the browser.