@fetchkit/chaos-sw
chaos-sw installs a Service Worker that injects failures, latency, rate limits, throttling, and mock responses into browser requests. Existing fetch calls and HTTP clients stay unchanged, while one configuration applies across every tab controlled by the worker.
chaos-sw uses chaos-fetch as its chaos engine, but moves interception into the browser Service Worker. Global and route-specific middleware can affect requests made by application code, third-party HTTP clients, and every controlled tab without replacing the global fetch function.
Transparent interception
Keep existing fetch calls and HTTP clients. The Service Worker applies chaos before requests reach the network.
Shared across tabs
One worker registration shares its enabled state, configuration, and scenario counters across all controlled tabs.
Same chaos model
Use the latency, failure, rate-limit, throttle, mock, and route configuration supported by chaos-fetch.
Register the copied worker, apply a serializable chaos-fetch configuration, and enable it. Path routes can match every origin; absolute URL routes restrict a rule to one exact origin.
import { setupChaosWorker } from '@fetchkit/chaos-sw'
const chaos = setupChaosWorker({
workerUrl: '/chaos-sw.js',
scope: '/',
})
await chaos.start()
await chaos.applyConfig({
global: [
{ latencyRange: { minMs: 100, maxMs: 500 } },
],
routes: {
'GET /api/users/:id': [
{ failNth: { n: 3, status: 503 } },
],
'POST https://api.example.com/orders': [
{ failRandomly: { rate: 0.2, status: 500 } },
],
},
})
await chaos.enable()await chaos.disable()await chaos.resetScenario()await chaos.getState()| Tool | Interception layer | Best fit |
|---|---|---|
| chaos-fetch | A fetch-compatible client inside JavaScript | Unit and integration tests with per-client configuration |
| chaos-sw | The browser Service Worker | Whole-app browser testing without replacing application fetch calls |
| chaos-proxy | An external HTTP proxy | Transport-level and multi-service testing with any HTTP client or language |
Both chaos-sw and Mock Service Worker intercept browser requests through a Service Worker, but they solve different problems. chaos-sw models degraded network conditions around traffic that usually continues to a real or separately mocked backend. MSW primarily defines API behavior and deterministic test data.
| Capability | chaos-sw | MSW |
|---|---|---|
| Primary purpose | Fault injection and degraded conditions | API behavior and data mocking |
| Configuration | Serializable global and route middleware | JavaScript or TypeScript request handlers |
| Random and stateful failures | Built in | Implemented in handler logic |
| Bandwidth throttling | Built in | Not its primary abstraction |
| Response mocking | Basic status and body mocks | Rich request-aware resolvers |
Only one Service Worker registration controls a page at a scope. If your application already has a PWA, Workbox, MSW, or custom worker, import createChaosWorkerRuntime from @fetchkit/chaos-sw/worker and register its event handlers inside that worker.
Configuration and middleware counters live in Service Worker memory and are shared across controlled tabs. Browsers may restart workers, so callers must reapply desired state. The core package deliberately has no persistence, YAML editor, DevTools extension, or request log.
Testing and limitations