feat: make the react native package name passable

[kraenhansen]

Summary

In the current version of the React Native Community template, the reactNativePath is passed as

• :path argument for the use_react_native call.
• Second argument for the react_native_post_install call.

An out-of-tree platform like react-native-macos cannot reuse this pattern, as it needs to pass it's own package path and the value of reactNativePath in the output of the config command points to React Native Core's path.

Merging this PR will add a new optional --react-native-package-name option, which the out-of-tree platform can pass when linking native modules to resolve their own package, instead of "react-native".

Test Plan

I added a unit test for the new behavior and I manually verified the --react-native-package-name was passed correctly through to the loadConfig functions into resolveReactNativePath.

Checklist

• Documentation is up to date.
• Follows commit message convention described in CONTRIBUTING.md. (or rather the PR title does? 🤷)
• For functional changes, my test plan has linked these CLI changes into a local react-native checkout (instructions).

[Saadnajmi]

Nit on naming, I wonder if it's better to have something like --platform or --out-of-tree-platform and maintain a mapping somewhere (there's only a handful of us and that's what react native test app does?)

[kraenhansen]

Nit on naming, I wonder if it's better to have something like --platform or --out-of-tree-platform and maintain a mapping somewhere (there's only a handful of us and that's what react native test app does?)

Yeah - the config command already takes a --platform and I started the implementation just using that to lookup the package name in an object. Once I had that, it felt a bit off to me to embed names like react-native-macos and @callstack/react-native-visionos into the community CLI, instead of what I suggest here by making that passable by the caller of the CLI (which is essentially the out-of-tree platform codebase).

I know it's not like a React Native platform is born every week (it's perhaps more like every other week 🙈😄), but it would be nice for someone to take advantage and rely on the CLI as they're building out the new platform, without having to rely on the CLI to merge a PR to update the lookup object.

I'd be happy to change this to a lookup in an object if that seems more appropriate 👍

[kraenhansen]

The test failures seem unrelated 🤔

[thymikee]

@Saadnajmi what's the reason you need to set the path variable to ../node_modules/react-native-macos specifically? @kraenhansen I'm not a fan of this solution as it builds on poor variable choice that we have in the Podfile template today:

1. The reactNativePath can be set in user config and then the flag is overridden (which would resolve your issue I suppose)
2. When one has multiple OOT platforms, where this variable should point to? (it's not clear currently)

Would like to use this as a discussion for a better API before we commit to complicate this even further.

[Saadnajmi]

@Saadnajmi what's the reason you need to set the path variable to ../node_modules/react-native-macos specifically? @kraenhansen I'm not a fan of this solution as it builds on poor variable choice that we have in the Podfile template today:

1. The reactNativePath can be set in user config and then the flag is overridden (which would resolve your issue I suppose)

2. When one has multiple OOT platforms, where this variable should point to? (it's not clear currently)

Would like to use this as a discussion for a better API before we commit to complicate this even further.

This is mostly driven by Kraen, who needed this to get some CLI stuff working for macOS. Happy to discus a better API :)