feat: add "requestId" as response resolver argument

[skvale]

Fixes: #1933

In MSW v1 I was able to access req.id in a handler function which corresponded with the requestId in events.

For example

worker.events.on('response:mocked', ({requestId}) => {
// and
rest.post('my-url', (req) => { req.id 

were the same value

In v2, the request object doesn't have an id attribute. From what I can tell the requestId is unique to events

This seems like a nice to have addition to the handler args that wouldn't be hard to add

[kettanaito]

Thanks for submitting this so quickly, @skvale! I will come back to review this in January.

[mattcosta7]

should this be required instead of optional? are we leaving it optional to avoid making it required for non-standard usage? just curious if we can accidentally miss this if it's optional?

[skvale]

I'm wondering if this is considered exposed of it's OK to change this function signature to get the required arg before the optional one

So from this

/**
 * Returns a mocked response for a given request using following request handlers.
 */
export const getResponse = async <Handler extends Array<RequestHandler>>(
  request: Request,
  handlers: Handler,
  resolutionContext?: ResponseResolutionContext,
  requestId?: string,
): Promise<ResponseLookupResult | null> => {

to this

/**
 * Returns a mocked response for a given request using following request handlers.
 */
export const getResponse = async <Handler extends Array<RequestHandler>>(
  request: Request,
  handlers: Handler,
  requestId: string,
  resolutionContext?: ResponseResolutionContext,
): Promise<ResponseLookupResult | null> => {

[kettanaito]

@skvale, I believe your last question is resolved since the run() method now accepts a single object argument where the argument position is irrelevant. Thanks for updating the PR!

[kettanaito]

The only thing I'm not sure about here is whether requiring requestId for the .run() method is right.

While this is not widely used, you can call a request handler directly using its .run() method. Just accepting request makes sense. Demanding requestId means the consumer has to contrive that ID. Hmm.

I think we can make this required and suggest using crypto.randomUUID() as a placeholder value if someone has to call a handler directly. If you want to—you must provide a request ID.

[kettanaito]

This looks fantastic! Great work, @skvale 👏

[kettanaito]

Welcome to contributors, @skvale! 🎉

[kettanaito]

Released: v2.1.0 🎉

This has been released in v2.1.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.