Fetch API Support Beta

[kettanaito]

Hey! Thank you for taking the time to help us with the next library release. We’re approaching this one as a release candidate because it contains quite a number of breaking changes.

• Feature proposal
• feat!: adopt the global Fetch API #1436

Motivation

The main motivation behind this release is to rework the public API to respect and use the Fetch API standard. This means handling intercepted requests as Request instances and expecting the mocked responses to be declared as Response instances. While this may sound simple, it requires a significant change to how MSW is used by each of you.

This is also the biggest API change we’ve had since the day I pushed the req, res, ctx API. With this release, that era is gone and so is that API. The next era begins and it looks fantastic.

Before you begin

The purpose of this beta release is to gather your feedback on the changes. We kindly ask you to share such feedback in the comments under this discussion, following these rules:

1. Please browse the existing comments below before posting yours. If you spot a similar topic, please leave a comment under it describing your more detailed case.
2. 1 post = 1 issue/topic. Please note that you can comment under your own post if you wish to provide additional info or respond to somebody’s comment.
3. Please be patient. This is a huge change, and we trust it to be our common goal to make it as smooth as possible for everyone.
4. Link reproduction repositories to reported issues. This will help us tackle the issues tremendously faster.

Getting started

👉 Please follow the Migration guide to learn more about how to install this beta release and the migration instructions for every feature we’ve changed or deprecated.

Expect breaking changes. It will require some effort to migrate any existing MSW setup to the new API but it’s going to be worth it.

What is expected from the participants?

• Report the things that the Migration guide failed to cover or covered insufficiently/incorrectly.
• Report the use cases which were troublesome to migrate.
• Share feedback on how to improve the migration guide.
• Report issues after migrating to the beta version.
• Share your opinion on the new API, its look and feel. Don’t be shy to share good feedback as well, if you’ve got any, we’ve worked hard on making this beta release happen.

---

Frequently asked questions

Are these changes backward-compatible?

No. Backward compatibility is beneficial when you want to have the advantage of the change while remaining on the previous API. This change, however, is about the API, so maintaining backward compatibility is not feasible for it. If you wish to use the previous API you can do so by staying on the previous version. However, you will update to these changes eventually as this is the public API we’re going forward with.

Are these changes “production” ready?

No. Be mindful that you’re trying out a beta release of the library. Things may and likely will change as we iterate through your feedback.

That being said, the API changes proposed in this release will end up in the public release, eventually. This is the direction we’re taking, so migrating to it may ease any additional changes you need to do in your setup once this release becomes public.

When is this release going to be public?

As soon as we gather enough feedback to be certain people can migrate to the new version without issues. We will then release the changes under the latest tag, updating the documentation respectively.

[elliotgonzalez123]

Greetings,

I started a fresh NextJs application, applied the new syntax to my handler, ran a simple test that checked for data after a GET request, and Jest blew up. If I switch back to the latest msw version and apply the old syntax, everything works as usual.

• Next v13.0.1
• axios v1.1.3
• Jest v28.1.0
• testing-library/react v13.4.0
• msw v0.0.0-fetch.rc-1
• Node v18.8.0

Handler:

export const handlers = [
  rest.get("https://catfact.ninja/fact", () => {
    return HttpResponse.json({ fact: "Hello", length: 4 });
  }),
];

Error:

