question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Support Node.js v18

See original GitHub issue

Prerequisites

Environment check

  • I’m using the latest msw version
  • I’m using Node.js version 14 or higher

Node.js version

v18.8.0

Reproduction repository

https://github.com/ericmasiello/msw-node-18

Reproduction steps

  1. Verify you are using node 18.8.0
  2. npm ci
  3. npm run test

Note that the tests pass but they actually should not. I’m using a toMatchInlineSnapshot(). That data snapshotted is the live data coming from real Pokemon API. what should be snapshotted is the mocked response I created in foo.test.ts

Current behavior

The tests pass because the msw is not intercepting the response. Therefore, the toMatchInlineSnapshot matches live data from the API.

Expected behavior

The tests should fail because the data should match the mocked response in foo.test.ts.

Issue Analytics

  • State:open
  • Created a year ago
  • Reactions:16
  • Comments:13 (2 by maintainers)

github_iconTop GitHub Comments

17reactions
joshuajacocommented, Oct 26, 2022

What is left for this? Node 18.12.0 is now the LTS and this is preventing us from updating.

12reactions
milesrichardsoncommented, Sep 8, 2022

Hey! I actually have a PR for this. Well, I have one simple PR, and then a series of more robust PRs. Let me summarize…

Background

  • Polyfilled fetch continues to be intercepted in Node 18 (mostly, I think)
  • Requests to IPv6 addresses will cause errors, regardless of fetch implementation. This might happen in tests that use localhost on an IPv6 system, because in Node 18, the resolution order has changed to prefer the order of OS resolution, instead of the previous behavior of preferring IPv4. You can revert to the previous behavior with the optional Node flag node --dns-result-order=ipv4first. This exposes the actual bug in msw (and some of its dependencies), which is incorrect URL serialization of IPv6 hosts (should be surrounded by brackets but is not, e.g. http://::1:80 should be http://[::1]:80).
  • “Node-native fetch” (aka Undici), which is enabled by default since Node 18, is not intercepted
  • The existing globalThis.fetch interceptor is able to intercept native fetch, but msw does not instantiate FetchInterceptor during createSetupServer, nor is it exported, so there is no easy way to call it from user code
  • We do not need to add any “special” interceptor for Undici, but we do need Undici as a dev dependency in the test/CI environment. Node bundles undici as internal code, but there is no way to import its package directly, so if you want to e.g. setGlobalDispatcher, you must add undici to your project and import it from there.

Quick fix

  • Draft PR in my fork: https://github.com/milesforks/msw/pull/1/files
  • Changing two lines in setupServer will make it “mostly” work.
  • This might not be the right way to make it available, since it could have impact on bundle size
  • This will not be covered by tests, and it will break with IPv6. It might also have some issues with TLS, can’t remember (lots of moving parts here).
  • I wouldn’t advocate merging this PR into this repository, but you might find it helpful as a quick fix in your own codebase. (For example, you could make the change to your local dependency with yarn patch or equivalent.)

Robust fix

  • Use that “quick fix,” then migrate to Node 18, fix newly broken tests, and add tests for native fetch
  • For Node 18 fetch to be testable, we need to migrate the development and CI environment of this repository to Node 18
  • Migrating to Node 18 breaks tests in GitHub CI runners due (primarily) to new IPv6 resolution behavior described earlier
  • These problems unfortunately cascade through a few dependencies, including mswjs/interceptors, page-with and open-draft/test-server (source unavailable). In my PRs, I fixed these problems with hacky prototype patching, and @kettanaito also merged the fix into page-with (but still needs to release its package to npm, so I can remove the prototype patching and bump the page-with dependency version)
  • In addition to migrating this repository, I also have a PR to migrate mswjs/interceptors to Node 18: https://github.com/mswjs/interceptors/pull/283
  • I successfully migrated most of this main repository (msw) to Node v18, and added v18 to the testing matrix (along with v14 and v16), but there are still a few tests failing due to a memory leak. Here’s the draft PR from my fork: https://github.com/milesforks/msw/pull/2

Summary

To fully migrate to Node 18, we need to open/merge the following PRs:

Note: These PRs are not as complicated/dangerous as they look. Most of the complexity only affects development/CI environment, and there are hardly any user-facing changes. And the high count of files changed is due to changing an import path to use the patched @open-draft/test-server.

In the meantime, as a “quick fix,” we could make the two-line change described above (https://github.com/milesforks/msw/pull/1). If @kettanaito is okay with that approach, I can rebase my PR and open it here, or he can just make the change himself, since it’s literally two lines.

Blockers

Next steps

I spent most of last week on this (thanks to ipv6…), so I would love to get this merged! Please let me know how you’d like to coordinate the order of merges here, and if you have any input on that last memory leak blocking my PR from being ready.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Node v18.12.0 (LTS)
This release marks the transition of Node.js 18.x into Long Term Support (LTS) with the codename 'Hydrogen'. The 18.x release line now moves ......
Read more >
npm WARN: npm does not support Node.js v12.4.0
What worked for me: if you try running this command "npm cache clean -f" and it doesn't work,. on your windows machine(mine is...
Read more >
Welcome Node.js 18 - Red Hat
Welcome Node.js 18 · Experimental Fetch · Test Runner · ECMAScript modules improvements · Improved support for AbortController and AbortSignal ...
Read more >
AWS Lambda adds support for Node.js 18
AWS Lambda now supports Node.js 18 as both a managed runtime and a container base image. Developers creating serverless applications in ...
Read more >
Node.js - endoflife.date
Release Released Active Support 19 2 months and 6 days ago. (18 Oct 2022) Ends in 3 months and 1 week. (01 Apr 2... 18...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found