feat: add "req.passthrough"

[kettanaito]

This is a breaking change.

• Originates from getting an unhandled request error for requests that are handled but intended to be forwarded on #655
• Closes Add "ctx.forward" for forwarding (bypassing) requests #676
• Closes feat: add support for ctx.forward #1180
• Closes feat: allow forwarding of requests with ctx.forward #962
• Closes feat(ctx): Add "ctx.forward" for forwarding requests #923

Changes

• Adds req.passthrough to explicitly instruct MSW to perform an intercepted request as-is.
• Returning undefined/null from handlers now treats the request as unhandled.

[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 69c9e3e:

Sandbox	Source
MSW React	Configuration

[kettanaito]

I'm returning a MockedResponse from passthrough to keep the same return type of the response resolver. I don't like this approach but I'll use it for now.

We need to refactor the return type of the resolver to be some sort of Instruction, which could be:

• Passthrough
• Fallthrough
• Use a mocked response
• Return a network error
• Anything else in the future

It should be a strictly defined object representing the library's next steps. Resolvers don't necessarily return mocked responses, as in the Passthrough/Fallthrough scenarios. Each intention can also be permanent or one-time (like res.once()). This is a great opportunity to solve #413.

The source for these instructions can also differ:

• res() instructs to use a mocked response.
• req.passthrough() instructs to passthrough this request.
• res.networkError() (or a different API) instructs to return a network error.

Decoupling the source from the instruction will allow us to design semantic APIs without locking ourselves in a MockedResponse structure.

[kettanaito]

Proposing this in #1207.

[kentcdodds]

Sweet! Where are the docs for this?

[kettanaito]

@kentcdodds, I've added the documentation in mswjs/mswjs.io#192.

[abhishekarun]

When is this coming in formal release?

[kettanaito]

@abhishekarun, as soon as #1175 is addressed. If you have some spare time I'd certainly appreciate some help with that issue.

Also, keep in mind that this is not a new feature but rather an improvement over the existing bypass/passthrough behavior.

[kettanaito]

Released: v0.40.0 🎉

This has been released in v0.40.0!

• 📄 Release notes
• 📦 npm package

Make sure to always update to the latest version (npm i msw@latest) to get the newest features and bug fixes.

---

Predictable release automation by @ossjs/release.

[yshrsmz]

This PR seems to break the compatibility with @mswjs/http-middleware. I've created a PR to fix the issue mswjs/http-middleware#10

[taylorkline]

Returning undefined/null from handlers now treats the request as unhandled.

I would politely suggest @kettanaito that the release notes for this release mention this as a breaking change.

[kettanaito]

@taylorkline, updated. Breaking changes between minor releases in pre-1.0 packages are implied but I agree this should've been communicated better.

[taylorkline]

@taylorkline, updated. Breaking changes between minor releases in pre-1.0 packages are implied but I agree this should've been communicated better.

Thank you!