Fallback mode

[kettanaito]

Changes

• Unifies response retrieval by introducing a new handleRequest function that encapsulates:
  • Response lookup via getResponse.
  • Life-cycle events emitting in the proper phases.
  • Unhandled request callback invocation.
• Removes mocked response headers serialization into a HeadersList. Instead, serializes mock response headers into a FlatHeadersObject so that their shape is the same across regular start (where serialization is necessary to transmit the headers to the worker) and the fallback start (where serialization is only necessary to respond properly).
• Adds support for the "fallback mode"—alternative interception mechanism that's automatically enabled in browser environments when Service Worker API isn't supported (legacy browsers) or cannot run (static local builds).
• Splits the Rollup configuration so each build target uses its own set of plugins. This way the browser bundles are configured properly (see the note below).

Motivation

• Add support for the browsers that don't support Service Workers.
• Allows MSW execution in statically built apps (i.e. static Storybook build), where running a Service Worker from a file:// is forbidden.

GitHub

• Closes RFC: Fallback mode #663
• Closes Fallback mode #688
• Closes Unify response retrieval and the related event handling #689

Roadmap

• Find a way to enable and control the interceptor when calling worker.start() and worker.stop() without disrupting the public API while keeping the internals clean.
• Bundle the debug transient dependency of interceptors property (currently pulls in util and tty dependencies being bundled for UMD and ESM targets).

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit d8e1652:

Sandbox	Source
MSW React	Configuration

[kettanaito]

Request cookies must not be set here, as they are already set in parseIsomorpchicRequest.

If cookies are set here once more, they will get overridden in Node.js, as request cookies in Node.js are resolved to {} (no location to check if the cookies should be inherited).

[kettanaito]

Surprisingly, there was no test that checks if the request cookies are properly set given the combination of its own cookies and those inherited from the cookie store. Previously, such combination resulted in the own request cookies being overridden, with the store cookies taking priority.

Here, I swap the cookies priority, with the request's own cookies potentially overriding the store (inherited) cookies, as that seems like something you'd expect.

[kettanaito]

It's important to signal the worker ignoring the response's delay, as the worker resolves the response respecting that delay. Otherwise, the delay would get doubled.

[kettanaito]

I'm using this pull request as an opportunity to remove external HTTP servers dependency from tests and replace it with the locally running server that represents a production one (which mustn't be hit in most test cases).

[kettanaito]

Bundling debug

The debug dependency has a dynamic import that loads either Browser and Node versions of the library on runtime:

https://github.com/visionmedia/debug/blob/d177f2bc36d3b8b8e9b1b006727ef5e04f98eac7/src/index.js#L6-L10

When being bundled, though, it loaded the Node version all the time, resulting in broken browser builds.

Solution

• Configure browser builds (UMD, IIFE) to prioritize the "browser" field in mainFields option (decides which dependency entries are loaded first).
• Set browser: true and preferBuiltins: false for the browser builds.

Links

• Cannot use debug with Rollup debug-js/debug#468