Fix hermes-engine Podfile.lock checksum inconsistency across developers

[rolandnagy]

Summary:

Fixed an issue where developers with identical development environments get different checksums for hermes-engine in Podfile.lock, causing unnecessary git conflicts.

The root cause was that hermes-engine.podspec used require.resolve() to get the absolute path to hermes-compiler, which included usernames. This caused the generated hermes-engine.podspec.json to differ across developers, resulting in different checksums.

See Issue: #54891

Changelog:

[IOS] [FIXED] - Fix hermes-engine Podfile.lock checksum inconsistency across developers

Test Plan:

• Created a test project with local React Native changes
• Ran pod install and verified hermes-engine.podspec.json contains
  ${PODS_ROOT}/../../node_modules/hermes-compiler path
• Verified app builds and runs successfully with Hermes enabled
• Verified that rn-tester app builds and runs successfully
• Confirmed hermesc binary resolves correctly at build time

[meta-codesync]

@philIip has imported this pull request. If you are a Meta employee, you can view this in D90932424.

[cortinico]

Review automatically exported from Phabricator review in Meta.

[cipolleschi]

Thanks for the attempt. This is not the right solution because we can't make assumptions on the structure of the projects. React Native is not used from the template only, but also in several brownfield scenarios we need to consider.

In the comment, I suggested a proper fix.

You can also test the fix by building the RNTesterApp locally:

# from the react-native folder
yarn install
cd packages/rn-tester
bundle install
bundle exec pod install
open RNTesterPods.xcworkspace
yarn start

Then build and run in xcode.

[cipolleschi]

Thanks for the attempt, but this won't work.

Sure, it works for the template app specifically, but, for example, it does not work for the RNTester app we have inside the repo.

For the RNTester app, the Pods folder is located in react-native/packages/rn-tester/Pods.
Therefore ${PODS_ROOT}/../../ points to packages, which won't have a node_modules folder, so the HERMES_CLI_PATH will always fail.

The right approach here would be to keep the resolution, and then use something like Pathname#relative_path_from to compute a path that it is always correct, independently from how the project is set up.

[rolandnagy]

Thanks for pointing that out! I've updated the implementation as per your suggestion to use Pathname#relative_path_from.