fix(pods): Fix invalid react-native/../react-native resolution for aliases

[kitten]

Description

Related: software-mansion/react-native-reanimated#9592 (same fix for react-native-reanimated and react-native-worklets)

The pod script attempts to resolve react-native/package.json to get to the version and perform a version check. It however performs a redundant react-native/../react-native resolution i.e. it essentially performs path.dirname(require.resolve('react-native/package.json')) (correct), but then joins this with ${dir}/.., then re-joins this with react-native.

Re-entering the react-native directory can be invalid in case of symlinks in the node_modules structure. The easiest way to reproduce an issue is to use react-native-tvos's pattern of aliasing "react-native": "npm:react-native-tvos@x.x.x". With isolated dependencies this will point a symlink at a directory that's named react-native-tvos and not react-native. The also applies to local link: dependency specifiers. Essentially, the directory name react-native is unnecessarily enforced.

This would lead to a cryptic file: no implicit conversion of nil into String. error

Test plan

• Existing pod install in working projects should continue passing unchanged
• https://github.com/kitten/douglowder--with-monorepo-tv-test/tree/init-pnpm
  • pnpm i then in apps/tv run pnpm prebuild (which runs pod install)

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Updates React Native package.json discovery logic in the gesture handler CocoaPods/Ruby utilities to resolve the React Native directory more directly and adjust fallback behavior.

Changes:

• Change try_to_parse_react_native_package_json to accept a React Native directory (instead of node_modules root) and read package.json from that directory.
• Update get_react_native_minor_version to derive the React Native directory via require.resolve('react-native/package.json') and adjust the ENV fallback path.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[m-bert]

Hi @kitten!

Is this problem specific to monorepo? Today I used newly created react-native-tvos to investigate our buttons and I didn't encounter any problems with doing pod install.

Existing pod install in working projects should continue passing unchanged

Unfortunately, after this change pod install no longer works in our example app 😞 Seems like while this is out-of-sync with Reanimated/Worklets the name of the function has to be unique, e.g.rngh_try_to_parse_react_native_package_json, otherwise it gets overriden. This is of course better than relying on the same code in 3 libraries.

[kitten]

I've renamed them. I assume we'd have to then do something similar in the other script in the related PRs, but the naming there is suspiciously generic. I'll leave it up to the review there though

Is this problem specific to monorepo?

No, not necessarily.

For the TvOS case, as mentioned, it's triggerable in isolated installations, since we try to re-enter the react-native folder that's not named 'react-native'

Generically, this applies to any case where we resolve through a symlink where the folder of the resolved package for react-native isn't called react-native, which can likely be triggered in other ways, like with link: too, although being a more rarely used pattern, or unlikely to be used in practice