React-native: [Debugging] Please make debug port (8081) configurable

[bparadie]

Port 8081 is currently used by react-native as the debugging port in the following files:

Libraries/RCTTest/RCTTestRunner.m
Libraries/WebSocket/RCTWebSocketExecutor.m
React/Base/RCTRedBox.m
React/React.xcodeproj/project.pbxproj

Unfortunately there are other services that might use 8081, i.e. McAfee:

| Port | Default | Description | Traffic direction |
| --- | --- | --- | --- |
| Agent wake-up communication port SuperAgent repository port | 8081 | TCP port that agents use to receive agent wake-up requests from the ePO server or Agent Handler... | Inbound connection from the ePO server/Agent Handler to the McAfee Agent... |

See https://kc.mcafee.com/corporate/index?page=content&id=KB66797

Another reason for having a configurable react-native debug port is that I often work on two react-native projects in parallel, i.e. my own project plus UIExplorer. But both react-native apps collide, because both want to use port 8081.

Please make react-native's debug port configurable in order to avoid conflicts with other services.

[brentvatne]

@bparadie - do you have time to submit a PR for this?

[bparadie]

@brentvatne Right now I don't have a lot of time. But I can prepare a PR. First I wanted to know whether there is interest in this change. It looks like there is, correct?

[ide]

I think so. A good approach to make things configurable without stepping on too many toes could be to define a macro like RCT_WEBSOCKET_PORT so that it's as configurable as RCT_DEV, etc.

[jsierles]

Should this also include configuring the IP address (replacing localhost)?

[bparadie]

@jsierles Yeah, I think IP address should be configurable as well.

[brentvatne]

@bparadie - agreed!

[bparadie]

@jsierles @ide @brentvatne Before I go ahead and implement something that nobody wants, I'd like to ask you guys whether you find this direction agreeable:
How about reading the information for port (8081) and origin ('http://localhost') from a dictionary in info.plist?

Roughly, I was thinking of adding a new dictionary to info.plist called RCTWebSocketExecutor with port and origin items. For example this would be UIExplorer's info.plist:

Then in RCTWebSocketExecutor:init I would check whether there is a RCTWebSocketExecutor dictionary and use those values for initWithURL. If there is no RCTWebSocketExecutor dictionary I'd use 8081 and 'http://localhost'.

Also, let me know if you think there are better names for RCTWebSocketExecutor, port, and origin.
Thanks!

Oh, I almost forgot: Then packager probably needs to be adjusted. I could perhaps simply extract port and originfrom the info.plist.

[jsierles]

This seems like a good approach. Easy to point people here, and plist files are easy to edit programatically. What about the IPs/ports for non-websocket?

[bparadie]

@jsierles Apologies if this is a stupid question: What are 'non-websocket' IPs/ports?

[bparadie]

@jsierles @ide @brentvatne Just wanted to dog-pile one other idea to this PR. We could change the name from RCTWebSocketExecutor to, say, AppImage and add a property bundle / name in addition to origin and port. If bundle is specified the default AppDelegate code would use the bundle instead of the web socket etc.

What do you guys think?

[ide]

@bparadie: bundles (I assume you mean JS bundles and not iOS asset bundles) and the web socket executor are independent. You could run a bundle across the web socket executor if you wanted. Best to keep the two concepts separate.

[bparadie]

This is the code snippet I am planning to use in AppDelegate.m and RCTWebSocketExecutor.m:

  NSMutableString* url;
  NSDictionary *dict = [[NSBundle mainBundle] objectForInfoDictionaryKey:@"RCTWebSocketExecutor"];
  if( dict )
  {
    NSString* origin = [dict objectForKey:@"origin"];
    NSString* port = [NSString stringWithFormat:@"%@", [dict objectForKey:@"port"]];
    url = [NSMutableString stringWithString:origin];
    [url appendString:@":"];
    [url appendString:port];
  }
  else
  {
    url = [NSMutableString stringWithString:@"http://localhost:8081"];
  }

I have three questions:

• Should I put this in a utility function and call it from AppDelegate.m and RCTWebSocketExecutor.m? If so what's a good place to add that utility function?
• Should every example use this snippet, or should I just show how it works in one of the examples?
• Would it be ok to assume that there is always a valid Info.plist entry for RCTWebSocketExecutor?
  If so then the code could be compressed to:

 NSDictionary *dict = [[NSBundle mainBundle] objectForInfoDictionaryKey:@"RCTWebSocketExecutor"];
 NSString* origin = [dict objectForKey:@"origin"];
 NSString* port = [NSString stringWithFormat:@"%@", [dict objectForKey:@"port"]];
 NSMutableString* url = [[[NSMutableString stringWithString:origin] appendString:@":"] appendString:port];

[bparadie]

@jsierles @ide @brentvatne I have something that works. This is a screenshot after changing the port number to 8086 in Info.plist and rebuilding UIExplorer:

But it's not pretty:

• I had to add a new target called ReactWithoutPackager to React.xcodeproj that is a copy of the React target without running the launchPackager.command script.
• UIExplorer now links against libReactWithoutPackager.a, which attracts the ReactWithoutPackager target w/o launchPackager.command.
• I had to add support for --origin parameter to packager.sh
• I had to add a run script to UIExplorer that launches launchPackager.command with --origin and --port parameters.
• I can't use open launchPackager.command, because I am now passing --origin and --port as parameters and open w/t --args does not seem to work with Terminal

I've create this fake PR against my private repo:
https://github.com/bparadie/react-native/pull/2/files

As you can see I decided to not switch everything over to Info.plist. People can still use the old way with hard-coded 'http://localhost:8081'.

