Skip to content
This repository has been archived by the owner on Jan 18, 2024. It is now read-only.

project root not set correctly #254

Closed
vjpr opened this issue Dec 12, 2018 · 2 comments
Closed

project root not set correctly #254

vjpr opened this issue Dec 12, 2018 · 2 comments

Comments

@vjpr
Copy link

vjpr commented Dec 12, 2018

Description

packages/xdl/Project.js

    let packagerProcess = _child_process.default.fork(cliPath, cliOpts, {
      cwd: projectRoot,
      env: _extends({}, process.env, {
        REACT_NATIVE_APP_ROOT: projectRoot,
        NODE_PATH: nodePath,
        ELECTRON_RUN_AS_NODE: 1
      }),
      silent: true
    });

The project root is currently being passed with REACT_NATIVE_APP_ROOT. This does not seem to work.

When I check the args arriving in react-native (node_modules/.github.com/expo/react-native/archive/sdk-31.0.0.tar.gz/react@16.5.0/node_modules/react-native/local-cli/server/runServer.js), the projectRoot is being set to a default value (See node_modules/.github.com/expo/react-native/archive/sdk-31.0.0.tar.gz/react@16.5.0/node_modules/react-native/local-cli/server/server.js).

Using app.json#packagerOpts = {projectRoot: 'something'} sets it using cli args which works.

It could be some other config option overriding it.

The bug may not have been picked up because react-native's default project root worked for most projects.

In my case, it is setting it to /xxx/node_modules/.github.com/expo/react-native/archive/sdk-31.0.0.tar.gz/react@16.5.0 by default, which then prevents the entry point being resolved correctly. I am using pnpm and a monorepo setup, so this is why it was probably not noticed. Below is the logic which set it:

/xxx/node_modules/.github.com/expo/react-native/archive/sdk-31.0.0.tar.gz/react@16.5.0/node_modules/react-native/local-cli/util/Config.js

function getProjectRoot() {
  if (
    __dirname.match(/node_modules[\/\\]react-native[\/\\]local-cli[\/\\]util$/)
  ) {
    // Packager is running from node_modules.
    // This is the default case for all projects created using 'react-native init'.
    return path.resolve(__dirname, '../../../..');
  } else if (__dirname.match(/Pods[\/\\]React[\/\\]packager$/)) {
    // React Native was installed using CocoaPods.
    return path.resolve(__dirname, '../../../..');
  }
  return path.resolve(__dirname, '../..');
}

I have opened a bug in react-native but I doubt it will get fixed facebook/react-native#22623.

I only found one usage of REACT_NATIVE_APP_ROOT in react-native:

const getWatchFolders = () => {
  const root = process.env.REACT_NATIVE_APP_ROOT;
  if (root) {
    return resolveSymlinksForRoots([path.resolve(root)]);
  }
  return [];
};

Expected Behavior

Observed Behavior

Environment

  Expo CLI 2.6.12 environment info:
    System:
      OS: macOS 10.14.1
      Shell: 5.3 - /bin/zsh
    Binaries:
      Node: 8.9.0 - ~/nvm/versions/node/v8.9.0/bin/node
      Yarn: 1.12.3 - /usr/local/bin/yarn
      npm: 5.6.0 - ~/nvm/versions/node/v8.9.0/bin/npm
      Watchman: 4.9.0 - /usr/local/bin/watchman
    IDEs:
      Android Studio: 3.0 AI-171.4443003
      Xcode: 10.1/10B61 - /usr/bin/xcodebuild
    npmPackages:
      expo: ^31.0.2 => 31.0.6
      react: 16.5.0 => 16.5.0
      react-native: https://github.com/expo/react-native/archive/sdk-31.0.0.tar.gz => 0.57.1

Also specify:

  • Phone/emulator/simulator platform, model and version:

Reproducible Demo

Please provide a minimized reproducible demonstration of the problem you're reporting.

Issues that come with minimal repro's are resolved much more quickly than issues where a maintainer has to reproduce themselves.

@vjpr
Copy link
Author

vjpr commented Dec 12, 2018

Summary

So it looks like its a bug in the assumption that react-native makes about node_modules structure.

Expo should pass in --projectRoot perhaps...

Workaround

I think react-native was unable to find rn-cli.config.js because of its faulty project root searching logic.

If I add app.json#packagerOpts = {config: 'rn-cli.config.js'}, it uses the projectRoot from the config file.

@EvanBacon
Copy link
Contributor

This is something we didn't have any control over before, should be fixed when using the new metro config #1845

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

No branches or pull requests

2 participants