fix(codegen): empty ReactCodegen input_files when no Native spec files found

[Levin-nik]

Summary

When an app's codegenConfig.jsSrcsDir contains no files matching the codegen
spec naming convention (Native*.ts/Native*.js/*NativeComponent.ts/*NativeComponent.js),
getInputFiles() in generateReactCodegenPodspec.js emits a directory path
for the [CP-User] Generate Specs script phase's input_files, instead of an
empty list.

This causes an intermittent Xcode build failure on incremental builds:

error: Cycle in dependencies between targets 'ReactCodegen' and '<Pod>';
building could produce unreliable results.

Root cause

const list = String(execSync(findCommand))
  .trim()
  .split('\n')   // when `find` finds nothing → [""], not []
  .sort()
  .map(filepath => `"\${PODS_ROOT}/${path.relative(xcodeproj, filepath)}"`)
  .join(',\n');
return `[${list}]`;

When find matches no spec files, execSync returns an empty string and
"".split('\n') yields [""]. The .map then runs once with
filepath === "", and path.relative(xcodeproj, "") resolves to a relative
path to the project/app root (e.g. ..). As a result input_files becomes
["${PODS_ROOT}/.."] — a directory.

That directory typically contains the iOS build output (e.g. ios/build, when
-derivedDataPath is set inside the project — common in Detox/CI configs). The
pods that produce those artifacts depend on ReactCodegen, so Xcode detects a
dependency cycle. Clean builds pass (the output dir doesn't exist yet), so the
failure only surfaces on the 2nd and later builds, which makes it look
intermittent and hard to reproduce.

Fix

Drop empty entries so an empty find result yields [] → input_files: []:

   const list = String(execSync(findCommand))
     .trim()
     .split('\n')
+    .filter(Boolean)
     .sort()
     .map(filepath => `"\${PODS_ROOT}/${path.relative(xcodeproj, filepath)}"`)
     .join(',\n');
   return `[${list}]`;

For apps that do have Native* spec files, behavior is unchanged — real paths
are truthy and are kept. This is also consistent with the existing .filter(...)
already used for xcodeproj discovery in the same function.

Changelog

Changelog: [iOS] [Fixed] - Fixed intermittent "Cycle in dependencies between targets 'ReactCodegen' and ..." Xcode build error that occurred on incremental iOS builds when an app's codegenConfig.jsSrcsDir contained no Native*/*NativeComponent spec files.

Test Plan

Reproducer (on a New Arch app):

1. Set codegenConfig.jsSrcsDir to a directory with no Native*/*NativeComponent files (or empty).
2. cd ios && pod install.
3. Inspect build/generated/ios/ReactCodegen.podspec:
   • Before: 'input_files' => ["${PODS_ROOT}/.."] (a directory).
   • After: 'input_files' => [].
4. Build twice with an in-project derived data path:
   xcodebuild -workspace ios/MyApp.xcworkspace -scheme MyApp -configuration Debug -sdk iphonesimulator -derivedDataPath ios/build
   • Before: 1st build passes, 2nd (incremental) fails with the cycle error.
   • After: both builds pass.

Regression: in an app with real Native*.ts specs, confirm input_files still
lists the spec files and the generated codegen output is identical.

Fixes #57760

[meta-cla]

Hi @Levin-nik!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

[meta-cla]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!