mswjs.io | Official website and documentation for the Mock Service | REST library

I was also experimenting with MSW (Mock Service Worker) for webpack 5 and module federation last couple of days. It may not apply to your specific use case, but below is what I did to make MSW work with a module federation app.

Set up and initiate MSW in the container app.

• place worker.start() in bootstrap.js in the container app (I put it before ReactDOM render as my app is using react).
• place mocks folder also in the container app (e.g. under src).
• Add endpoints that you want to intercept and mock in handlers.js in the mocks folder.
• run npx msw init ./ --save in the root of the host app (container). Note that the directory of the installation should be the root - mockServiceWorker.js should be in the same location as the index.html (its location is specified in webpack config).

This worked for me regardless of which child MFE apps calls the api endpoints you are intercepting with the MSW.

Below is the repo of a little experiment/example I did with Webpack5 Module Federation and MSW. https://github.com/nfabacus/module-federation-example

I did not test specifically with the module federation, but I think you can just follow the instruction in the MSW setup page for node (https://mswjs.io/docs/getting-started/install). Just install msw for each MFE and set up the tests. When I tested with normal react app (CRA), it worked fine (https://github.com/nfabacus/msw-cra-example). I don't think there is any difference between module federation and single SPA in terms of implementing msw with unit tests.

There are two problems in Users.test.js

1. Need to add async/await
2. Use findByText instead of getByText

With these changes, the test passes:

react-query-firebase library is an abstraction over Firebase that encapsulates resource paths (it's an SDK, I believe). Since the paths (URLs) are abstracted from, you have at least two options for how to mock requests issued by such libraries.

Although the exact resource paths are hidden away, requests still reference existing absolute paths. You can observe those in the "Network" tab of your browser or by enabling a simple request introspection with msw:

This feature was introduced in MSW v0.20.0, but in v0.29.0 the default setting for unhandled requests changed from "bypass" to "warn", hence the warnings suddenly appearing in the console. You can reset it to "bypass" as shown in the docs for setupWorker#start or setupServer#listen, in my case: