feat: use "IsomorphicRequest" class to handle request body as buffer

[95th]

Expose new Request API which allow access to raw buffer

• Prerequisite for Access raw request body as buffer msw#1302

Roadmap

• Add unit tests for bufferUtils
• Add a unit test for IsomorphicRequest constructor on accepting another isomorphic request instance as the argument
• Update the documentation on how to read request body now

[kettanaito]

What a fantastic kick off of this idea! Thank you, @95th!

I've left a few comments and thoughts on the changes. I would like to know what you think about those. Let's discuss it, make whichever adjustments are necessary, and have a unified request handling!

[kettanaito]

The tests should be passing now! I've also added a few minor changes and left a roadmap in the pull request's description of what's remaining. You don't have to tackle everything that remains, just let me know what interests you and I can take care of the rest (like updating the docs).

[kettanaito]

We were previously parsing this, as event.detail is a string. Do we not need to parse it into object anymore? 🤔

[95th]

It is automatically serialized and deserialized

[kettanaito]

We should await this, as request.text() returns a Promise.

[95th]

We already return promise for it in the test:

function getRequestBody(page: Page): Promise<string> {
  return page.evaluate(() => window.requestBody)
}

and documentation for evaluate says:

If the function passed to the page.evaluate(pageFunction[, arg]) returns a [Promise], then page.evaluate(pageFunction[, arg]) would wait for the promise to resolve and return its value.

[kettanaito]

I'm also thinking of how the IIR will be propagated to the request listener. It'd be great to just reuse the IsomorphicRequest instance provided by this library in MSW, but what this library exposes is an interactive instance, meaning it has the respondWith() method. At the same time, the req` in MSW handlers must not have such method, and should be a barebones iso request instance.

I'm thinking of something like IsomorphicRequest.clone(): IsomorphicRequest that'd create a clean instance of request upon use. Since IIR extends IR, it will also have the .clone() method but will return a plain request without the respondWith() method.

What do you think about this approach?

[95th]

I think we should have a MockedRequest extends IsomorphicRequest which include cookies etc and it won't expose the respondWith details in the type system.

export class MockedRequest extends IsomorphicRequest {
  public cookies: Record<string, string> = {}
  public redirect = 'manual'
  public referrer = ''
  public keepalive = false
  public cache = 'default'
  public mode = 'cors'
  public referrerPolicy = 'no-referrer'
  public integrity = ''
  public destination = 'document'
  public bodyUsed = false
  public passthrough = passthrough

  constructor(request: IsomorphicRequest) {
    super(request)
  }
}

[kettanaito]

This is by far the most enjoyable pull request in my open source journey. Thank you for collaborating with me on this!

[kettanaito]

Released: v0.17.0 🎉

This has been released in v0.17.0!

• 📄 Release notes
• 📦 npm package

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

---

Predictable release automation by @ossjs/release.