Fix React-bridging header not found for third party modules

[Kudo]

Summary

Some third party modules will have build errors on react-native 0.69.1 if they have dependency to React-bridging (or ReactCommon/turbomodule/core from transitive dependency). We setup correct header search paths in ReactCommon.podspec. We should also apply the change to third party modules. This PR is a workaround for the migration without introducing breaking changes to third party modules.

Note that is pr is based on 0.69-stable. Because on main branch, the react_native_pods.rb has much refactoring. I'll probably create a new pr based on main branch after this one landed.

Fix #34102

Changelog

[iOS] [Fixed] - Fix React-bridging headers import not found

Test Plan

$ npx react-native init TestApp --version 0.69
$ cd TestApp
$ yarn add react-native-vision-camera
$ yarn ios

[pull-bot]

	Fails
🚫	node failed.

Log

Error:  RequestError [HttpError]: Must have admin rights to Repository.
    at /root/react-native/bots/node_modules/@octokit/request/dist-node/index.js:86:21
    at processTicksAndRejections (internal/process/task_queues.js:95:5) {
  status: 403,
  response: {
    url: 'https://api.github.com/repos/facebook/react-native/issues/34214/labels',
    status: 403,
    headers: {
      'access-control-allow-origin': '*',
      'access-control-expose-headers': 'ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset',
      connection: 'close',
      'content-encoding': 'gzip',
      'content-security-policy': "default-src 'none'",
      'content-type': 'application/json; charset=utf-8',
      date: 'Wed, 20 Jul 2022 16:05:39 GMT',
      'referrer-policy': 'origin-when-cross-origin, strict-origin-when-cross-origin',
      server: 'github.com',
      'strict-transport-security': 'max-age=31536000; includeSubdomains; preload',
      'transfer-encoding': 'chunked',
      vary: 'Accept-Encoding, Accept, X-Requested-With',
      'x-accepted-oauth-scopes': '',
      'x-content-type-options': 'nosniff',
      'x-frame-options': 'deny',
      'x-github-media-type': 'github.v3; format=json',
      'x-github-request-id': '8C7A:8B4A:7F4CA9:F1D430:62D827D3',
      'x-oauth-scopes': 'public_repo',
      'x-ratelimit-limit': '5000',
      'x-ratelimit-remaining': '4992',
      'x-ratelimit-reset': '1658336738',
      'x-ratelimit-resource': 'core',
      'x-ratelimit-used': '8',
      'x-xss-protection': '0'
    },
    data: {
      message: 'Must have admin rights to Repository.',
      documentation_url: 'https://docs.github.com/rest/reference/issues#add-labels-to-an-issue'
    }
  },
  request: {
    method: 'POST',
    url: 'https://api.github.com/repos/facebook/react-native/issues/34214/labels',
    headers: {
      accept: 'application/vnd.github.v3+json',
      'user-agent': 'octokit-rest.js/18.12.0 octokit-core.js/3.5.1 Node.js/14.19.0 (linux; x64)',
      authorization: 'token [REDACTED]',
      'content-type': 'application/json; charset=utf-8'
    },
    body: '{"labels":["Pick Request"]}',
    request: { hook: [Function: bound bound register] }
  }
}
danger-results://tmp/danger-results.json

Generated by 🚫 dangerJS against fa2acc3

[analysis-bot]

Platform	Engine	Arch	Size (bytes)	Diff
android	hermes	arm64-v8a	7,794,939	-25,545
android	hermes	armeabi-v7a	7,196,378	-17,994
android	hermes	x86	8,103,483	-30,721
android	hermes	x86_64	8,083,335	-28,974
android	jsc	arm64-v8a	9,667,992	-30,011
android	jsc	armeabi-v7a	8,438,449	-15,678
android	jsc	x86	9,616,895	-32,905
android	jsc	x86_64	10,214,308	-33,715

Base commit: 361d939
Branch: main

[cipolleschi]

Hi @Kudo, thanks for the PR. I see that you created it against the 0.69-stable. Is this something required for 0.69 only because it works on 0.70 or do we have to implement it also in main?

[Kudo]

@cipolleschi because the react_native_pods.rb is quite different on main because #33982, i am thinking to land this first on 0.69-stable. if the pr landed, i can create another pr for main branch. does this make sense to you?

[cipolleschi]

Yes, it makes sense. However, there are failures in CI that shouldn't be there. The only failure that should be there is the test_ios_unit. Could you try rerun the jobs, please?

[Kudo]

@cipolleschi i also wondered for the failures. however i don't have permissions to rerun the jobs. could you help to do that?

[cipolleschi]

So... for analyze_pr it looks like we are actually missing some permissions. I asked @cortinico about that.

For the other task, the issue is that Hermes is deciding that it won't build from source.. I think that we need to take this case into consideration...

[Kudo]

if the ci failures come from pr based on 0.69-stable, i can also create a new pr based on main branch first and leave this pr as reference when cherry-picking to 0.69-stable. let me know which one makes sense to you.

[cipolleschi]

@Kudo PR #34221 should fix this problem as well.
As soon as we cherry pick that, we could rebase this one and the CI should be green.

[Kudo]

sounds good! i'll rebase after that pr is cherry-picked. thanks!

[kelset]

@Kudo my PR landed and I've already cherry picked it in both 0.70 and 0.69 branches 👍 you can try rebasing your branch

[Kudo]

rebased, thanks @kelset!

[Kudo]

looks like the ci jobs failed at the same places again 🤔

[cipolleschi]

Yep... Basically, in this setup we don't need to build hermes from source. The prepare_hermes_workspace does that check. But, it expect to have a couple of folders to copy... which, in that case, are not there.

I'm working on a fix here: #34223

[Kudo]

thanks @cipolleschi ! i'll rebase after #34223 landed.

[cipolleschi]

Hi @Kudo, I merged #34223 in 0.69-stable. If you can rebase, let's see if the CI goes green!

[Kudo]

sure, thanks! let's see how it going.

[Kudo]

@cipolleschi looks like there're some failure jobs for building hermes, is it expected?

[cipolleschi]

No... I'm looking into it, right now.

[cipolleschi]

@kelset @Kudo
Sorry, the previous fix was not the correct one. This #34228 will actually do. I'm testing it right now. It has to be ported also in main, though, but I'll do it in a separate PR becauseI want to see if it fixes our issues in 0.69

[cipolleschi]

@Kudo, merged #34228. Could you rebase, so that we check that now it builds properly?

[Kudo]

@cipolleschi all ci jobs finished. are they in good state or any further jobs you would like to pass?

[cipolleschi]

And now the CI is green! we can merge this!

[Kudo]

@cipolleschi cool, i don't have permission to merge. maybe you could help merging it. thanks!

[evelant]

@Kudo This patch works in some configurations, but doesn't work when using pnpm as a package manager. In the case of pnpm the bridging headers get copied to the wrong directory. They end up at ios/build/Build/node_modules/.pnpm/react-native@0.70.5_2hkxedd44to6uuf252s62q5boq/node_modules/react-native/ReactCommon/react/bridging.

Where in the build process does it determine where to copy headers and why might it be using a bad path? I'm guessing it doesn't like pnpm's symlinking, but I'm not sure where to look to work around it.