feat(msw): Add workerd export

[penalosa]

Fix #2637

This PR adds a msw/workerd entrypoint in order to expose a setupServer() API compatible with the workerd runtime (i.e. just a fetch() interceptor). I've added this as a new entrypoint to fit the existing setup, but I wonder if at some point it might make sense to just have a msw/setup entrypoint that exposed different browser, node, react-native, and workerd export conditions?

This is called workerd to match the WinterCG list of runtime keys: https://runtime-keys.proposal.wintercg.org/#workerd

[kettanaito]

Hey, @penalosa. Thanks for proposing this.

I believe what you're proposing can already be done by the developer, that is creating a custom SetupApi subclass and using it. We've also worked on tiny improvements to the ergonomics of that in the past, allowing folks to swap the list of interceptors while retaining other APIs and behaviors from setupServer. Albeit, I admit that might still be rough and I'm happy to discuss how to improve that approach.

As of now, I see no reason to add a new export or support workerd in any special way since no such support is needed. It's also worth mentioning that I'm at the final stage of rewriting the internal architecture to allow for easier creation of what most developers now know as setupServer-kind APIs (see #1617, it's coupled with a new API at the moment). But until that lands, I propose the following to ensure workerd support:

1. Create an example of declaring your own SetupApi/SetupServerApi API. This solves the discoverability problem. We can use workerd as a practical example!
2. Dogfood it and gather feedback. Here, I'm mostly curious in how ergonomic the creation of those custom APIs would be, whether MSW can make that process better by exposing certain internals, types, or anything else.

What do you think?

[penalosa]

Hey @kettanaito! Our main goal is to make this as simple as possible for developers trying to use MSW with Cloudflare, and so it felt like a simple API:

import { setupServer } from "msw/workerd"
export const server = setupServer()

would match that goal well, rather than end-users having to understand the details of MSW & interceptors (of course, we'd document the right setup, but the DX of setupServer() is hard to beat!). That said, I understand the hesitations with adding that.

In terms of the specific issues with existing APIs, as it stands today the custom SetupServer is only exported from the msw/node entrypoint, which the resolve conditions we use for Cloudflare workers don't work with, which are ["workerd", "worker", "module", "browser"]. I get errors along the lines of No known conditions for "./ClientRequest" specifier in "@mswjs/interceptors" package (or The requested module '_http_common' does not provide an export named 'HTTPParser' if I mess around a bit with the export conditions in the package).

In testing, the msw/native entrypoint works perfectly in Cloudflare Workers if I add a workerd export condition to the package.json, so I wonder if that might be an alternative path forward, or exporting SetupServerCommonApi?

[kettanaito]

Given the export conditions for CF Workers, I wonder if msw/node even can be used with workers. It might rely on built-in HTTP modules, not sure whether those can be imported on Cloudflare.

This is a good use case for us to explore how to provide all the necessary APIs for users to build their own setup* functions. The neutral SetupApi class is there and used to implement both SetupServerCommonApi and then SetupServerApi later, but it doesn't even concern itself with interceptors, and I wouldn't want any users touching that.

As I mentioned before, the defineNetwork API implemented in #1617 makes this process proper. I need to assess whether it make sense to spend time on an intermediate solution or just merge those changes and document how to use the new defineNetwork with your use case as an example.

That being said, I'm most certain we won't support CF Workers with the changes proposed here. If you don't mind, I will close this pull request. Let's continue collaborating on this in the issue instead.