feat!: adopt the global Fetch API

[kettanaito]

This is a breaking change.

• Closes Adopt Fetch API primitives #1404
• Closes fix(parseMultipartData): add File polyfill for Node.js #991, fixes parseMultipartData don't work with File class in Node.js #947
• Closes fix: added support for FormData bodies in jsdom to MockedRequest (#1327) #1422
• Closes feat(worker): read request/response body from as ArrayBuffer #1332
• Fixes Support "req.formData()" #1327
• Fixes Support ReadableStream as a mocked response body #1336
• Potentially solves Response patching is misbehave with FormData #1158
• Fixes Provide a way (or document an existing way) to return a NetworkError once #413
• Closes Remove deprecated MockedRequest.body and cleanup #1318 since it's no longer relevant (no MockedRequest)
• Fixes Bypassed request's referrerPolicy is reset to default #1380
• Fixes Request bodies of URLSearchParams can not be read #1365
• Distributes the library as CJS and ESM for both browser and Node.js. Fixes ESM support + treeshaking unused bits #1384, fixes TypeScript definitions of msw/node don't work with modern node16-style module resolution #1427
• Fixes Request body with Protobuf binary data is corrupted #1442
• Closes Support Node.js v18 #1388
• Closes Return instructions from the resolver #1207

Migration guide

• MIGRATION GUIDE
• Share your feedback

Roadmap

• feat: adopt Fetch API Request and Response interceptors#292
  • fix(Request): support custom "credentials" value remix-run/web-std-io#21
  • fix: drop RequestWithCredentials internal interceptors#329
  • Bump @mswjs/interceptors
• Fix typings tests (our tests pass but the compilation from msw fails)
• Support type-safe request bodies (mainly JSON)
• Support type-safe response bodies
• Support ReadableStream as the mocked response body (internally: read/send request/response bodies as streams)
• Fix test/rest-api/cookies-inheritance.node.test.ts ambiguous response body type
• Restructure root-level exports
• Publish Interceptors as CJS/ESM and update it here.
• Fix request.formData() test (see NotSupportedError: multipart/form-data not supported nodejs/undici#1979). Just updating to the latest Node 18 will fix this.
• FormData: the node test hangs for some reason on request.clone():

pnpm test:node rest-api/request/body/body-form-data.node.test.ts --detectOpenHandles

Jest has detected the following 1 open handle potentially keeping Jest from exiting:

  ●  MESSAGEPORT

      154 |     return this.predicate(
      155 |       request,
    > 156 |       await this.parse(request.clone(), resolutionContext),
          |                                ^
      157 |       resolutionContext,
      158 |     )
      159 |   }

      at RestHandler.test (../../src/handlers/RequestHandler.ts:156:32)
      at ../../src/utils/getResponse.ts:34:20
          at Array.map (<anonymous>)
      at filterAsync (../../src/utils/getResponse.ts:21:44)
      at getResponse (../../src/utils/getResponse.ts:33:34)

• Resolve the wrong response clone in serializeResponse:

  ✓  60 [chromium] › msw-api/setup-worker/printHandlers.test.ts:14:5 › lists rest request handlers (1.7s)
Error [TypeError]: Failed to execute 'clone' on 'Response': Response body is already used
    at serializeResponse (webpack://msw/./lib/index.js?:548:34)
    at RestHandler.log (webpack://msw/./lib/index.js?:864:34)

• Resolve xhr.onload being called twice (XMLHttpRequest: "onload" is called twice interceptors#359)
• Publish MSW as CJS/ESM for both browser and Node.js.
• Decide how to distribute type definitions because you may want to access SetupWorkerApi in Node.js module to extend window when working with Playwright.
• Memory leak in node tests:

(node:3158) MaxListenersExceededWarning: Possible EventTarget memory leak detected. 11 abort listeners added to [AbortSignal]. Use events.setMaxListeners() to increase limit
    at EventTarget.[kNewListener] (node:internal/event_target:514:17)
    at EventTarget.[kNewListener] (node:internal/abort_controller:183:24)
    at EventTarget.addEventListener (node:internal/event_target:623:23)
    at Request.clone (node:internal/deps/undici/undici:7303:23)
    at RestHandler.<anonymous> (msw/lib/core/handlers/RequestHandler.js:109:53)
    at Generator.next (<anonymous>)
    at msw/lib/core/handlers/RequestHandler.js:53:61
    at new Promise (<anonymous>)
    at __async (msw/lib/core/handlers/RequestHandler.js:37:10)
    at RestHandler.run (msw/lib/core/handlers/RequestHandler.js:103:12)
    at msw/lib/core/utils/getResponse.js:66:35
    at Generator.next (<anonymous>)
    at fulfilled (msw/lib/core/utils/getResponse.js:23:24)

• Backport req.operationName (feat: add operationName to GraphQL request #1568)
• The statuses import must be assert { type: 'json' } but that gets stripped off during the build. Find the way to keep it or check it statuses exports a plain object.
• Resolve the @open-draft/logger installation issue with PNPM.
• Upgrade to an ESM version of cookie
• Fix graphql@16 accessing process in the browser (check "globalThis.process" before accessing it graphql/graphql-js#3887).
• Replace .printHandlers() by .listHandlers().
• Change the call signature of Life-cycle events listeners to use object-as-argument pattern.
• Fix unnecessary warning on anonymous GraphQL operations when using graphql.operation() test(graphql): add test on anonymous operation warning #1693
• Move request error message from the worker to the main thread #1683
• fix: remove "NetworkError" in favor of "HttpResponse.error" #1730
• fix(graphql): support request handler options #1739
• feat: set minimal supported typescript version to 4.7 #1742
• Update the jsdoc links for the API
• v2 - Max listeners warning in Node.js (likely the cloning issue) #1760
• fix(worker): replace Math.random() with crypto.randomUUID() #1762
• DataCloneError: The object cannot be cloned in Safari v17 (using fetch-based MSW) #1757

[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 90b854a:

Sandbox	Source
MSW React	Configuration
Demo of bug	Issue #1427

[kettanaito]

@thepassle, yes. I forgot for a moment how awesome Playwright is. Would you like to open a pull request with those?

[weyert]

@luchsamapparat btw, that's wrong you shouldn't use beforeAll and expect on setup files and if you are environment is jsdom in expected that the AbortController was patch by jsdom if you don't want that then you need to use enviroment: node

here you go -> https://codesandbox.io/p/sandbox/funny-flower-lfqywh?file=%2Fsrc%2Fabort-controller.test.ts%3A9%2C42

But wouldn't it still be a problem for when you use jsdom to test React/web code and use mew to mock some external web servers? You would still have the issue of AbortSignal being using msws instead of Node's EventTarget that Node is expecting?

[luchsamapparat]

@weyert exactly.

[dbritto-dev]

@weyert shouldn't be a problem since you can override the AbortController from jsdom instance with the one from node but if you use environment: jsdom all the globals are patched even before setup files. BTW, you can run some tests with environment: jsdom and other ones with environment: node

[christoph-fricke]

@weyert shouldn't be a problem since you can override the AbortController from jsdom instance with the one from node but if you use environment: jsdom all the globals are patched even before setup files. BTW, you can run some tests with environment: jsdom and other ones with environment: node

@kettanaito @luchsamapparat @dbritto-dev I went into the inner workings of Node.js to figure out why this error occurs in JSDOM environments and how we can prevent it to solve it for real, not just the symptoms. I found a rather simple solution that I have implemented in in PR #1779.

[kettanaito]

📦 v0.0.0-fetch.rc-24

• Fixes setMaxListeners issue in React Native;
• Fixes setMaxListeners issue in JSDOM (fix(setupServer): suppress "ERR_INVALID_ARG_TYPE" (AbortSignal) errors from "setMaxListeners" in jsdom #1779).

[thepassle]

Is there any particular reason why the tsconfig target is set to es6 and not something slightly more modern? The es6 target turns async/await into generator functions wrapped in __async, and a bunch of other seemingly unnecessary stuff:

Im asking, because I've had to debug something in MSW several times now, and its extremely painful to debug code like this. Perhaps we could consider raising the target to something a bit more contemporary?

edit: actually it may be esbuild doing this? TS's output names it __awaiter instead. In any case, can we just ship more modern code? async/await and spread has good node/browser support for a long time now

[kettanaito]

@thepassle, absolutely agree and absolutely welcome a pull request! 🙏

[thepassle]

@thepassle, absolutely agree and absolutely welcome a pull request! 🙏

#1780

[acidoxee]

I've spent some time yesterday migrating away about a thousand handlers to the new fetch API (currently on the fresh 0.0.0-fetch.rc-24), and I must say I'm liking this new API a lot.

BUT, I've been stuck all day on some failing tests using the new API. Not a lot though, which was surprising, and it turns out tests that fail are the ones that used res.once() (now migrated to the { once: true } option). While requests were properly intercepted and handled in v1, with the v2 API it's not the case anymore.

I'm NOT saying all once handlers don't ever match no matter the conditions. But I've narrowed it down to this: if I set up all of my handlers at the beginning of my test (which is often the case, because I'm not directly firing requests myself, it's lower-level code that's not directly accessible in my test, so I have no way to interlace MSW once handlers and fetch-related code one by one), and if there is at least one request that's not related to a once handler that fires away, all of my once handlers are immediately switched to { isUsed: true } and don't ever match afterwards, even if they did in v1.

The current v1 docs state the following about one-time overrides:

Request handler override can be used to handle only the next matching request. After a one-time request handler has been used, it never affects the network again.

There's also this code block, which states that the first matching request will receive the mocked response:

rest.get('/book/:bookId', (req, res, ctx) => {
  // The first matching "GET /book/:bookId" request
  // will receive this mocked response.
  return res.once(
    ctx.status(500),
    ctx.json({ message: 'Internal server error' }),
  )
})

I've created a quick reproduction here: https://stackblitz.com/edit/vitest-dev-vitest-xa3evs?file=test%2Fbasic.test.ts&view=editor. The test is green since I wanted to validate what I'm saying. Since the configured once handlers don't match the first request, they're not supposed to be flagged as used, and they should be kept "alive" for future potential matches, until one finally does. In my reproduction, there should even still be one once handler in the pool that should be unused, since only the first one should have been consumed.

Can you confirm this is a bug, and not a change in behavior expected in v2? Since I couldn't find any information about such a change, and since it would be extremely breaking for people who can't intertwine individual requests and once handlers' setup, I'm definitely leaning on the bug side 😉

[kettanaito]

Thanks for reporting this, @acidoxee.

Can you confirm this is a bug, and not a change in behavior expected in v2?

I confirm this is a bug. I will do my best to address it but it may be after the 2.0 release. Please, could you open a new issue about it? Thanks.

[acidoxee]

Here you go @kettanaito: #1782. Thanks a lot for all your hard work! 🙏

[weyert]

@weyert shouldn't be a problem since you can override the AbortController from jsdom instance with the one from node but if you use environment: jsdom all the globals are patched even before setup files. BTW, you can run some tests with environment: jsdom and other ones with environment: node

@kettanaito @luchsamapparat @dbritto-dev I went into the inner workings of Node.js to figure out why this error occurs in JSDOM environments and how we can prevent it to solve it for real, not just the symptoms. I found a rather simple solution that I have implemented in in PR #1779.

Yes, I totally agree I could use different environment depending on the need. Only I never have been able to get the /* @jest-environment jsdom */ docblock comment to work.

I haven't gotten it working yet in my unit tests in Jest for Next.js against newer than r20 versions. Wondering if I need to rewrite my tests or something 🤔 Everything is timing out in r24. I will play around tomorrow. I was thinking of switching to Vitest but not sure if that's a good idea compared to next/js+jest.

[dbritto-dev]

@weyert are you using jest or vitest?

[thepassle]

🎉

[kettanaito]

Released: v2.0.0 🎉

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