- Introduction
- Getting started
- Philosophy
- Comparison
- Limitations
- Debugging runbook
- FAQ
- Basics
- Concepts
- Network behavior
- Integrations
- API
- CLI
- Best practices
- Recipes
- Cookies
- Query parameters
- Response patching
- Polling
- Streaming
- Network errors
- File uploads
- Responding with binary
- Custom worker script location
- Global response delay
- GraphQL query batching
- Higher-order resolver
- Keeping mocks in sync
- Merging Service Workers
- Mock GraphQL schema
- Using CDN
- Using custom "homepage" property
- Using local HTTPS
Managing the worker
In the browser, MSW registers a Service Worker script (mockServiceWorker.js
) that allows it to intercept the outgoing network traffic of your application. Below, learn about the best practices of generating, verifying, and updating the worker script.
Generating the worker script
To generate the worker script, run the following command in your project’s root directory:
npx msw init <PUBLIC_DIR> --save
You’d have to replace the <PUBLIC_DIR>
part with the actual path to your application’s public directory. You can learn more about this step here:
`init` CLI command
Generate the worker script at the given path.
Committing the worker script
It is recommended you commit the mockServiceWorker.js
worker script in Git. This way, everyone working on the project can get MSW up and running without having to run any additional commands.
Alternatively, you can treat the worker script as a generated artifact. If you chose to do so, make sure to automate the worker script generation so the script is created for everyone starting with the project.
Serving the worker script
The entire point of msw init
is to copy the worker script to your project’s root directory so it is available on runtime. You must ensure that your application is serving the worker script correctly by opening the script’s URL in the browser.
For example, if you are running your application at http://localhost:3000
, navigating to http://localhost:3000/mockServiceWorker.js
must return the application/javascript
content of the worker script. If it doesn’t, you should repeat the generation step or go through the browser integration from the start:
Browser integration
Set up Mock Service Worker in the browser.
Updating the worker script
The client-side code of MSW can pick up any worker script within the same major version. It is still recommended to keep the worker script up-to-date with the installed version of MSW. That is why we recommend using the --save
flag with the msw init
command.
When run with the --save
flag, the msw init
command will save the used public path in package.json
. Later, whenever you upgrade or downgrade the msw
dependency, it will automatically generate the worker script at the saved path to keep you in-sync.
// package.json
{
"msw": {
"workerDirectory": "./public"
}
}
`--save` flag of the `init` command
Save the public directory to enable automatic updates.
Multiple worker directories
MSW supports an array of public directories as the value of the msw.workerDirectory
property. This is especially handy when using MSW in multiple packages in a monorepo.
// package.json
{
"name": "my-monorepo-root",
"msw": {
"workerDirectory": [
// Include multiple public directories.
"./packages/one/public",
"./packages/two/static"
]
}
}
Anytime you run msw init
with the --save
flag and a public directory not previously stored in msw.workerDirectory
, MSW will automatically save the new public directory in your package.json
.
If you decide to manually edit
msw.workerDirectory
, make sure that it’s set in your project’s root-levelpackage.json
.