Desktop/Dev/ci-cd-next/node_modules/@remix-run/web-fetch/src/lib.js:4
    export { ReadableStream, Blob, FormData  } from './package.js';
    ^^^^^^`

     SyntaxError: Unexpected token 'export'

      at Runtime.createScriptFromCode (node_modules/jest-runtime/build/index.js:1796:14)
      at Object.<anonymous> (node_modules/@mswjs/interceptors/src/interceptors/ClientRequest/utils/createResponse.ts:2:1)

[kettanaito]

This seems related to mswjs/interceptors#283 (review). @remix-run/web-fetch distributes in a format that not all apps may consume by default. We likely need to bundle that dependency as a part or @mswjs/interceptors.

[kettanaito]

Update

We've moved away from the Fetch polyfill and dropped Node.js < 18 support. This shouldn't be an issue anymore.

However, we don't currently have support for the latest Next (App router) and we likely won't have it until after v2.0 releases. It seems to be extremely Next-specific and I don't have the time capacity to look into it unless we team up with the folks from Next and achieve this together.

[committomaster]

It's probably worth mentioning the new Response.json() static method may be an alternative for MSW's HttpResponse.json(). There's also Response.redirect().

[committomaster]

Yes, I'm not against HttpResponse, and agree there are use cases that Response cannot cover. Just thought Response.json() might deserve a mention in the docs.

[kettanaito]

I think Response.json() is common knowledge. It's not the library's mission to teach you about Fetch API but rather to support you in using it. So, if you know Response.json() is a thing, you may try it in MSW. You may see we don't have it yet, and it may encourage you to read if it's a widely supported thing in general or not. Does this approach make sense to you?

[committomaster]

Fair enough. The docs mentioned that creating a JSON Response is too verbose, and I just wanted to point out that's not the case for much longer.

[kettanaito]

That's a fair point. Perhaps we should advocate for HttpResponse using a different argument than brevity.

[kettanaito]

Update

• Response.json() is great but it doesn't exist in node. Given this, we won't be mentioning it in the docs.
• We will list all examples in the docs using HttpResponse so it's easier for people to get started and not be confused about all the other recipes and suggestions we have. This is a sensible common ground (see my explanation above).

[committomaster]

From the migration guide:

Since Fetch API Headers do not support multiple values as the HeadersInit, to mock a multi-value response cookie create a Headers instance and use the .append() method to set multiple Set-Cookie response headers.

This is possible with an array of entries instead of a plain object:

new Headers([
  ["Set-Cookie", "sessionId=123"],
  ["Set-Cookie", "name=world"],
]);

[kettanaito]

I didn't know this one. Thanks for sharing, @committomaster! This is going straight to the docs.

[committomaster]

I think just passing the array to ResponseInit.headers should do the job. No need to manually instantiate Headers there.

[kettanaito]

A valid point. At this stage, the way people use ResponseInit.headers is common knowledge. I don't mind showcasing two examples: giving a plain object and giving a Headers instance.

[committomaster]

But the new Headers() part is redundant:

new Response(null, {
  headers: [
    ['Set-Cookie', 'sessionId=123'],
    ['Set-Cookie', 'gtm=en_US'],
  ],
});

[committomaster]

With all the breaking changes towards the standards, may I also suggest renaming rest to http? 😅

[committomaster]

My point was exactly that HTTP and REST are not interchangeable. What MSW calls rest is much more generic than REST as you said. It can be used to mock any HTTP API, including GraphQL APIs. Also, REST is just as protocol agnostic as GraphQL. It just happens to be most commonly used with HTTP, similarly to GraphQL. The difference is that GraphQL is a specification while REST is just a pattern.

[kettanaito]

I understand your point but see little value to do such a breaking change. The workflow here is to ask yourself what kind of API you're mocking:

• Okay, I want to mock a REST API, so I import rest;
• I want to mock a GraphQL API, so I import graphql.

There isn't really a thinking chain that goes: I want to mock a REST API, so I import http...

If this is semantically confusing, consider using an import alias:

import { rest as http } from 'msw'

[kettanaito]

Update

We will not be renaming rest to http. Although, this may change in the future as we introduce other protocols, like WebSocket. For now, rest remains rest.

[thepassle]

I dont mean to revive a zombie thread, but I kind of agree that http makes more sense than rest, not all requests are RESTful, but all RESTful requests are http requests. And even graphql requests are http requests 😅. Also at work we have some API's at work that are not RESTful.

I do see that its nice for a user to import graphql when you're mocking a graphql api (and I think you should keep that), but I do think it does make sense to rename rest to http. Whenever I need to mock a network request, my first thought is not "Is this a RESTful request?"

Especially when you're on the verge of making a breaking change, and you're considering to add something like WebSocket in the future anyway, I'd say the time is now; break away. In this case the breakage is pretty easily fixed by a simple find/replace any (rest. -> http.) anyway.

(and also IMO http.get('/api/foo', () => Response.json({})); is much nicer, but thats just personal preference 😛)

[kettanaito]

@thepassle, the more I think about this the more I think this may be a good step forward. http would stand for a protocol handlers while graphql would be a helper object. GraphQL is often done via HTTP in JavaScript, so it makes sense that you can mock a GraphQL operation using both graphql and http. If anything, I think it reads more nicely since GraphQL operations are not RESTful resources. Just as not all HTTP requests as RESTful resources, like you've rightfully pointed out.

I will roll out the change in the next release candidate. Thanks everyone for this discussion.

[dbritto-dev]

@kettanaito this is what I found implementing some tests -> https://codesandbox.io/p/sandbox/msw-standard-api-9z1f0h?file=%2Frest.spec.ts

Seems the Response instance from require('@remix-run/web-fetch') has a default content-type, the default value is text/plain;charset=UTF-8 I have no idea if that was intended or not but that's the reason of one the unit tests are failing. In the other hand HttpResponse is working as expected.

Note: I expected the same behavior as HttpResponse from Response

[dbritto-dev]

I tried in a Chromium based browser but I don't get that result for me is null

[committomaster]

If a response has any body, it's Content-Type will be text/plain.

There are also some conveniences built-in with the Response constructor, e.g. an instance of URLSearchParams as body sets the content type to application/x-www-form-urlencoded, or an instance of FormData sets the content type to multipart/form-data.

[kettanaito]

As we're using a third-party polyfill for these Fetch primitives, we delegate the responsibility to fulfill the specification to that polyfill. We won't be addressing behavior differences around this. But if there are any, I strongly encourage you to report them in https://github.com/remix-run/web-std-io/tree/main/packages/fetch.

[dbritto-dev]

That's Ok if that is the expected behavior from that package.

[kettanaito]

Update

We no longer depend on the Fetch polyfill and use the native Node.js Fetch API instead (based on Undici). I don't believe it has this issue.

[wKovacs64]

❤️ the new API. I tried it out in 3 projects and found myself just knowing what to do thanks to already knowing Request, Response, etc. rather than having to go look at MSW docs when I couldn't remember some context utility or whatever. Great job, looking forward to this being released!

The only frustration was not being able to use Node 18, but that applies to the current version of MSW as well so nothing new to report there.

[kettanaito]

Thanks for the feedback, @wKovacs64!

Yes, we don't have Node 18 support yet but I think there's an effort behind it. I'm certain that will happen one day.

found myself just knowing what to do thanks to already knowing Request, Response, etc. rather than having to go look at MSW docs

Expecting ads revenue from docs to drop 😄

[wKovacs64]

Yes, we don't have Node 18 support yet but I think there's an effort behind it. I'm certain that will happen one day.

I hope it's more urgent than "one day" as Node 18 is the active LTS (with 16 now in Maintenance). I'm unable to recommend/use MSW at work because of this, unfortunately. 😢

Expecting ads revenue from docs to drop 😄

😆

[kettanaito]

I've looked into the latest status on Node 18 support, and there's been a tremendous amount of work done by our contributors.

• Support Node.js v18 #1388

I see that the only thing pending is mswjs/interceptors#283, which, in itself, is complete but has issues with @remix-run/web-fetch being imported in Node 18. I hope that package supports Node 18 otherwise we're blocked.

If you have time, you could investigate an issue I'm having: mswjs/interceptors#283 (review). This also seems to be the very same issue reported above by @elliotgonzalez123.

[kettanaito]

Update

The latest release candidate for these changes supports Node.js 18+ and also ships with ESM support. A bright day on the modern tech street 🎉

npm install msw@next --save-dev

[xmlking]

I am testing with vitest here: https://github.com/xmlking/svelte-starter-kit/tree/main/src/mocks

env: node v18.11.0 , "cross-fetch": "3.1.5", "msw": "0.49.0" <--- Works
env: node v18.11.0 , "cross-fetch": "3.1.5", "msw": "0.0.0-fetch.rc-1" <--- Time out error

looking for any workaround or fix

[kettanaito]

Thanks for reporting this. This may be a bit hard to trace down since we don't officially support Node 18. Although the A/B you did with the public version seems to suggest the issue is in these new changes.

[kettanaito]

Now, as we ship Node.js 18 support, I'm going to look into this and see what's going on...

[kettanaito]

Okay, I see that the linked repo doesn't use the next version of msw.

@xmlking, I recommend taking a look at our new Examples suite that features a full Svelte integration. We haven't experienced any issues with Svelte + MSW during integration and E2E tests (and local development). Take inspiration from that example!

[christoph-fricke]

Love the upcoming changes! As already mentioned in #1436, I noticed a TypeScript bug when passing a predefined object to HttpResponse.json. I updated the original sandbox to include both synchronous and asynchronous examples as the problem appears in both: https://codesandbox.io/s/msw-next-i0eijp?file=/src/index.ts

[kettanaito]

Thanks for reporting this, @christoph-fricke! Will have to look into this one. Didn't spot any issues on the first glance. Something must be off with the response type inference. I suspected the async resolver to be the case but you're saying it's the same for the sync one too. I wonder how come our typings tests pass.

msw/test/typings/rest.test-d.ts

Lines 79 to 81 in 041ff3e

	rest.get<never, never, { id: number }>('/user', () => {
	return HttpResponse.json({ id: 1 })
	})

[christoph-fricke]

@kettanaito I find the problem really strange as well and don't really have a clue... I experimented a bit with the test you have linked.

It appears to work fine with previously created objects as expected:

rest.get<never, never, { id: number }>('/user', () => {
  const obj = { id: 1 };
  return HttpResponse.json(obj)
})

However, it fails once the type of obj is defined explicitly with an interface:

interface ID {
  id: number
}

rest.get<never, never, ID>('/user', () => { // <-- Fails here with a return error problem
  const obj: ID = { id: 1 };
  return HttpResponse.json(obj) // <-- Fails here with "Index signature for type 'string' is missing in type 'ID'"
})

Strangely, it works fine if the interface is replaced with a type:

type ID = {
  id: number
}

rest.get<never, never, ID>('/user', () => {
  const obj: ID = { id: 1 };
  return HttpResponse.json(obj)
})

[kettanaito]

Oh, I think this is a common issue when the expected generic type expects Record<string, unknown> but you provide an interface, which does not have an index signature type by default.

Temporarily, you can circumvent this by declaring your body type as a type, just as you did in the last example.

[christoph-fricke]

@kettanaito I think a found a simple fix for the problem, which can be found in the PR #1481.

[kettanaito]

Thank you so much for improving this release, @christoph-fricke! Merged.

[the-ult]

I'll repost my question regarding the new Beta and generics here:
@see: #1308 (comment)

What would be the proper way to use the Generics with the next MSWjs version?

• https://github.com/mswjs/msw/blob/feat/standard-api/MIGRATING.md#migration-guide
• https://dev.to/kettanaito/type-safe-api-mocking-with-mock-service-worker-and-typescript-21bf

What do you provide, when you don't have PathParams or a RequestBodyType. I'm mostly interested in providing the ResponseBodyType, cause I need the proper return Type.

Is this the correct way? (providing undefined feels a bit icky 🤔 😇 )

/**
   * Handle the requests for POPULAR Movies
   * @see: https://developers.themoviedb.org/3/movies/get-popular-movies
   */
//get: <PathParams<string>, RequestBodyType_2 extends DefaultBodyType, ResponseBodyType_2 extends DefaultBodyType = undefined>
  rest.get<{ movieId: string }, undefined, MovieDetail | MovieError>(
    'movie/:movieId',
    ({ params }) => {
      const movieId = +params['movieId'];

      if (movieId === 436_270) {
        return HttpResponse.json<MovieDetail>(BlackAdam);
      }

      if (movieId === 505_642) {
        return HttpResponse.json<MovieDetail>(WakandaForever);
      }

      return HttpResponse.json<MovieError>({
        status_code: 56,
        status_message: `Movie with ID: ${movieId} not found`,
      });
    }
  ),

N.B.

• WakandaForever and BlackAdam are JSON files, with slightly different content.

Would the proper way be like the above replies? Using never ?

Or maybe using something like <T = void> or using function overloading, so not all generics are required?

https://garbagevalue.com/blog/optional-generic-typescript

[kettanaito]

Update

The type signature of request handlers remains as follows:

type Handler<ParamsType, RequestBodyType, ResponseBodyType> =
  (p: ParamsType, reqBody: RequestBodyType, resBody: ResponseBodyType>): RequestHandler<...>

To annotate the request and response body types you use it like this:

import { rest } from 'msw'

rest.get<never, RequestBody, ResponseBody>('/resource', () => {})

The latest release candidate msw@next should come with proper type inference already.

You use never when you don't wish to annotate request path parameters. You can also use void.

[the-ult]

Looks like with the latest version: "msw": "0.0.0-fetch.rc-3", Cypress (12.0.2) gives an error:
(version "msw": "0.49.1" does not give an error)

Error: Webpack Compilation Error
.../angular-nx-playground/node_modules/.pnpm/@[email protected]/node_modules/@remix-run/web-fetch/src/fetch.js 120:13
Module parse failed: Unexpected token (120:13)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
| 			}
| 
> 			response_?.emit("error", err);
| 		});
| 
 @ .../angular-nx-playground/node_modules/.pnpm/@[email protected]/node_modules/@remix-run/web-fetch/src/lib.node.js 1:0-72 1:0-72 1:0-72 1:0-72 1:0-72 1:0-72
 @ .../angular-nx-playground/node_modules/.pnpm/[email protected][email protected]/node_modules/msw/lib/index.js
 @ .../angular-nx-playground/libs/shared/test/msw/src/lib/server/server.ts
 @ .../angular-nx-playground/libs/shared/test/msw/src/lib/server/index.ts
 @ .../angular-nx-playground/libs/shared/test/cypress/src/lib/msw/msw.command.ts
 @ .../angular-nx-playground/libs/shared/test/cypress/src/index.ts
 @ ./src/e2e/movies-page.cy.ts
    at Watching.handle [as handler] (/Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/packages/server/node_modules/@cypress/webpack-preprocessor/dist/index.js:231:23)
    at /Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/node_modules/webpack/lib/Watching.js:99:9
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:6:1)
    at AsyncSeriesHook.lazyCompileHook (/Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/node_modules/tapable/lib/Hook.js:154:20)
    at Watching._done (/Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/node_modules/webpack/lib/Watching.js:98:28)
    at /Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/node_modules/webpack/lib/Watching.js:73:19
    at Compiler.emitRecords (/Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/node_modules/webpack/lib/Compiler.js:499:39)
    at /Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/node_modules/webpack/lib/Watching.js:54:20
    at /Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/node_modules/webpack/lib/Compiler.js:485:14
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:6:1)
    at AsyncSeriesHook.lazyCompileHook (/Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/node_modules/tapable/lib/Hook.js:154:20)
    at /Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/node_modules/webpack/lib/Compiler.js:482:27
    at /Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/node_modules/neo-async/async.js:2818:7
    at done (/Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/node_modules/neo-async/async.js:3522:9)
    at AsyncSeriesHook.eval [as callAsync] (eval at create (/Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:6:1)
    at AsyncSeriesHook.lazyCompileHook (/Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/node_modules/tapable/lib/Hook.js:154:20)
    at /Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/node_modules/webpack/lib/Compiler.js:464:33
    at /Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/packages/server/node_modules/graceful-fs/graceful-fs.js:143:16
    at /Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/packages/server/node_modules/graceful-fs/graceful-fs.js:143:16
    at /Users/ultimate-solutions/Library/Caches/Cypress/12.0.2/Cypress.app/Contents/Resources/app/packages/server/node_modules/graceful-fs/graceful-fs.js:61:14
    at FSReqCallback.oncomplete (node:fs:197:23)

[kettanaito]

Thanks for reporting this.

This may be related to the bundling of @remix-run/web-fetch. We have some work done on that on the Node side, I expected it to use browser globals in the browser. This needs looking into.

[the-ult]

Application and Jest tests (with testing-library-angular) work without a problem. Only the Cypress tests seem to fail (while loading).

Tried to debug, but could not really find anything other than that it must be related to "@remix-run/web-fetch": "^4.3.0", in the new package.json

[kettanaito]

Update

We no longer depend on the Fetch polyfill. This issue should be solved on the latest release candidate msw@next.

[nickrttn]

Hi folks! I've been using the Fetch API support to set up mocking for a mature codebase for the last week or so and it's been great. Use cases include a lightweight E2E testing suite that catches the most egregious errors, as well as a light weight development environment for our designers. It's a lot more intuitive than the previous iteration and it works really well. Two things that stood out to me and I wanted to point out to you:

• Currently, when I'm working on MSW handlers in development mode (we're still on webpack-hot-middleware), and I save, I get errors about already consumed Response bodies (Uncaught (in promise) TypeError: Response.clone: Body has already been consumed.) originating from serializeResponse. A hard refresh fixes those. Is this just a quirk of running MSW in a service worker or should this not be happening?
• Then, I have a need to set cookies and it would be great to have some sort of API for that. I really appreciate things being as close to 'platform-native' as they can be. However, the current API of writing out the bare header for Set-Cookie is pretty tricky to use.

[kettanaito]

Hey, @nickrttn! Thank you so much for your feedback.

I think the HMR bug is triggered by the handlers' code being re-evaluated upon HMR. Would be great to look into that. Would you mind isolating your dev setup (or creating a minimal one based on yours) for me to look at?

Regarding response cookies, you can use third-party libraries to help you compose cookie strings:

import cookie from 'cookie'

return HttpResponse.text('hello', {
  headers: {
    'Set-Cookie': cookie.serialize('token', 'value', {
      httpOnly: true,
      maxAge: 356000
    })
  }
})

I'm not planning on adding any cookie-related utilities in the nearest future.

[nickrttn]

Hey @kettanaito!

Thanks for your swift response :)

Would you mind isolating your dev setup (or creating a minimal one based on yours) for me to look at?

I'm working on a project with some legacy and a fairly complex setup, so I'll give it a try but it might be a while!

I'm not planning on adding any cookie-related utilities in the nearest future.

This is what I suspected, and understandable! I'll take a look at some third-party options.

[WesleyYue]

The Fetch API spec explicitly bans body on GET requests, despite this being quite common in the wild (and not explicitly banned by the HTTP spec). Stripe, Elasticsearch and many others all have API designs that require body in GET requests. node-fetch, axios also allows this.

[kettanaito]

No worries. We're all here to learn.

I will take a look at that Stripe example, thanks for putting that up.

[kettanaito]

I looked into the Stripe API briefly, and here's the implementation of GET /v1/prices:

https://github.com/stripe/stripe-node/blob/301f41df89169f49cd7b704adf1eaed6f903668c/lib/resources/Prices.js#L18-L22

At the top, you can see the mention that the implementation is generated from their OpenAPI spec. Let's dig that out. Here's the spec for GET /v1/prices (I'll highlight the relevant parts, the spec is rather verbose):

  /v1/prices:
    get:
      description: <p>Returns a list of your prices.</p>
      operationId: GetPrices
      parameters: 
        - description: >-
            A limit on the number of objects to be returned. Limit can range
            between 1 and 100, and the default is 10.
          in: query
          # Here's the "-d limit=3" parameter
          name: limit 
          required: false
          schema:
            type: integer
          style: form
      # And here's the specification for this request's body.
      requestBody:
        content:
          application/x-www-form-urlencoded:
            encoding: {}
            schema:
              additionalProperties: false
              properties: {}
              type: object
        required: false

You can see that the limit is listed as a parameter. More on that, it's defined as a query parameter (in: query). As I suspected, you don't send any body to this method, you include its data in request's query parameters!

So here's how you use that API correctly according to the Stripe API docs:

GET https://api.stripe.com/v1/prices?limit=3

At the same time, the requestBody of GET /v1/prices is explicitly stated to be a type: object with no properties (properties: {}) and no additional properties allowed. In human language, this means the body must be never present.

[WesleyYue]

As I suspected, you don't send any body to this method, you include its data in request's query parameters!

That makes sense to me. In that case, do you have any clue why interceptor raises the typeerror for that call then? If you run the codesanbox, you get this:

[dbritto-dev]

@WesleyYue shouldl works without any issues but may something goes wrong. Here is the code -> https://github.com/stripe/stripe-node/blob/master/src/makeRequest.ts#L66. May since we are intercepting the request a passing the response directly that is throwing an error. Ref: https://github.com/stripe/stripe-node/blob/master/src/StripeResource.ts#L198

[kettanaito]

Update

We no longer depend on Fetch polyfills and instead use the Node's global Fetch API. Whatever behavior Node exhibits MSW will also exhibit. If Node throws on GET requests with a body, it will also do so while handling requests with MSW (we don't really introduce any logic regarding this; bet on the platform).

This is no longer an issue.

[thomasbertet]

Hi,

🐛 I noticed an incompatibility between whatwg-fetch polyfill and the rc3 version.

Bug

The bug is that response headers won't be added to the Response headers object.
Ex: Doing const response = HttpResponse.json(content, { headers: { 'x-custom-header': 'value' } } will not add this header when whatwg-fetch is imported. (also true for other .text() & co.)

Repro

You can see the repro case here : https://codesandbox.io/s/mystifying-haze-selkxr?file=/src/index.js (try to comment out the whatwg-fetch import)
Having the polyfill import, it will not take any custom header into account. (see Terminal output in code-sandbox)

Explanations

The logic inside the whatwg-fetch is pretty narrow when merging headers: it only do it when Headers is the object from whatwg-fetch or an array/simple object, but msw is passing a different Headers object from headers-polyfill which is sad.
So basically it ignores everything inside headers prop, and returns a new "content-type".

Here is how rc3 version is creating the Headers object from headers-polyfill:

Here is how whatwg-fetch is merging Headers (see how it merges the passed headers if object/array/Headers from its package) (code) :

Here is how whatwg-fetch is defaulting a content-type that you see in repro: (code)

Here is a little something to help understand (maybe :D)

Solutions

What do you think we should do here ? Few suggestions I had in mind, feel free to suggest a better alternative:

• Would it be possible to detect if whatwg-fetch (which is I believe a pretty decent and popular fetch polyfill) is imported already and use that Headers instead of the other headers-polyfill object ?

• Would it be possible to use whatwg-fetch all-together by msw at some point ? Not sure it's a great idea, but it came to my mind :)

• Expect the "official" Fetch API to be added in user-land instead of integrated inside msw ? ie. give guidance on how to polyfill it instead of doing it automagically.

• Do not decorate the headers and keep simple plain object instead ?

What do you think ?

Thank you for maintaining this great project. We are using it quite a lot at Datadog 💌 .

[thomasbertet]

Great! thanks! Any ETA as to get a new RC available ? :)

[kettanaito]

@the-ult, based on the early results of a Twitter poll I've conducted, it looks that almost half of the participants are using Node 16. Doesn't look like we can drop it before August 2023 when it reaches EOL. I do hope to release these changes in a few months though.

But overall, I like your proposal: release with the polyfill, test things out, deprecate Node < 18 support in August and drop the polyfill.

[kettanaito]

@thomasbertet, should release this before the end of the week. I wish my automation tool had per-branch release rules + tags. Wrote that down as the next feature I work on there.

If you're in a hurry, you can always include GitHub pull request as a dependency.

[the-ult]

Wouldn't expect upgrading Node to be such a problem for most projects.. 🤔
Good thing you conducted the Twitter poll. 👍🏼

Keep up the awesome work

[kettanaito]

Update

Since we've decided to drop support for Node < 18 in this release, there is no need to include Fetch polyfills during testing at all now. I believe that solves the issue by itself.

[thomasbertet]

Hi! I have to admit I'm a bit surprised having the 1.0.0 released 5 days ago without this change. I thought we were going to have this new API in the next major version. It seems like a concern for consumers that they will have to upgrade to 1.0.0 and then probably a 2.0.0 with this Fetch API-like feat in a few weeks? Curious what's your reasoning around that :)

[kettanaito]

Hey, @thomasbertet.

Yeah, I understand the confusion. 1.0.0 has only a few breaking changes since the latest pre-released version (0.49.3 or so). It's not a major API overhaul.

We will release the Fetch API support in 2.0.0.

[tsteckenborn]

Somehow I'm encountering a curious situation. Did anybody else notice something similar?

I'm using a framework exposing a wrapper around Axios for doing external calls. Also running Node 18 right now.

When using return HttpResponse.json(); I receive an empty string as a response. Using return HttpResponse.json({}); I don't seem to receive any response. The call seems to be stuck. I'm not getting any error. Trying to debug my VSCode seems to be freezing when I try to step into HttpResponse.json.

In case somebody encountered something similar I'd be curious what happened.

[kettanaito]

Hi, @tsteckenborn. Thanks for reporting this. We've recently migrated our toolchain to Node 18 and you can give that version a try under the next tag:

npm install msw@next

I remember some weird issues during that migration but they should be fixed now. Please give it a try and let me know.

[dxlbnl]

I'm having difficulty running the mockServer with jest (on node). I've tried importing Response from 'msw', but it's not being exported. And then again, I'm using HttpResponse, but still getting the error.

ReferenceError: Response is not defined

Traceback is pointing to HttpResponse.js line 25.

class HttpResponse extends Response {...}

don't see any import happening in this file.

happening on rc-14

[kettanaito]

Hi, @dxlbnl. This error has to do with Jest explicitly removing Node.js globals, such as Request and Response (given you're using Node.js v18+, which you absolutely should as a part of migrating to this new version of MSW).

Because you're using Jest, you have to manually enable those globals as a part of your test setup. Here's what we have in jest.config.js to properly enable Fetch API globals in Node.js:

msw/test/jest.config.js

Lines 22 to 25 in 17f72e8

	globals: {
	Request,
	Response,
	},

Overall, I'd recommend migrating away from Jest. It doesn't play nicely with Node.js globals, forcing you to write additional configs just to satisfy Jest, it doesn't support ESM, and it's generally not well-maintained. Consider tools like Vitest instead.

[TeChn4K]

Hi

I started a fresh NextJS project (pages dir) and everything is running great for now.

• MSW 0.0.0-fetch.rc-14
• NodeJS 18
• NextJS 13.4.7

Thanks a lot for this great piece of software 👍

[kettanaito]

Hey, @TeChn4K! Thanks for your kind words.

Note that we currently have no support for the App directory in Next.js (see #1644 to track the progress on that). I'm happy to hear MSW runs smoothly for you using Pages! 🎉

[jonnedeprez]

We're also successfully using rc14 in a Vue 3 / Vite project.
This release finally made it possible to intercept uploads of binary data and the TS bindings seem to be fine. Thanks a lot!

Is there a plan to merge it into the main branch?

[kettanaito]

Excited to hear that! 🚀

Is there a plan to merge it into the main branch?

The release itself is stable and I don't anticipate any major changes to it. That being said, it is quite a breaking change, and I'm still working on updating our docs to help people migrate easier. I'd expect this version to land as latest in NPM sometime later this year (based on my availability).

Meanwhile, you can rely on msw@next with absolute certainty.

[luisr-carrillo]

Hi.

I am trying to implement MSW with fetch on my project but I get this error when I run it:
Cannot find module 'msw/node'from 'src/mocks/server.js'

It is a basic implementation of MSW:

import { setupServer } from 'msw/node';
import { handlers } from './handlers.js';

export const server = setupServer(...handlers);

I tried with msw/lib/node but I also get the error.

This is what I am using:

• Node: 18.16.1
• Webpack: 5.75.0
• Jest: 29.6.0
• MSW: 0.0.0-fetch.rc-15

[kettanaito]

Hi, @colinsullivan. I've opened a pull request that fixed your tests: colinsullivan/msw-next-jest#1. All I did was copy our existing Jest example from this repo. I highly encourage you to go to those examples whenever you have a problem with MSW + XYZ, they are helpful.

I've also left the key comments on my changes, explaining what I changed and why I did so. The tests are passing now, and your testing setup is as bulletproof as Jest allows it. If you found my help useful, consider Sponsoring the project. It helps us keep working on MSW and ship better experience to everyone. Thank you!

[colinsullivan]

Thanks! Much appreciated - I missed the examples repo.

[kristojorg]

I am getting this error not when using jest but just running nextjs 13 with MSW enabled

[dhenneke]

I'm also getting this error with the released msw 2.0, but the example repo helped. However, now I'm getting TypeError [ERR_INVALID_ARG_TYPE]: The "eventTargets" argument must be an instance of EventEmitter or EventTarget. Received an instance of AbortSignal. This also happens when I update this example to version 2.0.0.

[kettanaito]

Thanks, @dhenneke! I can also confirm that issue.

[thw0rted]

Not sure there's anything you can actually do about this at the moment, but there's an issue with using msw@next on server side in a TypeScript project.

HttpResponse.text('an error', {status: 400}) is a valid response but it fails type-checking. This is because the second argument is typed as HttpResponseInit, which inherits from ResponseInit, which doesn't actually exist in @types/node at the moment (it's a whole thing!). Bottom line is that users will have to patch fetch-related types into the global type space, if they haven't already, e.g.:

declare global {
  interface ResponseInit {
    status?: number
  }
}

They can also import the interface from undici, which is the implement native Node fetch uses under the hood.

import type {ResponseInit as NodeRI} from 'undici';
declare global {
  interface ResponseInit extends NodeRI {}
}

I just started using msw today, and currently I'm patching in ResponseInit and Request. I assume I'll have to add more later, or maybe I'll just try to get the types imported into @types/node already...

[kettanaito]

Hi, @thw0rted. I think you're right. To my surprise, Node doesn't really declare the ResponseInit type. Those seemed to have always been inferred from lib/dom by TypeScript.

The path of least resistance here is to depend on undici for types only on the MSW's side. Would you be interested in opening a pull request to the feat/standard-api branch to add this fix? I'd be thankful.

[thw0rted]

Unfortunately it gets a little complicated. As a library author, you don't have control over whether or not your consumer's tsconfig includes lib: ['dom']. Obviously browser projects will have this, and a lot of server-side projects either don't know to disable it, or intentionally leave it on to get browser-compatibility types, and just ignore the stuff like window that they know won't actually exist at runtime. Running without lib/dom is definitely not the norm but it's going to get more common as TS support for Node improves.

You could include undici as a dependency or peerDependency, but you would be forcing your browser-targeting consumers to install a Node-specific library. The types for undici add all of @types/node to the type-space as well. This how frontend devs wind up with weird behavior like multiple call signatures for setTimeout, a global process variable, etc.

This would also mean that the types for msw become very slightly inaccurate. It's hard to compose a real world example, but Node's implementations of "web compatible" global types sometimes include the ability to work with legacy Node classes (like Buffer), diverging from the lib/dom types. It probably won't have noticeable impact but it's something you should be aware of before proceeding with a PR.

[kettanaito]

but you would be forcing your browser-targeting consumers to install a Node-specific library.

This is never an issue. There is no dependency cost in question in developer tooling. You don't ship MSW to your users, so it has no effect on performance, so the number or size of its dependencies becomes irrelevant. Even now, every MSW user also installs a graphql package even if they don't plan on mocking GraphQL APIs. There hasn't been a single concern about it.

It probably won't have noticeable impact but it's something you should be aware of before proceeding with a PR.

To work around this, we can create ambiguous types that will pickup whichever ResponseInit already present in your environment and if not, default to using undici types.

[thw0rted]

To work around this, we can create ambiguous types that will pickup whichever ResponseInit already present in your environment and if not, default to using undici types.

I actually started to address this in my previous comment but ran out of time to write a response. The problem is that TypeScript doesn't really support "conditional include" for types -- it's difficult to "detect" whether global types from lib: ['dom'] are present or not. (If you have a clean approach for this, I'd love to see it, since I've been trying to implement something like this in @types/node proper for months....) Unconditionally merging undici types into the global type-space probably won't have disastrous consequences for anybody, but like I said it will make the global types very slightly wrong.

[ealejandrootalvaro]

Hello!

I am trying to use MSW and Playwright and I am following the migration guide for it to work with nodejs 18. I updated the setupWorker import to be like this import { setupWorker, SetupWorker } from 'msw/browser'; but when I try to run the tests I get this error Error: Package subpath './browser' is not defined by "exports" in ..../node_modules/msw/package.json

• Node v18.16.1
• MSW 0.0.0-fetch.rc-15
• Playwright 1.33.0

[dbritto-dev]

@ealejandrootalvaro you can't use msw/browser on a node env but you can use this -> https://github.com/valendres/playwright-msw

[ealejandrootalvaro]

Hi @dbritto-dev, we are using playwright-msw, but when we updated to nodejs 18 and the next version of msw, the playwright-msw dependency stopped working. I am trying to fork that dependency and follow the migration but I have had problems with some imports that no longer exist and I don't see any mention in the migration guide.

That's why I'm trying the msw integration on my own.

[dbritto-dev]

@ealejandrootalvaro you could try following the same pattern that playwright-msw implemented but tbh I wouldn't use msw since playwright do the same

[ealejandrootalvaro]

MSW has more features than the built-in playwright mock api, for example https://mswjs.io/docs/api/response/once

[dbritto-dev]

in that case you can try to implement your own version of playwright-msw but should be made on top of browserContext.route() or page.route() -> https://playwright.dev/docs/network#missing-network-events-and-service-workers you can't use msw/browser for that

[negabaro]

Hey there, I'm getting

console error

unhandledRejection: Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'statuses' imported from
node_modules/msw/lib/core/utils/HttpResponse/decorators.mjs
    at new NodeError (node:internal/errors:405:5)
    at packageResolve (node:internal/modules/esm/resolve:887:9)
    at moduleResolve (node:internal/modules/esm/resolve:936:20)
    at defaultResolve (node:internal/modules/esm/resolve:1129:11)
    at nextResolve (node:internal/modules/esm/loader:163:28)
    at ESMLoader.resolve (node:internal/modules/esm/loader:835:30)
    at ESMLoader.getModuleJob (node:internal/modules/esm/loader:424:18)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/module_job:77:40)
    at link (node:internal/modules/esm/module_job:76:36) {
  code: 'ERR_MODULE_NOT_FOUND'
}

browser error

./src/mocks/server.ts:2:0
Module not found: Package path ./node is not exported from package 
node_modules/msw (see exports field in
import { setupServer } from 'msw/node'

src/mocks/server.ts

import type { RequestHandler } from 'msw'
import { setupServer } from 'msw/node'

export const server = (handlers: RequestHandler[]) => {
  return setupServer(...handlers)
}

environment

Node v18.17.1
nextjs: 13.4.12
msw: v0.0.0-fetch.rc-16

Please let me know if there are any other solutions or improvements.

[thw0rted]

UPDATE: never mind -- already fixed! Don't you love when just updating a dependency resolves an issue for you? jestjs/jest#13868

Original text was:

---

I have one smallish new piece of feedback. I might be using it wrong, but if I accidentally write a handler-function that throws, I'm not seeing the content of the error in my test console. Example:

const testUrl = 'http://handled/url';
const handlers = [
  rest.get(testUrl, () => {
    // Oops, Infinity is a bad status, this throws
    return HttpResponse.text('OK': {status: 20/0})
  });
];

// Set up server.listen etc here

it('shouldn't fail here', async () => {
  const resp = await fetch(testUrl);
  expect(await resp.text()).toBe('OK');
})

This logs "TypeError: Failed to fetch", pointing at the fetch call, without any details about the exception that threw out of the handler-callback. I had to step through in the debugger to notice that I was suddenly in a catch block, to figure out what the root cause was.

I see that the interceptor does attach the root-cause in the cause argument to the Error constructor, so maybe I just need to take this complaint to Jest, or Node....

[kettanaito]

Hey, @thw0rted. Glad to hear the issue has been resolved!

The one related to the exception is a bit tricky. If you think of MSW handlers as server-side handlers, then exceptions on the server must, indeed, be represented by Failed to fetch and you never knowing about their details. We try to reach middleground by exposing the original exception in the rejected error.cause so you could debug it but I understand your frustration.

Forwarding exceptions to the user is a double-edged sword. If you are not intending an exception than that forwarding will certainly be useful. But if you are throwing on purpose, say to emulate a server-side error, then you don't wish to have those exceptions visible—you expect them.

At the time being, I find the error.cause approach to be the best of two worlds.

[thw0rted]

I also like having wrapped/nested errors like this, the only real downside is that the cause property is pretty new (ES2022) so support in the ecosystem is still evolving. It'll get there, though...

[kettanaito]

Let's leave it as it is right now and father more feedback once this version is the default for everyone to use. If this grows extremely annoying and people would be complaining about this, then I don't mind providing a mechanism to surface these exceptions in a more prominent way.

[thw0rted]

Once this leaves beta, it might be worth a footnote in the docs. Jest added first class cause support, which is great, but I'm not sure about other frameworks, or even just users stuck on older Jest versions.

[tsteckenborn]

I'm currently receiving Property 'url' does not exist on type 'StrictRequest<DefaultBodyType>'.ts(2339) when trying to read request.url on an HTTP request resolver with msw ^0.0.0-fetch.rc-16. Anybody else has the same issue? Same e.g. for method and the like.

[thw0rted]

You might find my previous thread here interesting. A lot of people do still use DOM types for server side code, and it won't actually break anything, but it can introduce some inconsistencies. If you want to leave lib-dom out of it, you can use undici types directly instead. It's more complex to set up, though, so there's a tradeoff either way.

[kettanaito]

Yeah, I remember our discussion on this. Do I understand it correctly that dom is necessary because @types/node don't ship the type definitions for Request and friends? If that's the case, then you have to rely on dom anyway when working with Fetch API. In that situation, we shouldn't change anything on our end. As long as it's not MSW types that are leaking and causing people to opt-in into using additional type libraries.

[thw0rted]

Yes that's the gist of it. I don't think you change anything on your end, at some point @types/node is going to have to bite the bullet and add them.

If any of your code is Node-exclusive, you could import type {Request as NodeRequest} from 'undici' and use that, instead of the global Request, but I don't think that's your situation. All of your code is intended to be isomorphic, right?

[kettanaito]

We do have a Node-exclusive code but that's scoped under msw/node so you will never import it unless you intend to. When you do, you end up in the "Request type doesn't exist in Node" situation and should resolve it to the best means Node provides (including dom at the moment).

Thanks for elaborating on this!

[thw0rted]

Anyone interested in this thread might want to follow DefinitelyTyped/DefinitelyTyped#66824 , when closed it should add the correct fetch types to @types/node. Woo!

[mscottnelson]

I started a fresh node.js project and discovered msw. I thought it would be perfect for my scenario. At first I was disappointed at its inability to use fetch natively, and then I discovered this branch. I've been very happily using msw since 0.0.0-fetch.rc-16 and eagerly anticipate each commit made here. Thanks for doing such great work on this. Looking forward to v2.0.0!

[tomdglenn91]

Run into an issue on rc-20.

 ● Test suite failed to run

    ReferenceError: TextEncoder is not defined



      at Object.<anonymous> (../../node_modules/@mswjs/interceptors/lib/node/chunk-3LFH2WCF.js:2:15)
      at Object.<anonymous> (../../node_modules/@mswjs/interceptors/lib/node/index.js:7:24)
      at Object.<anonymous> (../../node_modules/msw/lib/core/utils/matching/matchRequestUrl.js:26:27)
      at Object.<anonymous> (../../node_modules/msw/lib/core/handlers/HttpHandler.js:51:30)
      at Object.<anonymous> (../../node_modules/msw/lib/core/http.js:24:26)
      at Object.<anonymous> (../../node_modules/msw/lib/core/index.js:38:19)
      at Object.<anonymous> (../test/server/src/server/index.ts:22:14)
      at Object.<anonymous> (../test/server/src/index.ts:29:17)
      at Object.<anonymous> (src/setup-tests.ts:10:1)

❯ node -v
v18.17.1

Not sure if anyone else has this error. Lemme know if any more info needed.

[kettanaito]

@cwagner22, please share a reproduction repository where I can look at this. Thanks!

[cwagner22]

@kettanaito Thanks, here it is: https://codesandbox.io/p/sandbox/affectionate-danilo-z8z8my
It indeed works in this example when using a node environment (test-node-jest command), but I need to use jsdom env.

[kettanaito]

@cwagner22, thanks. There's quite a number of issues with your Jest config:

1. It's not picked up by test at all. Try that by logging anything in jest.config.js, it won't get printed.
2. When pointed to use that config with react-scripts test -c ./jest.config.js. This will print a bunch of warnings and errors, stating that the Jest config is invalid. I'd probably recommend resolving those issues first before proceeding with MSW.

The bottom line remains the same:

• Jest strips globals.
• You have to re-add globals back.

Since the current jest.config.js doesn't get picked up by Jest, the globals you are setting in the config aren't doing anything. You also forgot to set the TextEncoder and TextDecoder globals.

Important

Please use the official Jest usage example. Just copy its setup or merge it with yours. It's functional with the next version of MSW.

[cwagner22]

Thanks for looking into it. Yes jest.config.js is not picked up when running the tests via react-scripts by design. The create-react-app tool doesn't allow overwriting some properties such as globals without "ejecting", in order to have access to the full jest config. I'm using a library called "customize-cra" that allows overwriting the jest config, but unfortunately, it seems to not be working when the globals are not primitives...
So instead I have set

import { TextEncoder } from 'util';
global.TextEncoder = TextEncoder;

inside a jest setup file (setupFiles: ["./src/msw.js"])

but now I don't know if I can do something similar for the Request/Response.

[kettanaito]

You can get the Fetch API classes from the undici package. That's what Node.js is uses to implement the Fetch API.

import { Request, Response } from 'undici'

globalThis.Request = Request
globalThis.Response = Response

[tomdglenn91]

Not sure if this is related to my previous issue or jsdom/jest environment, I can move this to a my previous post if necessary. In jsdom my server seems to send different responses that are not usable. As I'm testing react, I need to be in jsdom. I've made a pretty lightweight setup

const server = setupServer();

beforeAll(() => server.listen({ onUnhandledRequest: 'error' }));
afterEach(() => server.resetHandlers());
afterAll(() => server.close());

 beforeEach(() => {
    server.use(
      http.get<any>('http://localhost/jobs', () => {
        return HttpResponse.json({ success: true });
      }),
    );
  });


  it.only('should show the issue', async () => {
    const response = await fetch('http://localhost/jobs', {
      headers: { 'Content-Type': 'application/json' },
      signal: new AbortController().signal,
    });

    const result = await response.json();
    expect(result).toBeDefined();
  });

Two things I've noticed - i have to give it a signal, otherwise I get a "TypeError: Cannot read properties of undefined (reading 'addEventListener')"

Once I've given it a signal, I simply get a

SyntaxError: Unexpected end of JSON input
        at parse (<anonymous>)

only in jsdom! If i swap out the test environment for node, works fine. Same with the signal, funnily enough.

Apologies for the bombardment, appreciate the work you guys do. Not sure if this is the fault of jsdom or not.

[tomdglenn91]

It's part of a big ol' company monolith but I'll see if I can replicate if i extract everything out. Will try your suggestions with setting Fetch globals after

[tomdglenn91]

Frustratingly, and expectedly, I can't replicate in a standalone repo, even after copying the entire dang package.json, the tooling (nx) and a straight up copy paste of the offending code.

Funnily enough, your solution for providing Jest the globals fixes a lot of jsdom issues on my standalone. However, the company application doesn't get the same success. After adding console.log('request', Request); in jest.config.ts, I get

     TSError: ⨯ Unable to compile TypeScript:
   libs/http/jest.config.ts:2:24 - error TS2304: Cannot find name 'Request'.
   
   2 console.log('request', Request);

We've got a tree of tsconfigs but they LOOk correct, and jest.config.ts gets swept up with node types.. We are using swc for our transform though. That being said, this sounds like a me problem. If you have any ideas though I'd love to hear em as I'm stumped atm 😅 . If I get any progress with replicating the signal issue i'll post here with an update.

[thw0rted]

If it helps at all, I think Jest has a longstanding open issue where the jest.config.ts is compiled using a different tsconfig file than is used for actually building your tests. Could that be your issue here? (We just went ahead and ported our config to vanilla JS.)

[csantos1113]

JSDOM is lacking way behind features, this might help you: jsdom/jsdom#1724 (comment)

[tomdglenn91]

I hit a git clean, a fresh yarn install, and now Request is populated. No idea if something got stuck in cache or whatever but it's now finding Request and I'm terrified to touch it again.

[wrporter]

I looked through the changes in the migration guide, and I'm really looking forward to the standardization on the fetch spec! This is fantastic work. I've really loved msw for the past two years. It really makes integration testing so much easier!

What's the current status for releasing v2? What is lacking prior to cutting a production release?

[thepassle]

It should be done soon™️ :)

[kettanaito]

So happy to hear that, @wrporter! The public release of V2 is coming this month. Meanwhile, you can already migrate and use it under msw@next. Excited for this change as well!

[bukanidzee]

Hello everyone, I'm trying to write simple app and some tests for it with jest. In my app I'm using redux-toolkit-query and tried to use msw for mocking as docs suggest and with regular version of msw everything worked fine untill form that sends Formdata to server. To fix it I installed msw@next and did all migrations as required, but now I only get TypeError: Failed to fetch error in response to all attempts to make fetch request

Node version

v18.18.2

Packages versions

"react-redux": "^8.1.2",
"@reduxjs/toolkit": "^1.9.5"

API reducer

const specificEndPoints = [
  'register',
  'postArticle',
  'updateArticle',
  'getArticleContent'
]

export const blogApi = createApi({
  reducerPath: 'blogApi',
  tagTypes: ['Articles', 'ArticlesDetail', 'ArticlesContent', 'Comments'],
  baseQuery: fetchBaseQuery({
    baseUrl: '/api/',
    prepareHeaders: (headers, { getState, endpoint }) => {
      const token = (getState() as RootState)?.user?.token

      if (token !== '') {
        headers.set('Authorization', `Token ${token}`)
      }
      if (!specificEndPoints.includes(endpoint)) {
        //   headers.set('Content-Type', 'multipart/form-data')
        // } else {
        headers.set('Content-Type', 'application/json;charset=UTF-8')
      }

      return headers
    }
  }),
  endpoints: () => ({})
})

Tested endpoints

export type ILoginResponse = {
  token: string
  userId: string
  name: string
  picture: string
  isAdmin: boolean
}
export const userApi = blogApi.injectEndpoints({
  endpoints: build => ({
    login: build.mutation<ILoginResponse, ILoginData>({
      query: body => ({
        url: 'auth/login',
        method: 'POST',
        body
      })
    }),

    checkAuth: build.query({
      query: () => ({
        url: 'auth/check',
        method: 'GET'
      })
    }),

    register: build.mutation<IFetchSuccess, FormData>({
      query: body => {
        return {
          url: 'auth/registration',
          method: 'POST',
          credentials: 'include',
          body
        }
      }
    })
  })
})

export const { useLoginMutation, useRegisterMutation, useCheckAuthQuery } =
  userApi

One of failed tests

const handlers = [
  http.post('/api/auth/login', () => {
    return Response.json(
      {
        userId: 1,
        name: 'Kovalev Aleksandr',
        token: 'fsafsefaefaewf',
        picture: null,
        isAdmin: false
      },
      { status: 200 }
    )
  })
]

const server = setupServer(...handlers)

// console.log(server.listHandlers())
describe('Login page', () => {
  beforeAll(() => server.listen())

  // Reset any runtime request handlers we may add during the tests.
  afterEach(() => server.resetHandlers())

  // Disable API mocking after the tests are done.
  afterAll(() => server.close())

  test('Login work', () => {
    renderWithProviders(<Login />, { router: 'browser' })
    const emailField = screen.getByLabelText('Email')
    expect(emailField).toBeInTheDocument()
    const passwordField = screen.getByLabelText('Пароль')
    expect(passwordField).toBeInTheDocument()
    const button = screen.getByRole('button')
    expect(button).toBeInTheDocument()
  })

  test('Login use', async () => {
    const { store } = renderWithProviders(<App />, {
      router: 'memory',
      routerProps: { initialEntries: ['/login'] }
    })
    const emailField = screen.getByLabelText('Email')
    fireEvent.input(emailField, { target: { value: '[email protected]' } })
    const passwordField = screen.getByLabelText('Password')
    fireEvent.input(passwordField, { target: { value: '123456789' } })
    const button = screen.getByTestId('login-submit')
    fireEvent.click(button)

    const avatar = await screen.findByTestId('logged-avatar')
    expect(avatar).toBeInTheDocument()

    const articleTitle = await screen.findByText('Articles')
    expect(articleTitle).toBeInTheDocument()
    const unloginButtons = await screen.findAllByText(/Logout/i)

    expect(unloginButtons).toHaveLength(2)

    const state = store.getState()
    expect(state.user).toMatchObject({
      userId: 1,
      name: 'Kovalev Aleksandr',
      token: 'fsafsefaefaewf',
      picture: null,
      isAdmin: false
    })

    fireEvent.click(unloginButtons[0])

    const loginButtons = await screen.findAllByText(/Войти/i)

    expect(loginButtons).toHaveLength(2)
  })
})

Component

export type ILoginData = {
  email: string
  password: string
}

const Login: FC = () => {
  const [sendLogin, { data, error }] = useLoginMutation()

  console.log({ data, error })
  const dispatch = useAppDispatch()

  const { handleSubmit, control } = useFetchForm<ILoginData>(error)

  const onSubmit = async (data: ILoginData): Promise<void> => {
    await sendLogin(data)
  }

  useEffect(() => {
    if (data !== undefined) {
      localStorage.setItem('auth', JSON.stringify(data))
      dispatch(login(data))
    }
  }, [data, dispatch])

  return (
    <CenterContainer>
      <StyledFormBox component='form' onSubmit={handleSubmit(onSubmit)}>
        <Typography variant='h4'>Login</Typography>
        <HookedTextField
          control={control}
          defaultValue=''
          label='Email'
          name='email'
          required
          autoFocus
          fullWidth
          variant='standard'
          type='email'
          sx={{
            color: 'inherit'
          }}
        />
        <HookedTextField
          label='Password'
          variant='standard'
          control={control}
          defaultValue=''
          name='password'
          required
          fullWidth
          type='password'
          sx={{
            color: 'inherit'
          }}
        />
        <Button type='submit' variant='contained' data-testid='login-submit'>
          Login
        </Button>
      </StyledFormBox>
    </CenterContainer>
  )
}

export default Login

[kettanaito]

MSW 2.0 is out! 🎉

As of today, [email protected] is out! (Release notes).

I would like to say a huge thank you to everybody who's contributed to that release in this discussion. You are incredible. I did my best to go through all the comments and mention you all in the announcement blog post. If I missed someone, pull requests are welcome!

I will lock this thread. I encourage you to report the issues with 2.0 as you normally would (by creating a new Issue in this repository). Thanks.