Haste module overrides for react-native-windows resolution failures

[rozele]

• Review the documentation: https://facebook.github.io/react-native
• Search for existing issues: https://github.com/facebook/react-native/issues
• Use the latest React Native release: https://github.com/facebook/react-native/releases

Environment

Run react-native info in your terminal and paste its contents here.

  React Native Environment Info:
    System:
      OS: macOS High Sierra 10.13.3
      CPU: x64 Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz
      Memory: 90.15 MB / 16.00 GB
      Shell: 3.2.57 - /bin/bash
    Binaries:
      Node: 8.9.4 - /usr/local/bin/node
      Yarn: 1.7.0 - /usr/local/bin/yarn
      npm: 6.1.0 - /usr/local/bin/npm
    SDKs:
      iOS SDK:
        Platforms: iOS 11.4, macOS 10.13, tvOS 11.4, watchOS 4.3
      Android SDK:
        Build Tools: 23.0.1, 25.0.3, 26.0.2, 27.0.3
        API Levels: 23, 25, 27
    IDEs:
      Android Studio: 3.0 AI-171.4443003
      Xcode: 9.4.1/9F2000 - /usr/bin/xcodebuild
    npmPackages:
      react: 16.3.2 => 16.3.2 
      react-native: 0.56.0-rc.1 => 0.56.0-rc.1 
    npmGlobalPackages:
      react-native-cli: 2.0.1

Description

Describe your issue in detail. Include screenshots if needed. If this is a regression, let us know.

react-native-windows overrides haste modules in react-native, currently using the @providesModule attribute. For example, the ScrollView module in react-native has behavior that limits it to iOS and Android, we we override the module in react-native-windows here.

Prior to react-native 0.56.0 RC (which moved to metro 0.38), this behavior worked as expected. Now, the haste module overrides for windows no longer seem to get resolved. Specifically, I get the following error:

Unable to resolve module `AccessibilityInfo` from `/Users/rozele/code/sandbox/v56/node_modules/react-native/Libraries/react-native/react-native-implementation.js`: Module `AccessibilityInfo` does not exist in the Haste module map

This might be related to https://github.com/facebook/react-native/issues/4968
To resolve try the following:
  1. Clear watchman watches: `watchman watch-del-all`.
  2. Delete the `node_modules` folder: `rm -rf node_modules && npm install`.
  3. Reset Metro Bundler cache: `rm -rf /tmp/metro-bundler-cache-*` or `npm start -- --reset-cache`.  4. Remove haste cache: `rm -rf /tmp/haste-map-react-native-packager-*`.

Please note - the AccessibiltyInfo module just happens to be the first module in the dependency graph that we provide a *.windows.js override for, so it has nothing to do with that module specifically.

Reproducible Demo

Let us know how to reproduce the issue. Include a code sample, share a project, or share an app that reproduces the issue using https://snack.expo.io/. Please follow the guidelines for providing a MCVE: https://stackoverflow.com/help/mcve

A very simple test that repos (on both Windows and Mac):

1. Generate a new react-native project with 0.56.0-rc.4:

react-native init test --version 0.56.0-rc.4

2. Generate a react-native-windows project:

yarn add rnpm-plugin-windows
react-native windows --windowsVersion 0.55.0-rc.0

3. Try to generate a windows platform bundle

react-native bundle --platform windows --entry-file index.js --bundle-output test.bundle

[rubennorte]

Thanks for reporting this. This is indeed a breaking change for plugins. In order to prevent having to override the hasteImplModulePath configuration in end-user code, we're going to add an exception for react-native-windows in react-native. I'm working in a fix right now.

Meanwhile, we're going to work in a long-term solution for overriding core components from plugins, as the current approach is pretty hacky.

[rozele]

@rubennorte - definitely agree that a less hacky long term solution is ideal. I've never liked the "special case" of react-native-windows in the metro / react-native repos.

That being said, my parameters for an ideal solution would be one that allows me to install react-native-windows and have it "just work" without changes to the rn-cli.config.js. We have a precedent for plugging into the react-native link command via a bit of config in the package.json file here. If we could have something declarative like that for metro / haste modules, that would be ideal.

