Modules required from outside of root directory does not find node_modules

[zth]

Hi! I hope I post this in the right place, sorry if I'm not.

I'm trying to setup requiring files outside of the root project directory, as I'm building both a web app and a native app that'll share some code. I've configured this using rn-cli.config.js, and I can successfully import my shared files from outside of my root.

However, the files imported from outside of the root does not find any modules from node_modules (React for example). Files required from inside of the project root does find them (which I guess is because node_modules is in a parent directory to them). I just get a Cannot resolve module 'React'.

The folder structure looks like this:

common
- components
- - ....code
web
- node_modules
- ....code
native
- node_modules
- ...code, rn-cli.config.js, etc...

rn-cli.config.js:

const path = require('path');

module.exports = {
  getProjectRoots() {
    return [
      path.resolve(__dirname, '../common'),
      path.resolve(__dirname, 'node_modules'),
      path.resolve('.')
    ]
  }
};

If I add a package.json to common and install react there it works. So I guess this has to do with the packager walking the file upwards and not finding node_modules as it's in a sibling directory and not a parent directory?

Am I missing something obvious here? I've tried clearing the cache etc. I'm on the latest Expo which I'm pretty sure uses RN 0.43.

Thanks in advance!

[zth]

Tested with fresh react-native init and version 0.45, same issue still. How does the packager resolve modules? Is it somehow relative to the file being required, not primarily from the project roots...?

[fredbt]

Hi @zth I'm facing a similar issue here.

So, if you do the following setup:

1. Make "common" a JS package:

• this would require a package.json for the common folder, and potentially an index.js exporting your common classes.

2. Add a rn-cli.config.js to your app folder.

Does it work? I agree it sucks to have two node_modules folder, but this could be a temporary solution for me until there's a proper solution from metro.

[fredbt]

So I managed to make this work following these steps:

1. Added a package.json to my "common" folder.

2. In the dependencies of my "app1" folder, I added:

"dependencies": { "common": "file:../common/" }

My folder organization is: -- app1: app to do X for users of type 1 -- app2: app to do X for users of type 2 -- common

I'm sure there's something bad about this structure because I ended up with different node_modules folders: --- one under app1: ---> this one includes "common". --- another under common --- another under app2

Not sure about the side effects here (larger binary?) but this works for now.

[jc-murray-1986]

@fredbt there's a major problem with your solution. If you update a file in common, then the changes are not reflected (and loaded) into app1. app1 still has the old version of the file.

Like you say, there is a copy of common in app1/node_modules/common. The copy is not updated when you edit the original lib.

[fredbt]

Thanks @jc-murray-1986 But the packages get updated if I run npm install, correct?

[charlie-axsy]

@fredbt yes they do. But that's not very useful when you're working on one of your common components. Every time you save the file you need to run npm install. It's not a very nice workflow at all

[jl-compileit]

We're having the same issue with a monorepo structure where we currently have web/mobile/shared folders. In our case the root also has a package.json to keep a single version of things like ESLint and Relay and importing those dependencies in the app doesn't work either. The web app is built with webpack and can handle this fine just by configuring module roots and/or module aliases.

Adding every possible module directory to an rn-cli-config.js doesn't seem to make a difference:

const path = require('path');

module.exports = {
  getProjectRoots() {
    return [
      // Keep the project directory.
      path.resolve(__dirname, './'),
      path.resolve(__dirname, './node_modules'),

      // Add the common root.
      path.resolve(__dirname, '../'),
      path.resolve(__dirname, '../node_modules'),

      // Add shared.
      path.resolve(__dirname, '../shared'),
      path.resolve(__dirname, '../shared/node_modules'),
    ];
  },
};

Our initial solution was using shared as a local dependency ("file" in package.json which creates symlinks) and each package being completely separate. This kind of worked but caused some weird install issues where dependencies from shared got added or removed depending on where the install ran and having to manage multiple versions and configs of things like ESLint was really annoying.

[jonbronson]

Has there been any progress on this issue? It seems to be a major show stopper for a unified codebase.

[jeanlauliac]

If I add a package.json to common and install react there it works. So I guess this has to do with the packager walking the file upwards and not finding node_modules as it's in a sibling directory and not a parent directory?

Yes. If you do require('foo'), then it looks node_modules/foo first in the directory of the module you're requiring from, then for each parent directory in turn. So if there's a node_module somewhere in another nested folder it won't find it. The roots are not used for the resolution of node-style packages, purposefully. This resolution pattern follow closely the algorithm specified by Node.js: https://nodejs.org/api/modules.html#modules_all_together.

So one solution is to have all common dependencies be installed in the root directory, that can be resolved from anywhere. Another solution might be to use the extraNodeModules field to specify things you want available manually. Ex. something like:

  extraNodeModules: {
    'foobar': path.resolve(__dirname, '../common/node_modules/foobar'),
  },

