Browser: worker not mocking requests when vi.mock present

[charlieforward9]

Prerequisites

• I confirm my issue is not in the opened issues
• I confirm the Frequently Asked Questions didn't contain the answer to my issue

Environment check

• I'm using the latest msw version
• I'm using Node.js version 18 or higher

Browsers

Chromium (Chrome, Brave, etc.)

Reproduction repository

https://github.com/Agriculture-Intelligence/msw-vitest-browser-issue

Reproduction steps

• Install aws-amplify, vitest, msw
• Configure vitest and msw to support browser-based testing/mocking
• Try mocking a call to the downloadData command from aws-amplify/storage module
• Notice the non-detailed NETWORK ERR

Current behavior

Functional in development and node/jsdom testing, when configuration is changed to browser-based, fails.

Expected behavior

I expect the browser based mocking to work exactly the same as node based testing.

[charlieforward9]

Looking at more of my tests, it seems like the real problem is that my handlers are not properly intercepting/mocking the network calls.

It appears to fire the request and match correctly, but not mock properly and end up somehow bypassing?

Am I configuring the worker incorrectly?

Please take a look at the sample repo so I can fix it and contribute it to an msw/example browser mode setup. Thank you

[charlieforward9]

I am also getting this at some places in my console when I run my tests...

 ... Warning: intercepted a request without a matching request handler:

  • GET /node_modules/...

i did not have any issues with any of the mocking when I was using the setupServer config, but now with setupWorker, there are a bunch of miscellaneous issues relating to external calls, including calls to http://localhost:63315/node_modules/...

[bdpartridge]

I'm hitting a seemingly similar issue while trying to use msw with vitest browser mode. My request handlers are being called, but ultimately msw is bypassing all requests, so all my mocked requests are resulting in 404 responses.

[bdpartridge]

I'm hitting a seemingly similar issue while trying to use msw with vitest browser mode. My request handlers are being called, but ultimately msw is bypassing all requests, so all my mocked requests are resulting in 404 responses.

I just realized that vitest browser is setting up its own msw request handler when vi.mock(...) is used to mock modules. Somehow this is interfering with my own request handlers, so it looks like this might be an issue with vitest browser and not msw.

[charlieforward9]

vitest browser is setting up its own msw request handler when vi.mock(...) is used to mock modules. Somehow this is interfering with my own request handlers

@bdpartridge is it? Take a look at my reproduction. I don't use vi.mock and still get issues.

[bdpartridge]

@charlieforward9 You're right. It looks like yours is a different issue. I tried out your reproduction and noticed that the beforeAll hook in the vitest.setup.ts file wasn't awaiting the worker to start. After making this change:

beforeAll(async () => {
  Amplify.configure(amplifyconfig);
  await worker.start();
});

…I see the mocked 200 response for POST https://cognito-identity.us-east-2.amazonaws.com/, but there seems to be a separate CORS issue related to the preflight request to https://mock-staging.s3.us-east-2.amazonaws.com/path/to/file.json.

Anyway, sorry for adding noise to this thread. Good luck resolving this.

[charlieforward9]

@bdpartridge seems to be right

I just realized that vitest browser is setting up its own msw request handler when vi.mock(...) is used to mock modules. Somehow this is interfering with my own request handlers, so it looks like this might be an issue with vitest browser and not msw.

The reason it wasnt working on my repro without vi.mock calls was because I was originally returning undefined in the handler, leading to it bypassing the call.

If you think this isnt a problem with msw, have you opened an issue with vitest yet? Any workarounds other than commenting out vi.mock?

[e7h4n]

I also encountered this issue, here is the minimal reproduction I tried: https://github.com/e7h4n/msw-vitest-failure/blob/main/index.test.ts

[louneskmt]

Same here, commenting out all the vi.mock makes the interceptors work again. Otherwise the handlers are correctly executed but for some reason the requests still end up a 404.

[kettanaito]

Hi, everyone. Thanks for sharing your details and reproduction repos! Much appreciated.

This one is most likely on MSW's side, but it needs proper investigation before we can know for certain. Since Vitest also uses an MSW worker under the hood for vi.mock(), there's a slight chance that something goes off and request handlers conflict (we've covered a few of related issues in the past on Vitest's side; they're fixed now).

How you can help

1. In the reproduction scenario, log out console.log(worker.handlersController.currentHandlers()). What does it print you? You should see the list of your handlers.
2. Grab the handler you expect to match (e.g. by index: currentHandlers()[0]) and run handler.run(). Does it returned the mocked response you expect? If not, what does it return?

[vafanassieff]

Without a vi.mock in my tests

[
  HttpHandler {
    "__kind": "RequestHandler",
    "info": {
      "callFrame": "http://localhost:63315/@fs/Users/afa/code/afa/msw-trpc/packages/msw-trpc/src/handler.ts:36:14",
      "header": "GET /http:\/\/localhost:3000\/trpc\/userById$/",
      "method": "GET",
      "path": /http:\/\/localhost:3000\/trpc\/userById$/,
    },
    "isUsed": false,
    "options": {},
    "resolver": [Function anonymous],
    "resolverIterator": undefined,
    "resolverIteratorResult": undefined,
  },
]

With a vi.mock

[
  HttpHandler {
    "__kind": "RequestHandler",
    "info": {
      "callFrame": "http://localhost:63315/@fs/Users/afa/code/afa/msw-trpc/packages/msw-trpc/src/handler.ts:36:14",
      "header": "GET /http:\/\/localhost:3000\/trpc\/userById$/",
      "method": "GET",
      "path": /http:\/\/localhost:3000\/trpc\/userById$/,
    },
    "isUsed": false,
    "options": {},
    "resolver": [Function anonymous],
    "resolverIterator": undefined,
    "resolverIteratorResult": undefined,
  },
]

I have an error when executing the function

TypeError: Cannot read properties of undefined (reading 'request')
    at HttpHandler.run (http://localhost:63315/@fs/Users/afa/code/afa/msw-trpc/node_modules/.pnpm/[email protected]_@[email protected][email protected]/node_modules/msw/lib/core/handlers/RequestHandler.mjs?v=8f961d5b:77:63)
    at http://localhost:63315/Users/afa/code/afa/msw-trpc/packages/test-browser/src/app.test.tsx?import&browserv=1740212511749:49:21
    at async http://localhost:63315/@fs/Users/afa/code/afa/msw-trpc/node_modules/.pnpm/@[email protected]/node_modules/@vitest/runner/dist/index.js?v=8f961d5b:558:22

[bdpartridge]

It looks like vitest runs its own worker setup when vi.mock(...) is called. Is it safe to call workser.start(...) when the worker has already been started? Even if it is, if the vitest request handler used for module mocking runs first, it creates a passthrough Response for any requests that haven't been mocked, which means other handlers would be skipped anyway.

Interestingly, the @vitest/mocker package that's used by vitest to mock modules appears to support passing a pre-configured worker instance, but it doesn't look like there's a way to use that option from the API exposed by the main vitest package.

For now, I'm working around this by specifying aliases in the vitest config. That works okay for my use case since none of my module mocks are test-specific at the moment.