[Due for payment 2025-10-13] Fix verifyPodfile check

[roryabraham]

Coming from: https://expensify.slack.com/archives/C05LX9D6E07/p1759315132607339

Proposal: Fix Podfile.lock verification by correcting JSON parsing in the existing workflow

Background

In our repository, we have a GitHub Actions workflow verifyPodfile designed to detect inconsistencies between the Podfile.lock and other dependency declarations (such as package.json and Podfile). This workflow should ensure that every Pull Request containing dependency changes does not introduce an unsynchronized Podfile.lock, preventing build failures and runtime issues.

Problem

The validatePodfile script in the workflow does not work correctly and fails to detect changes in Podfile.lock, even when they exist.

Solution

We will fix the existing script .github/scripts/removeInvalidJson.rb to correctly parse the JSON files containing information about the used pods. After this fix, the verifyPodfile workflow will properly detect inconsistencies in Podfile.lock.
This also ensures that running npm run pod-install does not generate unnecessary changes in the lockfile unrelated to the current branch.

BENEFITS

Ensuring Podfile.lock consistency prevents build failures and runtime issues. Additionally, it eliminates situations where running pod install generates unnecessary changes in the lockfile that are unrelated to the current branch.

[roryabraham]

@sumo-slonik has a draft PR: #71657

[sumo-slonik]

Problem

When running the verifyPodfile.sh on the current main branch, the podspec is printed in the following format:

{
  Name: xyz
  Version: xyz
}
{
  Name: xyz
  Version: xyz
}

However, in some cases, additional messages appear between objects, for example:

Your project includes the Expo package, but React Native Community CLI is unable to install the related Pods.
Make sure to require autolinking scripts from Expo and call `use_expo_modules!` in your target.
Learn more: https://docs.expo.dev/bare/installing-expo-modules

As a result, the data format looks like this:

{}
{}
{}
{}
Some text
{}
{}
{}

The removeInvalidJson.rb receives this as a single argument. For example:

ARGV = ["{\"name\":\"Alamofire\",\"version\":\"5.8.0\"} {\"name\":\"RxSwift\",\"version\":\"6.6.0\"} {\"name\":\"Moya\",\"version\":\"15.0.3\"}"]

The problem is that the JSON objects exist within {}, but they are not separated by commas. Consequently, the parser treats the entire string as one invalid JSON, causing the variable FORMATTED_PODS to remain empty.

This leads to the following code:

while read -r POD; do
  if ! grep -q "$POD" ./ios/Podfile.lock; then
    error "$POD not found in Podfile.lock. Did you forget to run \`npx pod-install\`?"
    cleanupAndExit 1
  fi
done <<< "$FORMATTED_PODS"

always iterating over an empty array. Therefore, this section never detects changes in Podfile.lock. The script may work correctly in other scenarios handled by other parts of the script, but this specific case will never work.

---

Solution

I introduced changes in the parsing logic so that the script now:

• Correctly detects closed JSON objects.
• Ignores text messages that appear between objects.

This produces a proper list of objects that can be used further. The updated version of the script can be viewed here:

[link to updated script]

I also concluded that we should add tests for this scenario to ensure that this problem does not occur in the future.