[kelset]

Hey @rozele is this still an issue or 0.56.0 fixed it?

---

According to issue #20015 this is still an issue.

[PerspectivesLab]

this => Unable to resolve module AccessibilityInfo is still an issue for 0.56.0, compiling for android on windows platform .... what is going wrong ? this is a major issue....
i cant believe this is happening for 0.56 after 6 release candidates....

[guilhermegonzaga]

I got the same issue on Windows 10 :(

[guidotajan]

Same issue here! Trying to compile RN 0.56.0 for Android.
Here it's the react-native info output:

React Native Environment Info:
    System:
      OS: Windows 10
      CPU: x64 Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz
      Memory: 1.49 GB / 3.88 GB
    Binaries:
      Yarn: 1.5.1 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
      npm: 5.6.0 - C:\Program Files\nodejs\npm.CMD
    IDEs:
      Android Studio: Version  3.1.0.0 AI-173.4819257

[rubennorte]

I followed the same steps in this issue and then yarn upgrade react-native@0.56.0. The error I'm getting after react-native bundle --platform windows --entry-file index.js --bundle-output test.bundle is:

Unable to resolve module `ViewContext` from `.../ReactNativeWindowsTestNew/node_modules/react-native-windows/Libraries/Image/Image.windows.js`: Module `ViewContext` does not exist in the Haste module map

Which is normal because ViewContext doesn't exist anymore in React Native.

This isn't related to this issue, as the hasteImpl/providesModule thing has been solved for react-native-windows.

[kelset]

@rubennorte according to the other issue I linked (#20015) the error Unable to resolve module AccessibilityInfo is present in projects that are not strictly using react-native-windows (and there is also a related metro issue open atm -> facebook/metro#181 )

[daravi]

I would like to suggest that the issue detail be updated to reflect the fact that the same issue is happening on Windows 10 when compiling for Android. I spent two days troubleshooting as this happened during my very first react native project setup :(

  React Native Environment Info:
    System:
      OS: Windows 10
      CPU: x64 Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz
      Memory: 22.43 GB / 31.95 GB
    Binaries:
      Yarn: 1.7.0 - C:\Program Files\nodejs\yarn.CMD
      npm: 5.6.0 - C:\Program Files\nodejs\npm.CMD
    IDEs:
      Android Studio: Version  3.1.0.0 AI-173.4819257

[eazzyLEE]

@rubennorte Please, this is still an issue and it's becoming really frustrating. I had to downgrade to 0.55.4, it worked but there are vulnerabilities that npm suggests npm install react-native @0.56.0 will fix. Going back to that version will return the same "AccessibilityInfo" bug.

What can be done?

[donjo9]

downgrading isnt really resolving a issue, the originale issue stated that everything worked prior to 0.56

[esipavicius]

Everything working with 0.55 upgraded to 0.56 and babel it fails :/ I need 0.56 for some bug fixes :/

[zain-merchant]

0.56 is broken on windows. Hopefully, this gets fixed soon!

[TomBerriot]

Same error here, it's okay to have bugs sometimes, but what can we do about it ?
Isn't there some lines we can just add to the config files so that it can work for now ?

[kelset]

I'm locking this since the comments are all but useful in helping with solving this issue.

Aside from that, a commit landed in master with a fix: 3ac86c3 and we'll make sure to cherry pick it and release a 0.56.1 release asap.

EDIT: since there are reports that the commit is not enough to fix the issue completely, this issue prob can't be closed yet.

[kelset]

Update:

the TLDR is that the original issue causing this was nested into a dependency of Babel. After having tested various workarounds in the past weeks, in collaboration with the Metro team we agreed that (sadly) it's really complex to backport the "true fix" to 0.56.

We are cutting a 0.57 rc0 in these hours in order to make a new version available to everyone asap, and test that in fact 0.57 will solve this (related: 583cb13 ).

I'll try to update everyone as soon as we have better info related to this.

We are also trying to avoid situations like this in the future by integrating a some Windows tests in the CI, you can follow along and help and provide feedback about that here: #20260

---

EDIT: we created a more general issue to keep track on the whole Windows situation over here: #20353