Can't refactor common app code into module - .rn-cli.config.js workaround not working

Environment

23:39 $ expo diagnostics

  Expo CLI 2.11.6 environment info:
    System:
      OS: Linux 4.15 Ubuntu 18.04.2 LTS (Bionic Beaver)
      Shell: 4.4.19 - /bin/bash
    Binaries:
      Node: 10.15.2 - /usr/bin/node
      Yarn: 1.13.0 - /usr/bin/yarn
      npm: 6.9.0 - ~/.npm-packages/bin/npm
    npmPackages:
      expo: ^32.0.0 => 32.0.1 
      react: 16.5.0 => 16.5.0 
      react-native: https://github.com/expo/react-native/archive/sdk-32.0.0.tar.gz => 0.57.1 
      react-navigation: ^3.0.9 => 3.0.9 
    npmGlobalPackages:
      expo-cli: 2.11.6

Steps to Reproduce

I have a couple of Expo apps (let’s call one my-expo) with common Api code, which I’d like to move into a separate module (my-common-expo). I’m still in development, so the module is not in git, I install it from a main app directory with npm install ../my-common-expo. Here’s a relevant extract from package.json:

{
  "dependencies": {
    "expo": "^32.0.0",
    "my-common-expo": "file:../my-common-expo",
    "react-native": "https://github.com/expo/react-native/archive/sdk-32.0.0.tar.gz",
  }
}

Code in my-common-expo uses Expo and React Native features, so package.json for my-common-expo includes:

{
 "dependencies": {
    "expo": "^32.0.6",
    "react-native": "https://github.com/expo/react-native/archive/sdk-32.0.0.tar.gz",
  }
}

Expected Behavior

I expect the bundler to complete as usual.

Actual Behavior

(node:11990) UnhandledPromiseRejectionWarning: Error: jest-haste-map: @providesModule naming collision:
  Duplicate module name: react-native
  Paths: **/home/antony/src/git/my-common-expo/node_modules/react-native/package.json** collides with **/home/antony/src/git/my-expo/node_modules/react-native/package.json**

This error is caused by a @providesModule declaration with the same name across two different files.
    at setModule (/home/antony/src/git/my-expo/node_modules/jest-haste-map/build/index.js:462:17)
    at workerReply (/home/antony/src/git/my-expo/node_modules/jest-haste-map/build/index.js:512:9)
    at process._tickCallback (internal/process/next_tick.js:68:7)
(node:11990) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 2)
(node:11990) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

I did some research and found https://github.com/facebook/metro/issues/265, which is related. I added a .rn-cli.config.js file to the main app root directory with the following content:

const blacklist = require('metro-config/src/defaults/blacklist');

module.exports = {
  resolver: {
    blacklistRE: blacklist([/my-common-expo\/node_modules\/react-native\/.*/]),
  },
};

I hoped that this would get the bundler to ignore the react-native in my-common-expo, and use the one from my-expo. When I restarted the bundler, it got further, but there was a different error:

Unable to resolve "react-native" from "../my-common-expo/node_modules/expo/build/Expo.js"

Well of course it’s not able to resolve, I had to blacklist it to avoid the duplicate error from Metro.

Trying to blacklist the other react-native install with blacklistRE: blacklist([/react-native\/.*/]), predictably failed with Unable to resolve "react-native" from "node_modules/expo/build/Expo.js".

Trying the .rn-cli.config.js file in the my-common-expo directory didn’t seem to have an effect, I guess because that’s not where the bundler is running from.

I don’t see how to get out of this, and this is my first attempt at writing a node module which doesn’t help. The common code requires react-native for AsyncStorage and expo for Constants.

Grateful for any assistance.

Reproducible Demo

Unfortunately can’t do this, as it’s a multi-app and module situation. Hope it’s not a big deal.

[AdamJNavarro]

Hey @antgel,

Thanks a ton for the detailed issue and my sincere apologies for the delay in response here. I’m raising this issue internally and will follow back as soon as I have more information.

Cheers, Adam

[antgel]

@MontoyaAndres Amazing, I will do, thanks for the tip.