Question/Feature request: Is there a way to run msw independently from the frontend app?

[flowck]

Is your feature request related to a problem? Please describe.
I was trying to run msw with a Next app, however I ran into a race condition between msw and an http request inside of a useEffect hook. I looked for answers and I bumped into this post Deferred mounting, however I was not able to make it work within a Next-based app because the mounting of the whole application is abstracted, and the entry point is just a regular component function MyApp()...

I am thinking: why going into this trouble when I can have the mock server completely detached from the frontend app?

Describe the solution you'd like
I would like to be able to initiate msw's server as a standalone instance, so that the frontend app is completely decoupled from the mock server, should I want it to be.

export const server = setupServer(...handlers);
server.listen({ port: 9000 });

// [MSW] Mocking is enabled and running at 9000 port.

Describe alternatives you've considered
At this point I am thinking on replacing msw with express to mock the requests.

Additional context
N/A

[kettanaito]

Hey, @flowck. Thanks for raising this.

It'd be great to improve the recipe to rely on patterns you can use in any framework/setup, no matter how abstracted. Like with NextJS, where you don't control the application mounting directly.

I am thinking: why going into this trouble when I can have the mock server completely detached from the frontend app?

Devising this deferred rendering pattern may seem like a chore but it's insignificant compared to the cost of writing and running a standalone server, even if for the local development. On top of that, there are other things that a mocked server implies, such as routing all your requests to that server just for the sake of development/testing. This diverges your app and opens room for mistakes.

We do support running an HTTP server via @mswjs/http-middleware but I strongly discourage you from doing so, as yours isn't the use case we've designed the said package.

What I think should happen here is for the library to provide a simple and reliable way to intercept requests made on the initial mounting of components (compensating or removing the race condition between the worker registration and the app mounting). We are open to ideas as our current approach (buffering all requests and postponing them until the worker is ready) clearly doesn't work for quite a few people.