question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Metro bundler not starting when running run-android / run-ios command on linux

See original GitHub issue

Description

When running the react-native run-android command it tells me that the JS server (metro bundler) is starting, but in fact it does not and the application in the emulator fails to start as of this issue. Runningreact-native start separately resolves the issue. I think this issue might apply for run-ios as well although this needs to be confirmed.

React Native version:

react-native: 0.62.2 @react-native-community/cli: 4.8.0 node: 12 // this version does not matter system: ubuntu 18.04 // this does not matter as well

Steps To Reproduce

Any project with those versions on linux should fail starting the JS server when running react-native run-android.

Expected Results

  1. When running react-native run-android the bundler should be started if it’s not started already in a separate terminal window.
  2. When running react-native run-android and there is an issue with the JS bundler the primary process should display errors why the JS bundler failed starting.

Related issues

https://github.com/facebook/react-native/issues/25509 https://github.com/facebook/react-native/issues/28281

Snack, code example, screenshot, or link to a repository:

I have debugged the issue extensively since none of the related issue provided any solution for my case. I have found several problems with the linux implementation and I will lay them out here. I have also worked out a hacky temporary solution for the fix.

Temporary solution

To hot fix this problem we can leverage the --terminal parameter on run-android command. This is very hacky but it works

  1. Add the following in your package.json:
  "scripts": {
    "android-linux": "react-native run-android --terminal \"$PWD/shgnome\""
  }
  1. Create a new file called shgnome the modified terminal runner in your project root with this content:
#!/bin/bash
# @TODO: Remove once issue is fixed in react-native.
set -e
# Remove all params and leave only the path to the script.
script=$(echo "$@" | awk '{print $2}')
gnome-terminal -- "$script"
  1. Run chmod u+x ./shgnome.
  2. Run npm run android-linux.

Actual issues

  1. The first issue is in the function runAndroid in file @react-native-community/cli-platform-android/build/runAndroid/index.js. The call startServerInNewWindow return value is completely ignored and thus any potential errors are swallowed. This is why I was not getting any errors in the primary process and this is why this issue survives so long. I suggest that if stderr is set than it should be printed or thrown, but this depends also on the other fixes required.
     try {
        startServerInNewWindow(args.port, args.terminal, config.reactNativePath);
      } catch (error) {
        _cliTools().logger.warn(`Failed to automatically start the packager server. Please run "react-native start" manually. Error details: ${error.message}`);
      }
  1. The process invoked for the metro bundler is react-native/scripts/launchPackager.command. This file does not have the -e cmd flag and thus it does not exit with proper error code if things fail in it’s process. This was also influencing the 1. issue since if the flag is set then we get proper error message in the primary process (run-android) that the JS bundler failed to start and why it failed.
#!/bin/bash
# Set terminal title
echo -en "\\033]0;Metro\\a"
clear

THIS_DIR=$(cd -P "$(dirname "$(readlink "${BASH_SOURCE[0]}" || echo "${BASH_SOURCE[0]}")")" && pwd)

# shellcheck source=/dev/null
. "$THIS_DIR/packager.sh"

if [[ -z "$CI" ]]; then
  echo "Process terminated. Press <enter> to close the window"
  read -r
fi
  1. The startServerInNewWindow function in @react-native-community spawns the launchPackager.command process in an sh shell, while in fact the launchPackager.command explicitly says that it require bash. Because that shellscript was written for bash when it runs with sh it fails due to syntax differences. This failure is not printed to the console of the primary process and is not detected because of issue 2. For this I would suggest letting the shellscript decide in what to run itself and just be called directly as the hot-fix shows. But I am not sure why sh was enforced there and so input is required for this. Note that the code below is modified in the catch case when the terminal is not set with my proposed solution. The try block is the old one as you can see has the sh. I would also suggest not doing the fallback as such and rather if --terminal is set and it does not work just throw an error to the user. The current fallback implementation is unnecessary slower in cases where the the --terminal is not set and it’s bad developer experience if the --terminal is set but in fact it doesn’t work.
if (process.platform === 'linux') {
    try {
      return _execa().default.sync(terminal, ['-e', `sh ${launchPackagerScript}`], { ...procConfig,
        detached: true
      });
    } catch (error) {
      // By default, the child shell process will be attached to the parent
      return _execa().default(`gnome-terminal -- ${launchPackagerScript}`, {
        ...procConfig,
        shell: true,
        detached: true,
        stdio: 'pipe'
      });
    }
  }
  1. There are two flows on linux: 1 if the --terminal is given then the process is opened separately but if it is not it won’t be separate and will be blocking. I am not sure what the implementation was intended there, but even if I applied the fix to change sh to bash it was blocking the primary process and it also wasn’t displaying the JS bundler process`s stdout since it is not implemented as such. My solution for this was to use gnome-terminal as can be seen above: this allows to open a separate window and set the blunder to be a separate process.

I would also suggest having tests for the metro bundler auto start.

Issue Analytics

  • State:open
  • Created 3 years ago
  • Reactions:16
  • Comments:17

github_iconTop GitHub Comments

8reactions
pkecommented, Sep 9, 2020

This is still an issue. Please some contributor prevent this ticket from going stale.

6reactions
mostafabrazicommented, Nov 16, 2020

Confirmed the workaround of @archfz, it worked just fine. Or simply using this command in package.json :

"scripts": {
        "run-android": "gnome-terminal -e \"react-native start\" && react-native run-android",
  },

Screenshot from 2020-11-16 13-38-42

Read more comments on GitHub >

github_iconTop Results From Across the Web

ReactNative Metro Bundler not starting automatically
Run react-native run-android --port 8084 in second Command Prompt window. After error screen appear clicking Android Ctrl + M , iOS Command +...
Read more >
react native metro bundler not starting : Solved Solution
Recently a lot of programmers are having issue on using a react native init application to start an app all because of a...
Read more >
Running On Device - React Native
This document will guide you through the necessary steps to run your React Native app on a device and to get it ready...
Read more >
Reactnative Metro Bundler Not Starting Automatically - ADocLib
Run react-native run-android --port 8084 in second Command Prompt window. After error screen appear clicking Android Ctrl + M , iOS Command +...
Read more >
React Native | WebStorm Documentation - JetBrains
WebStorm helps you create, edit, lint, run, debug, and maintain your ... the react-native run-ios or react-native run-android command is ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found