MSW (Mock Service Worker)

MSW (Mock Service Worker) intercepts outgoing requests at the network level rather than patching fetch/XMLHttpRequest in your application code. In the browser it uses the Service Worker API to intercept requests before they leave the page; in Node.js it patches the underlying request-dispatching layer. Either way, your application code and tests remain unaware that responses are mocked — they see the same requests and responses they would in production.

Handlers are defined with an Express-like routing syntax (http.get('/users/:id', resolver), graphql.query(...)), supporting path parameters, wildcards, and regular expressions, with resolvers able to return custom status codes, headers, cookies, delays, or streaming responses. The same handler definitions work across unit tests, integration tests, Storybook, and live browser development, so mocks are written once and reused everywhere.

What You Get

• setupWorker() for browser-based interception via a generated Service Worker script, and setupServer() for Node.js test environments
• Express-like http.get/post/put/... and graphql.query/mutation handler syntax with path params, wildcards, and regex matching
• A CLI (msw init) to scaffold the Service Worker file into your public/static directory
• Composable resolvers supporting custom status codes, headers, cookies, response delays, and streaming bodies
• Life-cycle events and request/response logging for debugging which handlers matched a given request

Common Use Cases

• Mocking backend REST/GraphQL APIs in unit and integration tests without patching fetch or spinning up a real server
• Running Storybook stories or local development against mocked API responses before the real backend endpoint exists
• Simulating error states, slow networks, or edge-case API responses that are hard to reproduce against a real backend
• Sharing one set of mock handlers between tests, Storybook, and browser-based manual QA to avoid mock drift

Under The Hood

Architecture - MSW’s src/core module holds the runtime-agnostic pieces (handler matching, resolver execution, life-cycle events), while src/browser implements Service-Worker-based interception (generating and registering mockServiceWorker.js) and src/node implements interception by patching Node’s request-dispatch internals via an interceptors library — both runtimes funnel matched requests through the same core resolver pipeline so handler code is 100% shared. Tech Stack - Written in TypeScript (97% of the codebase) with a dual CJS/ESM build produced by tsup, tests run under Vitest, and the package ships separate browser, node, native, and iife entry points via conditional exports in package.json for each target environment. Code Quality - The test/ directory mirrors src/ with dedicated suites per interception target plus a large integration-test surface, and knip.json/commitlint.config.js indicate enforced unused-export detection and commit-message conventions; the project has 181 contributors and consistent release cadence. API Design - The Express-like http.get(path, resolver) syntax gives JS/TS developers a near-zero learning curve, graphql.query/mutation mirrors the same pattern for GraphQL, and life-cycle events (server.events.on('request:start', ...)) provide debuggability without extra tooling.