feat: add "SetupApi" base class

[Toxiapo]

• Closes Support Edge Runtime (no http module) #1428

Hi @kettanaito, I would like to hear your thoughts about the current setup and if I am on the right track. I am also curious if you mean to write the SetupApi as an interface and update the return types on setupWorker and setupServer or a base class and mimic the current logic into a class as I did here. However, this might be tricky to implement interceptor.on('request') for both the server and the worker.

We will have to create a custom setup specifically for Edge in the consuming app to consume the API.

import { SetupApi } from "msw"
import { FetchInterceptor } from '@mswjs/interceptor'

class SetupEdge extends SetupApi {
  constructor(handlers: RequestHandler[]) {
      super([ClientRequestInterceptor], handlers)
  }
  
   public listen(options: ...): void {
      // ...
      super.apply()
    }
  // ...
}

[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 1b03936:

Sandbox	Source
MSW React	Configuration

[kettanaito]

Hey, @Toxiapo. I'm so excited to see this in the works! Thanks for working on the changes, I will try to get to them today/tomorrow to give some feedback.

I am also curious if you mean to write the SetupApi as an interface and update the return types on setupWorker and setupServer or a base class and mimic the current logic into a class as I did here.

I was thinking of introducing a base class, then extending that class with specific SetupServerApi and SetupWorkerApi classes, and then returning their instances from the setupServer() and setupWorker() existing API to preserve the same public interfaces. I think a class is the best syntax to describe fixed life-cycles and behaviors, which is exactly what we're doing here.

[kettanaito]

Let me know when you would like a full review of this. Really exciting changes going on here 👀

[Toxiapo]

Yes, @kettanaito I think we can start the review! I left some comments that I thought might be useful, but most of the logic was kept the same.

[kettanaito]

Thanks for moving forward with this, @Toxiapo! This looks great. I've had a chance to try it out locally, and also pushed a few changes regarding tests and child classes. One thing that remains is to distribute the interceptors properly (not all child classes rely on interceptors at all). I can pick this up once I have time next week so we can finish this.

[kettanaito]

I've got some time to work on this today. Hope to wrap it up soon and prepare the next release.

[kristojorg]

Just getting back from some time off and super happy to see this get done! Thanks @Toxiapo and @kettanaito : )

[kettanaito]

Thanks for making this happen, @Toxiapo! 👏

[Toxiapo]

Woohoo, I am excited to try this! Thanks, @kettanaito!

[kettanaito]

Released: v0.48.0 🎉

This has been released in v0.48.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.

[smblee]

Hey guys! wondering what this would enable us to do? Is this for better edge support?

[kettanaito]

Hey, @smblee. This would enable you to create custom setup* APIs that manage interception. One example of this is indeed creating a subset of setupServer that'd use different interceptors to run on the edge.

// Import the interceptors you want from @mswjs/interceptors
const edgeInterceptors = [fetchInterceptor]

class SetupEdgeServerApi extends SetupServerApi {
  constructor(handlers) {
    super(edgeInterceptors, handlers)
  }
}

export function setupEdgeServer(...handlers) {
  return new SetupEdgeServerApi(handlers)
}

Also note this is a rather advanced usage. If this doesn't make sense to you, it's very likely you don't need this API at all.