[reggie3]

@jeanlauliac can you provide more information about your solution? The extraNodeModules link now resolves to a 404 page.

[jeanlauliac]

I moved on onto other projects so I'm not sure what the status of this field in the configuration at the moment. @CompuIves , does the extraNodeModules configuration still exist and is documented somewhere?

[willgriffiths]

@reggie3 @CompuIves Here is the link to the extraNodeModules documentation: https://facebook.github.io/metro/docs/en/configuration#resolver-options

@jeanlauliac's syntax is the one I've been using.

I'm working in a monorepo with yarn workspaces. I'm using a combination of getProjectRoots to tell metro where to find packages. And then using extraNodeModules to make sure that the local package goes looking for the react, react-native, etc module in the right place.

module.exports = {
  /**
   * Add "global" dependencies for our RN project here so that our local components can resolve their
   * dependencies correctly
   */
  extraNodeModules: {
    react: path.resolve(__dirname, "node_modules/react"),
    "react-native": path.resolve(__dirname, "node_modules/react-native"),
    "@storybook": path.resolve(__dirname, "node_modules/@storybook")
  },
  getProjectRoots() {
    /**
     * Add our workspace roots so that react native can find the source code for the included packages
     * in the monorepo
     */
    const projectPath = path.resolve(__dirname);
    const componentsPath = path.resolve(__dirname, "../../components");
    const rootModulesPath = path.resolve(__dirname, "../../node_modules");

    return [
      projectPath,
      componentsPath,
      rootModulesPath
    ];
 }
}

My use case is probably not the same as yours but I hope it helps.

Also I'm using "react-native": "0.55.4".

[Strate]

@willgriffiths thank you for that solution. Based on yours, I made a more generic one:

const path = require("path");

const installedDependencies = require("./package.json").dependencies;

const extraNodeModules = {};
Object.keys(installedDependencies).forEach(dep => {
  extraNodeModules[dep] = path.resolve(__dirname, "node_modules", dep);
});

module.exports = {
  extraNodeModules: extraNodeModules
};

[pmierzejewski]

@willgriffiths and @Strate solutions work great. If you're using TS don't forget to add your shared code path to

 "rootDirs": [
            ".",
            "../shared"
        ] /* List of root folders whose combined content represents the structure of the project at runtime. */,

in tsconfig.json as well.

[jkillian]

The solution @willgriffiths and @Strate have posted is confusing to me: why do you have to tell metro to look in the current directory's node_modules directory? Isn't that what it does by default?

And do you have to do this for every single dependency? If so, issues can arise in a workspace setup, because there's no guarantee if a dependency will be installed at the top-level node_modules or in a workspace's node_modules directory

[ivan-jorge001]

i am in version RN0.57, latest version i still have this issue, any solutions? none of the solutions aboved worked

[RomualdPercereau]

With the 0.57 of react-native, it looks like the extraNodeModules feature doesn't work anymore?

[rafeca]

In RN 0.57 the format of the Metro config options has changed slightly, now the extraNodeModules param is inside the resolver field (there's more information in the metro docs).

@RomualdPercereau are you configuring the extraNodeModules?

[willgriffiths]

@JKillian

This setup works when used with yarn nohoist. nohoist allows you to force modules to stay in project folders and stop them from being hoisted up to the monorepo root.

RN doesn't work if react-native gets hoisted. Therefore, we needed to nohoist it to get RN working in our monorepo.

Nohoist is how you can guarantee that the modules end up insider your RN project folder.

Also, any library that has native code has to be no hoisted so that you can react-native link it.

Be careful though, no hoisting everything reduces the benefits of yarn workspaces and increases install times so I only use it if I have to.

My team and I are hoping that metro (and as a side note: react-scripts) start working nicer with yarn workspaces.

The solution @willgriffiths and @Strate have posted is confusing to me: why do you have to tell metro to look in the current directory's node_modules directory? Isn't that what it does by default?

In RN if you import a component from "../../components/Button" and that Button component imports View "react-native", metro will go looking for "react-native" in the Button package as per the normal module resolution rules.

It starts in the component's folder "../../components/Button/node_modules/react-native" and if it doesn't find it node_modules it climbs up a level checks in node_modules .

1. "../../components/Button/node_modules/react-native"
2. "../../components/node_modules/react-native"
3. "../node_modules/react-native"
4. etc

By telling metro that react and react-native are located inside the React Native project folder then you override this behaviour so it goes looking in:

1. "RNProject/node_modules/react-native"

And do you have to do this for every single dependency? If so, issues can arise in a workspace setup, because there's no guarantee if a dependency will be installed at the top-level node_modules or in a workspace's node_modules directory

I start no hoisting or adding entries to extra node modules when I get a metro errors like:

• duplicate modules in haste module map
• can't find module in haste module map

[jkillian]

Thanks for the detailed info @willgriffiths 😄

Your example with importing "../../components/Button" is interesting! I believe you're doing cross-workspace relative imports here. I may need to accomplish the exact same thing in my situation, so your solution seems perfect.

Be careful though, no hoisting everything reduces the benefits of yarn workspaces and increases install times so I only use it if I have to.

Yep, agreed with the downsides. We actually ended up adding nohoist: ['**'] to our react-native yarn workspace because it was easier than figuring out which needed to be where. (It's possible that the install times might grow to be obnoxious, we'll see.)

My team and I are hoping that metro (and as a side note: react-scripts) start working nicer with yarn workspaces.

Yes, I hope so too! So far it's been a bit of a hassle to get the react-native toolchain (metro) to work in a nice way with our old web-only yarn workspaces setup. Hopefully FB will have the resources to improve things, maybe the metro team and the yarn team can have a nice fun offsite together and work on these issues 😆 (Thanks to both teams for all the work they've put in to their tools so far!)

