msw: 2.1.0 breaks browser usage

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/thepassle/msw-bug

Reproduction steps

npm i && npm test

Current behavior

When using msw@2.0.14 it works:

When using msw@2.1.0 it breaks:

I havent been able to debug (but I was able to pin it down to version 2.1.0 as the breaking version), and im unlikely to have time to dive into this for the next couple of days or so, but I figured i’d report it so maybe somebody else can pick it up

Expected behavior

It works 😃

About this issue

Original URL
State: closed
Created 5 months ago
Reactions: 2
Comments: 15 (14 by maintainers)

Most upvoted comments

Asking you to properly await promises is a good thing. It’s a thing you should do.

I agree, I’m just letting you know that release 2.1.0 resulted in an expected behavior of the library breaking in our projects at work, fyi. Hopefully in the future we can be a bit more careful about deprecations/removals of behavior

thepassle on Jan 26, 2024

@thepassle, the root cause seems to be not awaiting worker.start(). Remember, it’s an asynchronous action that you must await before your app/tests are running.

If I add a simple await statement right here, your reproduction repository passes: https://github.com/thepassle/msw-bug/blob/8bbec16ddcd0bca4166a2407b0838a9429fb870f/test.js#L5

Finished running tests in 1.1s, all tests passed! 🎉

In our examples (browser tests) we don’t await worker.start() for two reasons:

Our compiler doesn’t like root-level async/await.
Not all tests should await it. The await mechanism is built-in into loadExample and you can even opt-out of it via skipActivation: boolean.

kettanaito on Jan 25, 2024