Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Haste module overrides across packages #188

Closed
rozele opened this issue Jun 28, 2018 · 7 comments
Closed

Haste module overrides across packages #188

rozele opened this issue Jun 28, 2018 · 7 comments

Comments

@rozele
Copy link
Contributor

rozele commented Jun 28, 2018

Do you want to request a feature or report a bug?

Bug

What is the current behavior?

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.

If the current behavior is a bug, please provide the steps to reproduce and a minimal repository on GitHub that we can yarn install and yarn test.

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
  1. Generate a react-native-windows project:
yarn add rnpm-plugin-windows
react-native windows --windowsVersion 0.55.0-rc.0
  1. Try to generate a windows platform bundle
react-native bundle --platform windows --entry-file index.js --bundle-output test.bundle

What is the expected behavior?

The expected behavior is that a valid bundle will be generated for the windows platform moniker, with the correct module overrides being used from the react-native-windows package.

Please provide your exact Metro configuration and mention your Metro, node, yarn/npm version and operating system.

metro: 0.38.1
node: 8.9.4
yarn: 1.7.0
OS: macOS 10.13.3
@rozele
Copy link
Contributor Author

rozele commented Jun 28, 2018

Related to facebook/react-native#19953

@mjesun
Copy link
Contributor

mjesun commented Jun 28, 2018

cc @rubennorte; how does the Haste implementation shipped by default works with providesModuleNodeModules? (omg what a config name...)

@rubennorte
Copy link
Contributor

All modules in providesModuleNodeModules are analyzed by jest-haste-map, but only created as haste modules if their filename matches the hasteImpl used in the configuration. If you have multiple packages with haste names, then you have to unify all the whitelisting in a root config (where you can require specific hasteImpl files from different packages).

@rubennorte
Copy link
Contributor

I just saw react-native-windows didn't define a specific configuration for hasteImpl or for providesModuleNodeModules as some specific configuration for react-native-windows is already hardcoded in Metro. I'll create a patch to solve this issue now and meanwhile we're going to explore a better solution for this.

hramos pushed a commit to hramos/react-native that referenced this issue Jul 2, 2018
Summary:
We removed support for providesModule annotations and maintained support for Haste names in installed modules via `providesModuleNodeModules`, but our default `hasteImpl` doesn't take them into account. We need to find a better way to override core components from plugins but meanwhile this adds an exception for react-native-windows in the default `hasteImpl` to unblock their upgrade to the latest RC.

Fixes facebook/metro#188

Reviewed By: mjesun

Differential Revision: D8695207

fbshipit-source-id: a3a8303715820a156b2338438b7f9186e1f71396
hramos pushed a commit to hramos/react-native that referenced this issue Jul 2, 2018
Summary:
We removed support for providesModule annotations and maintained support for Haste names in installed modules via `providesModuleNodeModules`, but our default `hasteImpl` doesn't take them into account. We need to find a better way to override core components from plugins but meanwhile this adds an exception for react-native-windows in the default `hasteImpl` to unblock their upgrade to the latest RC.

Fixes facebook/metro#188

Reviewed By: mjesun

Differential Revision: D8695207

fbshipit-source-id: 24119fe25257ec92504d0695b1b9056dfbee2774
hramos pushed a commit to hramos/react-native that referenced this issue Jul 2, 2018
…acebook#20007)

Summary:
Closes facebook#20007

We removed support for providesModule annotations and maintained support for Haste names in installed modules via `providesModuleNodeModules`, but our default `hasteImpl` doesn't take them into account. We need to find a better way to override core components from plugins but meanwhile this adds an exception for react-native-windows in the default `hasteImpl` to unblock their upgrade to the latest RC.

Fixes facebook/metro#188

Reviewed By: mjesun

Differential Revision: D8695207

fbshipit-source-id: e70c8649543ebfcba40f934451faf33548c3d20a
hramos pushed a commit to facebook/react-native that referenced this issue Jul 4, 2018
…20007)

Summary:
Closes #20007