[fiznool]

We actually ended up adding nohoist: ['**'] to our react-native yarn workspace because it was easier than figuring out which needed to be where.

I came to the same conclusion too! Yes I end up with a larger workspace but the benefits of not having to hunt these things down far outweigh the cons of a larger workspace size.

As mentioned above, for RN 0.57 you have to put your extraNodeModules inside a resolver object in your rn-cli.config.js, and also getProjectRoots() is no longer a thing. The example provided above would be rewritten as follows for RN 0.57+:

module.exports = {
  /**
   * Add "global" dependencies for our RN project here so that our local components can resolve their
   * dependencies correctly
   */
  resolver: {
    extraNodeModules: {
      react: path.resolve(__dirname, "node_modules/react"),
      "react-native": path.resolve(__dirname, "node_modules/react-native"),
      "@storybook": path.resolve(__dirname, "node_modules/@storybook")
    }
  },
 /**
   * Add our workspace roots so that react native can find the source code for the included packages
   * in the monorepo
   */
  projectRoot: path.resolve(__dirname),
  watchFolders: [
    path.resolve(__dirname, "../../components"),
    path.resolve(__dirname, "../../node_modules")
  ]
}

[brentvatne]

@rafeca - can we get some docs on the above? it's painful to update to the latest version of react-native on a project that uses rn-cli.config.js right now

[mmazzarolo]

I share the same @brentvatne sentiment on this.
I was able to migrate to the new config format thanks to @rafeca's comment above.

I know that the new config.js format is described in the docs but a quick migration guide would be really helpful 🤔

[rafeca]

Hi!

We added a util method in the metro-config package that should help migrating the old configuration format to the new one.

You can call it by doing:

const {convert} = require('metro-config');

module.exports = convert.convertOldToNew({ /* old config object */});

This works as a temporary workaround when upgrading to the latest metro version.

[rafeca]

Regarding the docs, I agree that having some quick migration guide will be helpful. @mmazzarolo , @brentvatne does any of you want to help creating such quick guide? It can be created in the docs folder and will appear in the website.

I can help with clarifications around some parameters if needed 😃

[mmazzarolo]

I didn't know about the convertOldToNew utils, looks good!

About the docs: I meant adding it in the release notes the next time (since it's release-specific).

That said, I'll try to write a few lines in the weekend 👍

[GanchoDanailov]

"dependencies": { "common": "file:../common/" } + npm link works as a workaround

[dagatsoin]

I am totally lost about this issue :/ Could someone explain me how to import some files which are outside the Expo folder? For example

- Stories
-- story0.tsx
- MyExpoRoot
-- metro.config.js
-- App.js

How could I import story0.tsx in App.js ?

[dagatsoin]

For the record, my final config file for making Storybook find the upper folder

var path = require("path");
var config = {
  projectRoot: path.resolve(__dirname),
  watchFolders: [
    // Let's add the root folder to the watcher
    // for live reload purpose
    path.resolve(__dirname, "../src"),
  ],
  resolver: {
    extraNodeModules: {
      // Here I reference my upper folder
      "@sproutch/ui": path.resolve(__dirname, "../src"),
      // Important, those are all the dependencies
      // asked by the "../src" but which
      // are not present in the ROOT/node_modules
      // So install it in your RN project and reference them here
      "expo": path.resolve(__dirname, "node_modules/expo"),
      "lodash.merge": path.resolve(__dirname, "node_modules/lodash.merge"),
      "react": path.resolve(__dirname, "node_modules/react"),
      "reactxp": path.resolve(__dirname, "node_modules/reactxp"),
      "react-native": path.resolve(__dirname, "node_modules/react-native")
    }
  }
}
module.exports = config;

[nihar108]

The solution provided by @fiznool works. But in RN59, rn-cli.config.js is replaced by metro.config.js