MSW: 187k repos mock APIs via Service Worker

You know that feeling when your backend isn't ready yet, or it's flaky in CI, and every frontend test either fails randomly or requires a real server running? The old fix — patching `fetch` or `XMLHttpRequest` directly in your test setup — means your tests know they're being mocked, your app code diverges from production, and you maintain separate stubs for Vitest, Jest, Storybook, and local dev. You end up with four different mock layers that drift apart over time and hide real integration bugs.

In the browser, MSW registers a Service Worker — a background script that sits between your app and the real internet. When your app fires a request, the Service Worker catches it before it leaves, hands it to your handler code (running in the main thread, with full access to TypeScript and any library), and returns whatever response you defined. The request still shows up in the browser's Network tab as a real HTTP call, because it is one — it just never reaches the actual server. In Node.js (for tests), MSW uses a different mechanism: it extends Node's native HTTP/HTTPS/Fetch classes to intercept at the class level, with no module patching. The same `handlers.ts` file you wrote for the browser gets imported directly into `setupServer()` — no adapters, no environment branches.

• Single handler file across all environments — you write `http.get('/api/user', resolver)` once and it works in Vitest, Jest, Storybook, Playwright, and local dev with no adapters or branching logic, eliminating handler ...
• Requests appear in DevTools as real network calls — because interception happens at the Service Worker level, not inside your app's JS, so you can inspect headers, timing, and payloads exactly as you would in production.
• Zero application code changes required — MSW intercepts outside your app, so the same codebase you ship to production is what runs in tests; no conditional mock flags, no environment checks in your fetch calls.
• REST, GraphQL, and WebSocket support — `http.get/post/put/delete/patch` covers REST; a separate `graphql` namespace handles GraphQL by operation name; WebSocket mocking is production-supported per official Egghead cours...
• Runtime handler overrides per test — `server.use(http.get('/api/user', () => HttpResponse.json({ error: 'unauthorized' }, { status: 401 })))` overrides handlers for a single test without polluting others, then `server.r...
• `bypass(request)` for selective passthrough — you can let specific requests hit the real network while all others are intercepted, useful for tests that need real auth tokens or real third-party responses.
• TypeScript-first with 96.8% TypeScript codebase — handler resolvers are fully typed, `HttpResponse` is a subclass of the Fetch API `Response`, and path params are inferred from URL patterns, so you catch mock/contract m...

Who It Is For

If you write frontend or full-stack JavaScript and your tests hit real APIs, use environment variables to toggle mocks, or maintain separate stub files per testing tool, MSW directly removes that overhead. It's also the right fit if you use Storybook and want components to render with realistic network data without a running backend. Not a fit if you need to mock raw TCP connections (`net.connect...

Worth Exploring?

Yes — 17,852 stars, 187k+ dependent repositories, 255 releases, v2.13.4 pushed on 2026-04-16, and named usage by Google, Microsoft, Spotify, Amazon, and Netflix all confirm this is production-proven, not experimental. The one real risk is sustainability: per the README itself, zero full-time contributors maintain a project used by hundreds of thousands of engineers. That's an operational dependency risk worth factoring into any long-term adoption decision.