Are my changes acceptable?
If so I'll submit an official PR against facebook/master

[bparadie]

@brentvatne np, done: https://github.com/facebook/react-native/pull/1546 !

[jsierles]

Looks good @bparadie!

[schickling]

+1

[niftylettuce]

Here's my hack for how to get Android running https://github.com/mjohnston/react-native-webpack-server/issues/65#issuecomment-151222398

[qimingweng]

I've posted this on product pains so it would be great if you could upvote it there and show the react-native team that this is an important feature https://productpains.com/post/react-native/allow-packager-port-to-be-configurable-change-from-8081/

[satya164]

If someone could send a PR it would be great.

[PublicParadise]

I haven't deleted the branch yet:
https://github.com/bparadie/react-native/tree/webSocketConfig

But I am afraid I am not going to re-submit this PR. I've spent too much time keeping that branch up to date with master and formatting it only to learn that nobody had interested in reviewing and approving it.

[berniedurfee-ge]

@satya164 Looks like there's a PR now, what else is needed to move this change forward?

[satya164]

cc @mkonicek

[qimingweng]

@berniedurfee-ge Is there a link to the existing PR? I see the closed PR from @bparadie here https://github.com/facebook/react-native/pull/1546

@satya164 Looking through that PR it is a little scary to contribute. It seems like people ask for PRs but then aren't reviewing them. Is there any interest from the core team in this feature and would a new PR be handled in a more timely matter?

[berniedurfee-ge]

@qimingweng, sorry, yes, I was referring to the closed PR.

[satya164]

@qimingweng The core team is bit busy working on highest requested features (for example 5bf1f4c05ef0f3ee1cbf6e38164d58dbeee6637d), and not to say various bug fixes. The number of bug reports and pull requests are overwhelming.

We, community collaborators try our best to review small and straight forward PRs. But for bigger PRs, someone from the core team needs to review it. And it can take a long time, both due to the number of open PRs and the size of the PRs. Not that the core team is not interested in merging the PRs. Just that we haven't figured out a better way to keep up such a high volume of PRs. We know we need to improve on this, and looking for ways to improve.

[jsierles]

Since this is being tracked on Product Pains, and we want to keep Github issues focused on bugs, I'm closing this out until another PR pops up or we get more votes on Product Pains.

https://productpains.com/post/react-native/allow-packager-port-to-be-configurable-change-from-8081/

[haitang3009]

Hello there,

I have fixed this issue by the step below:
if you installed McAfee antivirus, the default port of McAfee log is 8081. You should manual change the port of your react native server

Step 1: go to \node_modulesreact-native\local-cliserverserver.js and change the port 8081 to 8088

const args = parseCommandLine([{
command: 'port',
default: 8088,
type: 'string',
}

Step 2: Create an "assets" folder under "android/app/src/main"

Step 3: in node.js run "react-native start" and navigate to the url "http://localhost:8088/index.android.bundle?platform=android"

Step 4: save the bundle to assets folder and you are all set. in node.js run "react-native run-android" to view the result

Regards,

Hai Tang

[PublicParadise]

Is this maybe a viable solution to this problem?
https://github.com/jondot/react-native-network-boot

[qimingweng]

Actually, @haitang3009, we should be able to start the server with a --port flag to set the port at this point. I tried and this works.

react-native start --port=8088

[david0673]

@qimingweng @frantic @bparadie
the solution @PublicParadise suggested will work 100% for sure

[qimingweng]

@david0673 that solves the localhost problem, not the port problem?

[abhranilnaha]

Is this problem fixed now? Can someone please point me how I can run react native apps in Android and iOS emulators using port other than 8081.

[Rovack]

@abhranilnaha As explained here, you can now set the port for iOS by editing AppDelegate.m, and for Android using the "Debug server host & port for device" setting in the dev menu.
Alternatively on Android you can use the debug_http_host shared preference, as explained here.

Currently this doesn't make it possible to use the debugger, but it does allow running the apps using a port other than 8081 as you asked (see the last comment here and this issue for more on the debugger problem).

[fritx]

How can I run react-native run-ios and run-android at the same time?
How to configure a different port?

[ktonon]

I couldn't figure out how to get this working following any of the solutions I found online. I found the only reliable way was to replace all occurrences of the hard coded port in the react-native package.

I published an npm package to do this: https://github.com/ktonon/react-native-port-patcher

Just install it as a dependency, then add a script for postinstall setting it to react-native-port-patcher --new-port=8088 (or whatever port you want). You can leave out the --new-port as 8088 is the default.

[ktonon]

Also, just a warning that I'm new new react-native and this appears to work, in that I can compile and launch my app now, from the command line and from xcode.

But I haven't tested on Android yet, or done anything beyond launching.

[jwrigh26]

This still seems to be an issue and searching for a concrete solution has not produced any 100% reliable results for me. I have been able to get Xcode to run doing the following:

Xcode:
RCTWebSocketExecutor.m line 61 change 8081 to 8999
RCTBundleURLProvider.m line 17 change 8081 to 8999
RCTDDevMenu.m line 262 change 8081 to 8999

Go to Libraries -> React.xcodeproj -> Start Packager
Change all text that says “8081” to “8999”

Startup React native using port 8999:
$ react-native start --port=8999
Tap run in Xcode

Still working on a solution for Android.

[kenji-1996]

Can we get a way to pass in the IP of our machine running the debugger?
It drives me nuts that because of my VM macOS setup the local IP is weird and not the norm so I have to manually set it.

Meaning I can just run
react-native run-ios --ip 192.168.0.1 --port 9090

the way ive been forced to setup a virtual machine makes this damn hard to problem solve