Allow running two apps on 127.0.0.1 and another address on same port

[Exagone313]

Describe the bug

Currently, when starting two React apps with e.g. HOST=127.0.0.1 PORT=3000 and HOST=127.2.2.2 PORT=3000, the second app will fail with an error Something is already running on port 3000, although starting two apps on same port but different addresses is valid. Note that this works when not using address 127.0.0.1.

Did you try recovering your dependencies?

N/A

Environment

N/A

Steps to reproduce

1. Create a React app
2. Run HOST=127.0.0.1 PORT=3000 npm run start in a first terminal
3. Run HOST=127.2.2.2 PORT=3000 npm run start in a second terminal

Expected behavior

Both apps are running on their respective address.

Actual behavior

Only the first app (on 127.0.0.1:3000) is running, the second app didn't start with an error: Something is already running on port 3000.

When patching the code manually to bypass this check, both apps can run aside without issues.

Reproducible demo

Any React app is applicable.

Trivia

The issue is coming from the package detect-port-alt from @Timer, a fork of detect-port which adds host support, but doesn't cover this edge case. Unfortunately, this fork doesn't allow creating GitHub issues and changes have not been upstreamed.

[krreet]

Hi , I tried to reproduce this issue

Steps to reproduce

1. Create a React app
2. Run HOST=127.0.0.1 PORT=3000 npm run start in a first terminal
3. Run HOST=127.2.2.2 PORT=3000 npm run start in a second terminal

you get an error ,
However if we swap step 2 and step 3 , then there is no error

Steps to reproduce

1. Create a React app
2. Run HOST=127.2.2.2 PORT=3000 npm run start in a first terminal
3. Run HOST=127.0.0.1 PORT=3000 npm run start in a second terminal

I have looked into the detect-port-alt code. and found that regardless of the host it always check that port against localhost.

here https://github.com/Timer/detect-port/blob/master/lib/detect-port.js
line no 68

based on above reasoning lets try to explain the behavior
2. Run HOST=127.0.0.1 PORT=3000 npm run start in a first terminal ===> this causes localhost 3000 to be blocked. because 127.0.0.1 is localhost
3. Run HOST=127.2.2.2 PORT=3000 npm run start in a second terminal ===> this causes localhost 3000 not to be blocked because 127.2.2.2 is not localhost

hope this helps

[rv2673]

The upstream has gotten support for hostname, it only has a slightly different interface. Replacing the fork(detect-port-alt) with the upstream(detect-port) one might solves this. It checks if the port is free for the given hostname and port combination if caller provides hostname instead of checking all localhost, default host, ip combinations. Which I believe is what the call for detect is trying to do in react-dev-utils/WebpackDevServerUtils.js.

So aside from replacing the dependency, the invocation of detect needs to change from:

function choosePort(host, defaultPort) {
  return detect(defaultPort, host).then(

function choosePort(host, defaultPort) {
  return detect({port: defaultPort, hostname: host}).then(

[krreet]

Hi , @Exagone313

Meanwhile until this gets fixed you can use this workaround. let me know if there is any issue?
i.e run the 127.0.0.1 host app in the last step.
Create a React app
Run HOST=127.2.2.2 PORT=3000 npm run start in a first terminal
Run HOST=127.0.0.1 PORT=3000 npm run start in a second terminal

for a proper fix we may have to port the changes from detect-port ( which doesn't have the problem as @rv2673 pointed out) to detect-port-alt fork which seems like to be forked especially for react/CRA use case so there maybe more reasons to use it?
as the committers in that fork seem to be related to react/CRA , etc.
Timer/detect-port@040f179

HTH,
Reetesh

[Exagone313]

@krreet, unfortunately my usage requires first starting the app on 127.0.0.1, this cannot be changed. I'll be waiting for the bug to be fixed.

@rv2673 you might want to do that PR yourself, but I can do it in your place if you want (with co-authored-with). (I prefer not to sign the CLA)

Or #11424 needs to be taken over.

[rv2673]

@krreet That might require some git history checking over why and when the fork was added(though might be tricky from the quick git blame click through I did on my phone, since there are several refactors and code moves in there). The host functionality was added after 1,5 year after it was added to the fork, around the same time the fork stopped getting updates. (So backporting it might be rather difficult).

@Exagone313 or somebody else, feel free to create PR. I messed up my personal desktop last weekend and haven't got it working again yet, and I can't do it from my work computer.

[krreet]

@krreet That might require some git history checking over why and when the fork was added(though might be tricky from the quick git blame click through I did on my phone, since there are several refactors and code moves in there). The host functionality was added after 1,5 year after it was added to the fork, around the same time the fork stopped getting updates. (So backporting it might be rather difficult).

@Exagone313 or somebody else, feel free to create PR. I messed up my personal desktop last weekend and haven't got it working again yet, and I can't do it from my work computer.

Looks like CRA was using the original detect-port earlier and was replaced by a "temporary" fork because of the related issue : #2112

@Exagone313 , maybe you can try editing your hosts file meanwhile if it helps as it seems that replacing the forked detect-port might cause regression issues so this one may not be quick to fix.