Add a way kill the other packager which took port 8081?

[zubko]

Hi RN CLI devs,

When I switch between RN projects, it's tedious that I have to manually kill the other packager or I won't be able to run the new one.

I think the DX will be better if the packager would ask and then try to kill the other process.
Wdyt?

For example, it can run some shell commands to get the PID of that process and then another one to kill it. And it can be limited to macOS and Linux at first, if it's harder to do on Windows.

I could contribute a PR for it.

[szymonrybczak]

hey @zubko, actually in 0.73 we did some improvements to this flow. When run run-ios or run-android it should prompt you to use other port if the one is busy.

https://x.com/SzymonRybczak/status/1709686134542893162?s=20

[zubko]

Hi @szymonrybczak

I see, so you've decided to address it how Expo does.

I saw it once briefly, but my workflow usually starts from react-native start rather than react-native run-ios so I didn't saw it much.

This approach is good when one tries many new apps, like to run an example app from some library repo. But for regularly switching between 2-3 stable apps imo probably it's not so good.

Did I understand correctly that another port (like 8082) will be compiled to the app's binary? So let's say after OS restart if I run the last app first, the packager will listen on port 8081 and I will have to rebuild the binary or it will fail to find the packager on 8082?

On a larger app we have our own build script to apply some asset transformations and do other preparations before calling run-ios, and I noticed that esp for iOS builds the other developers will experience much less native build issues if all the previous build caches will be reset, so the build always takes the full time (the developers are not expected to run it often) and it's not interactive (the developers won't be able to interact with the run-ios). Also I've seen it in another company and it's in our plans to allow our JS developers to not worry about native builds at all. Then some script will download and install already pre-built app and react-native start will be the frist command from RN CLI and the binaries will expect the packager to be on 8081.

In my personal workflow, for example, I just start the Simulator/Emulator and I run the app which is already there from the last time. I avoid native rebuilds unless they are really needed.

I understand of course that for the apps which I develop I can just put that 8081 port check / kill before calling react-native start and it will work how I want. But I was thinking it could be a useful feature of react-native start itself, like a CLI argument or an interactive question before erroring out.

As for increasing the port number aren't you concerned that running on port 8082, 8083 etc can create a bit of chaos to track which port which binary is using, and esp junior or non core RN developers would run into the situations that the packager was not found and they will spend time debugging it and / or will ask for support?

[zubko]

Hi @szymonrybczak ,

I have another suggestion for you.

What if this question will have a 3rd option to choose from?

Smth like: