React Native: Property 'Document' doesn't exist

[rodperottoni]

I'm currently using [email protected] on Expo SDK 51. When calling .listen() on my server instance, all requests start failing with the following error:

[ReferenceError: Property 'Document' doesn't exist]

• My setupServer is indeed imported from msw/native.
• My polyfills are correctly set up

After digging around, I found out the latest XMLHttpRequestInterceptor makes use of the global Document property, which is not available on React Native or Expo applications.

The usage can be seen here: XMLHttpRequestController.ts

I'm wondering if anyone else has faced this issue and how did they solve it?

[rodperottoni]

Some more information:

• I've placed several console.logs around the compiled MSW code, and found out that the imported XMLHttpRequestInterceptor somehow is resolved to the browser variant under @mswjs/interceptors.

---

• I can confirm this by placing logs in the following file: node_modules/@mswjs/interceptors/lib/browser/interceptors/XMLHttpRequest/index.js

---

Output:

• This is how I'm setting up my server:

---

Relevant packages:

• [email protected]
• [email protected]
• [email protected]
• [email protected]

[rodperottoni]

I think I just found my answer.

In Expo's metro config, the config.resolver.resolverMainFields has a default value of: https://github.com/expo/expo/blob/58c7c9156e86dab9e3f2f15135e52f03880b6cf3/packages/%40expo/metro-config/src/ExpoMetroConfig.ts#L262

For reference, this is Metro's docs on resolverMainFields: https://metrobundler.dev/docs/configuration/#resolvermainfields

This makes me wonder: how did anyone else ever got MSW to work with React Native + Expo if the module resolution is using the browser exports rather than node ?

[watadarkstar]

@rodperottoni Did you ever figure out how to get MSW to work with an Expo app? If so, care to share some code?

[rodperottoni]

@watadarkstar unfortunately not. I ended up putting this endeavour on the back burner.

[watadarkstar]

@rodperottoni Thanks for the quick response! I think I will also back burner it

[kettanaito]

I will never understand why project just opt-in into using seemingly incompatible export conditions by default. Since Metro prioritizes browser, you get the browser build of @mswjs/interceptors, which includes XHR interception as it should.

This makes me wonder: how did anyone else ever got MSW to work with React Native + Expo

We have been looking for a champion to bring the React Native integration into a good shape. None has showed up as of now. Since not many issues have been reported about this, I deem React Native support as a non-priority task. I don't develop in React Native so it's hard for me to have a proper grasp on the workflows and project specifics there.

Solution

The solution is to configure config.resolver.resolverMainFields to prioritize node only when testing. Your Metro app may be okay digesting browser packages, but your test runs in Node.js, and it must never import a browser package there.

[tranhl]

@kettanaito FWIW React Native has experimental support for the react-native export condition. Perhaps that's something that msw could leverage for it's integration? Perhaps the integration could also be marked experimental as well seeing how unstable it currently is? That would open up a path to stability that lines up with package exports support in React native as well.

More details: https://metrobundler.dev/docs/package-exports/#replacing-browser-and-react-native-fields

[j3lev]

I was able to resolve this issue by switching my HTTP client to Fetch vs. Axios. Luckily we were early enough in our project where this wasn't a huge lift. It might make sense to officially document the lack of Axios support. Interestingly enough I was still seeing console errors after switching to Fetch but the responses were resolving correctly. I didn't have time to debug further and just ended up suppressing the error.