We removed support for providesModule annotations and maintained support for Haste names in installed modules via `providesModuleNodeModules`, but our default `hasteImpl` doesn't take them into account. We need to find a better way to override core components from plugins but meanwhile this adds an exception for react-native-windows in the default `hasteImpl` to unblock their upgrade to the latest RC.

Fixes facebook/metro#188

Reviewed By: mjesun

Differential Revision: D8695207

fbshipit-source-id: 2ad6cb1e93e600880a148776ac45f6ebd7d205d3
@Slexom
Copy link

Slexom commented Jul 14, 2018

Same problem, I'm not alone.
My system

React Native Environment Info:
    System:
      OS: Windows 10
      CPU: x64 AMD A10-9620P RADEON R5, 10 COMPUTE CORES 4C+6G
      Memory: 2.23 GB / 7.39 GB
    Binaries:
      Yarn: 1.7.0 - 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
"react": "16.4.1",
"react-native": "0.56.0",
error: bundling failed: Error: Unable to resolve module `AccessibilityInfo` from `C:\Users\****\WebstormProjects\****\node_modules\react-native\Libraries\react-native\react-native-implementation.js`: Module `AccessibilityInfo` does not exist in the Haste module map

@esipavicius
Copy link

@Slexom Also same here.

`
"dependencies": {
"@mapbox/polyline": "^0.2.0",
"ansi-styles": "^3.2.0",
"babel-core": "^7.0.0-beta.3",
"core-js": "^3.0.0-beta.3",
"firebase": "^5.2.",
"firebase-admin": "^5.12.0",
"firebase-functions": "^1.1.0",
"prop-types": "^15.6.2",
"react": "16.4.1",
"react-native": "^0.56.0",
"react-native-android-location-services-dialog-box": "^2.6.0",
"react-native-animated-sprite": "^0.11.1",
"react-native-camera": "^1.1.4",
"react-native-config": "^0.11.5",
"react-native-datepicker": "^1.7.2",
"react-native-device-info": "^0.21.5",
"react-native-dropdownalert": "^3.5.0",
"react-native-elements": "^0.18.5",
"react-native-fcm": "^15.0.2",
"react-native-fetch-blob": "^0.10.8",
"react-native-fs": "^2.10.14",
"react-native-icons": "^0.7.1",
"react-native-image-resizer": "^1.0.0",
"react-native-loading-spinner-overlay": "^0.5.2",
"react-native-maps": "^0.21.0",
"react-native-modal-dropdown": "^0.6.2",
"react-native-orientation": "^3.1.3",
"react-native-pdf": "^3.0.16",
"react-native-popup-dialog": "^0.10.46",
"react-native-star-rating": "^1.0.9",
"react-native-swiper": "^1.5.13",
"react-native-vector-icons": "^4.6.0",
"react-native-windows": "0.55.0-rc.0",
"react-navigation": "^2.6.
",
"rnpm-plugin-windows": "^0.2.8",
"uglify-es": "^3.3.10"
},

"devDependencies": {
"babel-jest": "21.2.0",
"babel-preset-react-native": "^5.0.2",
"jest": "21.2.1",
"react-devtools": "^3.2.3",
"react-test-renderer": "16.0.0-beta.5"
},

.babelrc

{
"presets": ["babel-preset-react-native"]
}
`

grabbou pushed a commit to react-native-community/cli that referenced this issue Sep 26, 2018
…20007)

Summary:
Closes facebook/react-native#20007

We removed support for providesModule annotations and maintained support for Haste names in installed modules via `providesModuleNodeModules`, but our default `hasteImpl` doesn't take them into account. We need to find a better way to override core components from plugins but meanwhile this adds an exception for react-native-windows in the default `hasteImpl` to unblock their upgrade to the latest RC.

Fixes facebook/metro#188

Reviewed By: mjesun

Differential Revision: D8695207

fbshipit-source-id: 2ad6cb1e93e600880a148776ac45f6ebd7d205d3
@verinova771
Copy link

__

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants