feat: add --binary-path to run-ios and run-android to enable installing pre-build binaries

[andrejborstnik]

Summary:

Add support for --binary-path option to run-ios and run-android. This allows a caller to specify their own (pre-built) binary that they want to install on devices, while still keeping all the great os/emulator/device support that react-native-community-cli brings.

Test Plan:

• [x] react-native run-ios works & builds from scratch
• [x] react-native run-ios --device works & builds from scratch
• [x] react-native run-ios --binary-path [PATH] works & installs pre-built .app on simulator
• [x] react-native run-ios --device --binary-path [PATH] works & installs pre-built .app on device
• [x] react-native run-android works & builds from scratch
• [x] react-native run-android --deviceId [ID] works & builds from scratch
• [x] react-native run-android --binary-path [PATH] works & installs pre-built .apk on emulator/device
• [x] react-native run-android --deviceId [ID] --binary-path [PATH] works & installs pre-built .apk on emulator/device
• [x] react-native run-android --binary-path [PATH] --tasks 'test' throws; tasks and binary-path are not compatible
• [ ] catalyst build works as expected
• [ ] catalyst build throws if --binary-path specified

[thymikee]

Hey, this is interesting. What's the main use case, speed up the local builds, or maybe something else? Feel free to share your desired workflow :)

[andrejborstnik]

Hey, this is interesting. What's the main use case, speed up the local builds, or maybe something else? Feel free to share your desired workflow :)

Hey! The use-case as I see them are:

1. speed-up local build. First build can be relatively slow still, incremental builds are fine. Building once and never re-building again until native code changes (even if you want to install on a new device) would be great
2. speed-up build of other devs. We can share the pre-built .apk/.app within the dev team
3. remove the need for most developers to setup & maintain native development tooling and deal with possible build issues. Only devs adding native code/libs need to have the tooling setup. The rest just need:
   • the JS toolchain
   • adb
   • xcode/command-line-tools
   • respective device and (optional) simulator/emulator

[andrejborstnik]

@thymikee do you have any thoughts on the feature?

[thymikee]

I think it makes sense. Is it ready for a review?

[andrejborstnik]

I think it makes sense. Is it ready for a review?

It is ready for review. I just rebased it on latest main for your convenience

[github-actions[bot]]

There hasn't been any activity on this pull request in the past 3 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 7 days.

[andrejborstnik]

@thymikee did you get a chance to review yet? Happy to rebase if needed

[thymikee]

cc @adamTrz @TMisiukiewicz

[thymikee]

Looks like the rebase is needed indeed, so if that's not a problem, I'd appreciate it 👍🏼

[andrejborstnik]

Looks like the rebase is needed indeed, so if that's not a problem, I'd appreciate it 👍🏼

@thymikee done

[TMisiukiewicz]

@andrejborstnik if possible, please add command description to docs/commands.md :)

[andrejborstnik]

@andrejborstnik if possible, please add command description to docs/commands.md :)

Done, lmk if the description sounds good or needs tweaking

[TMisiukiewicz]

LGTM 👍

[adamTrz]

Ugh, sorry for pinging you once more @andrejborstnik but there yet another merge conflicts present. Would you mind resolving them and then we can at least merge you PR? 🙂

[andrejborstnik]

Ugh, sorry for pinging you once more @andrejborstnik but there yet another merge conflicts present. Would you mind resolving them and then we can at least merge you PR? 🙂

@adamTrz rebased. Double-checked the rebase is ok, but might be worth re-running CI just in case

[adamTrz]

@andrejborstnik LGTM! All checks are green, merging 🎉 Thanks for the contribution 🙂