Summary:
`use_frameworks!` is broken again in react-native 0.69 because React-bridging. in the `use_frameworks!` mode, header structures are flattened, so `#include <react/bridging/CallbackWrapper.h>` is not reachable to the header. to somehow workaround the issue without touch React-bridging imports, the pr do these things:
- use `header_mappings_dir` to keep `react/bridging` header structure
- because the header structure is not default framework header structure, explicitly `HEADER_SEARCH_PATHS` is necessary.
- forward declare `CallbackWrapper` and use it internally in ReactCommon. so that we don't need to add `HEADER_SEARCH_PATHS` for React-bridging to every pods depending on `ReactCommon/turbomodule/core`, e.g. React-RCTSettings.podspec.
[iOS] [Fixed] - Fix use_frameworks! for 0.69
Pull Request resolved: https://github.com/facebook/react-native/pull/34011
Test Plan:
```sh
$ npx react-native init RN069 --version next
$ yarn ios
```
Reviewed By: cortinico, cipolleschi
Differential Revision: D37169699
Pulled By: dmitryrykun
fbshipit-source-id: 309c55f1c611a2fc3902a83e8af814daaf2af6a0
Summary:
`pod install --project-directory=ios` silently fails to prep Hermes:
```
% pod install --project-directory=ios
[Codegen] Generating ios/build/generated/ios/React-Codegen.podspec.json
[Hermes] Downloading Hermes source code for commit 515e112edc267ad58d3c70991b3d9a721cc66b19
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 9478k 0 9478k 0 0 3939k 0 --:--:-- 0:00:02 --:--:-- 5591k
[Hermes] Expanding Hermes tarball for commit 515e112edc267ad58d3c70991b3d9a721cc66b19
[Hermes] Using pre-built HermesC
[!] One or more resources were not found and will not be included in the project. If they are found later and you want to include them, run `pod install` again.
warn Multiple Podfiles were found: ios/Podfile,macos/Podfile. Choosing ios/Podfile automatically. If you would like to select a different one, you can configure it via "project.ios.sourceDir". You can learn more about it here: https://github.com/react-native-community/cli/blob/master/docs/configuration.md
Auto-linking React Native module for target `ReactTestApp`: ReactTestApp-DevSupport
Analyzing dependencies
Fetching podspec for `DoubleConversion` from `../node_modules/react-native/third-party-podspecs/DoubleConversion.podspec`
[Codegen] Found FBReactNativeSpec
Fetching podspec for `RCT-Folly` from `../node_modules/react-native/third-party-podspecs/RCT-Folly.podspec`
Fetching podspec for `boost` from `../node_modules/react-native/third-party-podspecs/boost.podspec`
Fetching podspec for `glog` from `../node_modules/react-native/third-party-podspecs/glog.podspec`
[!] No podspec found for `hermes-engine` in `../node_modules/react-native/sdks/hermes/hermes-engine.podspec`
% ls -l node_modules/react-native/sdks
total 0
hermes-engine
hermesc
```
[iOS] [Fixed] - `pod install --project-directory=ios` fails when Hermes is enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/33909
Test Plan: Instead of running `pod install` inside `ios` folder, run `pod install --project-directory=ios`.
Reviewed By: cortinico
Differential Revision: D36693625
Pulled By: hramos
fbshipit-source-id: 8757a9c388348276b07c785c211979ec8f2e2f84
Summary:
Update `hermes-engine.podspec` to use pre-built Hermes artifacts from the corresponding React Native GitHub Release when targeting a specific React Native release.
Otherwise, fallback to building Hermes from source.
Changelog: [Internal]
Reviewed By: cortinico, cipolleschi
Differential Revision: D36609257
fbshipit-source-id: 6179c9e255558c7eaf1417ff46a2e7db120295f0
Summary:
The new Hermes scripts need to be included in the `react-native` npm.
The `shelljs` dependency that was used by the Hermes scripts is a dev dependency, so instead of adding to the `react-native` npm size, we refactored its use out of hermes-utils.js.
Changelog:
[General][Added] - Add Hermes scripts to package
Reviewed By: cortinico
Differential Revision: D36387135
fbshipit-source-id: 12d0bc29d365c4cb18d33a0d390e6e7d34864b7a
Summary:
Use pre-built hermesc if available by generating a ImportHermesc.cmake file that points to the hermesc binary. Recent `react-native` releases should have hermesc available in sdks/hermesc.
Hermes build scripts have been updated to support a `HERMES_OVERRIDE_HERMESC_PATH` envvar which can point to this generated ImportHermesc.cmake file.
Pull Request resolved: https://github.com/facebook/react-native/pull/33827
Changelog:
[iOS] [Changed] - Use pre-built HermesC if available in current React Native release
Reviewed By: cortinico
Differential Revision: D36024615
fbshipit-source-id: 476569f73309f9bd142f28cb02d1f7d57b6cbc6a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33825
Updates the CocoaPods build scripts to consume the prepare-hermes-for-build script, replacing the now redundant set of Ruby code that would previously set the filesystem up.
Changelog:
[iOS] [Changed] - When building Hermes from source, the filesystem will now be prepared using the new hermes-utils.js scripts, outside of CocoaPods
Reviewed By: cortinico
Differential Revision: D36336633
fbshipit-source-id: a4506db80c039529b14b0290d2f0b54fae78dcf2
Summary:
Adds a script that uses the new hermes-utils.js functions to prepare the local filesystem for Hermes to be built from source (e.g. download the Hermes source code tarball and extract it into its final location).
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D36334624
fbshipit-source-id: 012f758ecda07931bdb0ab1728b87733bf5af16a
Summary:
Currently, the tasks for downloading, expanding, and preparing Hermes to be built for Apple targets are split across the Circle CI and CocoaPods configs.
This diff sets out to consolidate these tasks into a single hermes-utils.js script that can be reused across CI and build systems.
The release script that is used to assign the Hermes tag for a given React Native version has been moved into `scripts/hermes`.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D36329356
fbshipit-source-id: 0222070adf201fa533b607a183471396d45c6caf
Summary:
Copy Hermes build scripts to React Native repository for greater control over the build pipeline when used in RN.
Changelog: [Internal]
Reviewed By: neildhar
Differential Revision: D36295406
fbshipit-source-id: 54bf4173b6c75db35de828378e6f5782a248ed2e
Summary:
Adjust logs during `pod install` to warn user about longer install times due to Hermes compilation.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D36143766
fbshipit-source-id: 0facb2e295543438dfbc46d11db1c4dc163acff9
Summary:
Using Fabric with a Swift native module is currently broken. There are currently two issues.
If you try to integrate a native module with Swift code, you will get the following error when running `pod install` with Fabric enabled:
```
[!] The following Swift pods cannot yet be integrated as static libraries:
The Swift pod `MyNativeView` depends upon `React-RCTFabric`, `React-Codegen`, `RCTTypeSafety`, and `ReactCommon`, which do not define modules.
To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries),
you may set `use_modular_headers!` globally in your Podfile, or specify `:modular_headers => true` for particular dependencies.
```
To resolve this, I have applied the suggestion from the error (set `:modular_headers => true` for the appropriate modules inside `react_native_pods.rb`.
Afterwards, `pod install` succeeds but I still got `Redefinition of module 'React'` during the build due to the conflict inside the generated modulesmaps `React-Core.modulemap` and `React-RCTFabric.modulemap`. This makes sense since `React-RCTFabric.podspec` has `s.header_dir = "React"` (see [here](https://github.com/facebook/react-native/blob/main/React/React-RCTFabric.podspec#L37)) and the module inherits that. However, we can explicitly specify `module_name` for the podspec which is what I have done. I have named the module `Fabric`, let me know if you think there's a better name.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Fixed] - Fix using Swift in a native module with Fabric enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/33743
Test Plan:
1. Clone [this](https://github.com/fortmarek/react-native) repo
2. From `main`, apply changes from [this](https://github.com/fortmarek/react-native/commit/26958fccf4b4ac90d0bf9bb3699f12760a6b2b58) commit (adding Swift file to the `MyNativeView` native module in the RN tester app)
3. Try to run `USE_FABRIC=1 RCT_NEW_ARCH_ENABLED=1 USE_CODEGEN_DISCOVERY=1 USE_HERMES=0 bundle exec pod install` inside the `packages/rn-tester`
4. Observe errors
5. Apply [the commit](https://github.com/facebook/react-native/commit/9772c6209d73257f679b76407e1b5a27ffe03219) from this PR
6. Both pod install and the subsequent build should succeed.
I can also make changes to the current `MyNativeView` module to include Swift as well if it's something that the React Native Core team would be interested in - in case you want the Swift native modules to be always buildable on `main`
Reviewed By: dmitryrykun
Differential Revision: D36097852
Pulled By: cipolleschi
fbshipit-source-id: 2faebcffd1115339f89a406e265a6a040218dc9c
Summary:
If Hermes is enabled, it will be built from source instead of using the CocoaPods hermes-engine pod.
Changelog:
[iOS] [Changed] Build Hermes from source when Hermes is used
Reviewed By: cortinico
Differential Revision: D35693945
fbshipit-source-id: eadc638106180b183fd6d1e2a272dc3df66fa8b6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33672
This pr adds a parameter to the `create-artifacts.js` script to accept the path to a node executable, falling back to `node` in case the parameter has not been passed.
Then, it passes the NODE_BINARY to the script in the `script_phases.sh` script.
This PR decouples the `node` environment from the system one and fixes a build issue in the new architecture when the environment has no `node`
## Changelog
[iOS][Changed] - Update CodeGen scripts to accept custom node executable
Reviewed By: cortinico, dmitryrykun
Differential Revision: D35748497
fbshipit-source-id: 41b102de6427d6ef0ba1f8725f4b939d3b8c63db
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33674
## Issue
In D35317070 (https://github.com/facebook/react-native/commit/0480f56c5b5478b6ebe5ad88e347cad2810bfb17) we introduced a way to configuring the Xcode environment via he `.xcode.env`, falling back to the old `find-node-for-xcode.sh` behavior in case of a misconfiguration.
Unfortunately, there were an issue with the new architecture for which the pods were not able to locate the `find-node-for-xcode.sh`, crashing while building the new architecture.
## Solution
This Diff solves the issue in two steps:
1. it exposes to the project the REACT_NATIVE_PATH like Android does here: D35451821 (https://github.com/facebook/react-native/commit/f8d7e0a968ea12606fd8cce03470fd374f732aad)
2. it leverages this new variables to reach the script
## Changelog
[iOS][Changed] - Fixed the fallback behavior when the `.xcode.env` file is missing, actually using the old `find-node-for-xcode.sh` script
Reviewed By: dmitryrykun
Differential Revision: D35779165
fbshipit-source-id: 393ef9a0b98d32d9cf226f7d109fdefd772e5120
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33673
This PR solves a TODO in a script that required a link to the documentation on the website.
## Changelog
[iOS][Changed] - Adding a link in a message for the users.
Reviewed By: cortinico
Differential Revision: D35742810
fbshipit-source-id: b7416a5bead5fa525ca69f05391b307195f5c987
Summary:
there are build errors happened when in [`generate_multiple_pod_projects`](https://blog.cocoapods.org/CocoaPods-1.7.0-beta/#multiple-xcodeproj-generation) mode and fabric is on. since we have multiple pod projects, there are something breaks.
### `-DRCT_NEW_ARCH_ENABLED=1` does not pass to `RCTAppSetupUtils.mm`
because `installer.pods_project` is targeting `Pods.xcodeproj` but not `React-Core.xcodeproj`. we should use ` installer.target_installation_results.pod_target_installation_results` to deal with `generate_multiple_pod_projects` mode.
### fatal error: 'CompactValue.h' file not found
```
In file included from /path/to/react-native/packages/rn-tester/build/generated/ios/react/renderer/components/rncore/Props.cpp:11:
In file included from /path/to/react-native/packages/rn-tester/Pods/Headers/Private/React-Codegen/react/renderer/components/rncore/Props.h:13:
In file included from /path/to/react-native/packages/rn-tester/Pods/Headers/Private/React-Fabric/react/renderer/components/view/ViewProps.h:11:
In file included from /path/to/react-native/packages/rn-tester/Pods/Headers/Private/React-Fabric/react/renderer/components/view/YogaStylableProps.h:10:
/path/to/react-native/packages/rn-tester/Pods/Headers/Public/Yoga/yoga/YGStyle.h:16:10: fatal error: 'CompactValue.h' file not found
#include "CompactValue.h"
^~~~~~~~~~~~~~~~
1 error generated.
```
`Props.cpp` -> `YogaStylableProps.h` -> `YGStyle.h` -> `CompactValue.h`
[`CompactValue.h` is internal private header for Yoga pod](https://github.com/facebook/react-native/blob/4eef075a583224ec9da6bbc4b42bc52508eb31be/ReactCommon/yoga/Yoga.podspec#L54-L56) where `React-Codegen` project cannot access to.
~there are some solutions toward this problem. one way is to make other yoga headers as public headers. i am not sure whether this solution would introduce any side effects. so i only make necessary projects to search yoga private headers.~
Update: a solution is to expose all yoga headers publicly. however, CocoaPods will put all public headers to module umbrella header. this will break YogaKit (swift) integration because swift module doesn't support c++. my pr is trying to expose all yoga headers to `$PODS_ROOT/Headers/Public/Yoga/yoga`, but use custom `module_map` to control which headers should be exposed to the swift module. CocoaPods's custom module_map has some limitation where cannot well support for both `use_frameworks!` mode and non use_frameworks! mode. there's a workaround to use `script_phase` copying the umbrella header to right place.
## Changelog
[iOS] [Fixed] - Fix iOS build error when Podfile `generate_multiple_pod_projects=true` and Fabric is on
Pull Request resolved: https://github.com/facebook/react-native/pull/33381
Test Plan:
verify with rn-tester
1. add `generate_multiple_pod_projects`
```diff
--- a/packages/rn-tester/Podfile
+++ b/packages/rn-tester/Podfile
@@ -5,7 +5,7 @@ platform :ios, '11.0'
# Temporary solution to suppress duplicated GUID error.
# Can be removed once we move to generate files outside pod install.
-install! 'cocoapods', :deterministic_uuids => false
+install! 'cocoapods', :generate_multiple_pod_projects => true, :deterministic_uuids => false
USE_FRAMEWORKS = ENV['USE_FRAMEWORKS'] == '1'
```
2. pod install and build rn-tester from xcode
Reviewed By: cortinico
Differential Revision: D34844041
Pulled By: dmitryrykun
fbshipit-source-id: 93311b56d8e44491307a911ad58442f267c979eb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33546
This Diff does 2 things:
1. Removes all the remnant of the `find-node.sh` script. This allows React Native to stay agnostic from any other node manager
2. Introduces a way for the developers to specify which `node` executable they want to use, through a simple `.env` file.
## Changelog
[iOS][Changed] - This PR removes the `find-node.sh` scripts and replaces it with an `.xcode.env` file that is sourced by the script phases that needs it. The `.xcode.env` file is versioned: to customize a local environment, an unversioned `.xcode.local.env` can be used.
Reviewed By: cortinico
Differential Revision: D35317070
fbshipit-source-id: 4b400ba56aa2d574db563fa67b2008e1ddde1c59
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33539
As we now provide `hermes-executor-debug` OR `hermes-executor-release` based on which version of RN we're building, we need to provide a variant aware AAR.
Changelog:
[Internal] [Changed] - Setup multi-variant publishing for React Native Android
Reviewed By: ShikaSD
Differential Revision: D35289444
fbshipit-source-id: ffccd2089dc2eb50ea8c08ed10d8fd9816f9efb7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33538
This Diff is a revert of this other diff: D34352049 (https://github.com/facebook/react-native/commit/802b3f778b4d2ecd22882b371a84293421558b8a).
Following a discussion with the Open Source Community, the removal of `find-node.sh` script will break some configurations that leverages different node managers.
The landed diff will block the release of version 0.69, that's the reason why we are reverting it.
However, we still want to abstract RN from knowing which node manager the user is going to use. After discussing with the community, we will deprecate the usage of this script and we will move toward a configurable `.xcode.env` file that developers can configure on their own. The task for this is tracked here: T115868521.
## Changelog
[Internal][Removed] - Reintroduce the old `find-node.sh` script to prevent broken builds for some users
Reviewed By: cortinico
Differential Revision: D35280778
fbshipit-source-id: 7a0b269af207e13998fd85c0c4839e75028cda65
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33549
When building Hermes from source, use arbitrary hermes-engine.podspec to ensure correct Hermes tag is used by CocoaPods.
Without this change, CocoaPods will check out the `v0.11.0` git tag from the `facebook/hermes` git repository.
Ideally, this change should be done in the original `hermes-engine.podspec` in `facebook/hermes`. For now, use the arbitrary copy until the canonical Pod has been updated.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35300595
fbshipit-source-id: be4b1225eb2c2a88958cd9e5e98cb8efed343bad
Summary:
Print logs during `pod install` to clarify when Hermes is being used with RNTester and/or iOS React Native apps.
This changeset should not result in any change to the behavior of `pod install`, other than adding logs to CocoaPods' stdout.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35294993
fbshipit-source-id: 55b6115d9f49c311c34ad3cb07346b2f97adcbf9
Summary:
When downloading Hermes from source on Circle CI, the process will fail because Circle CI macOS machines do not have wget installed.
Since curl can serve the same purpose and it is already part of the installed software on macOS machines, we can use curl in place of wget.
This change ensures Hermes can be built from source on Circle CI jobs.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35294868
fbshipit-source-id: bb099b603ef64205d45b833882852b2f4d6060ca
Summary:
In https://github.com/facebook/react-native/blob/main/scripts/update-ruby.sh#L61
```bash
bundle lock
```
is called which creates a Gemfile.lock in the rn root. This file should be in the git add files list along with the other files that get updated by that script.
## Changelog
[Internal] [Fixed] - Added Gemfile.lock to git add files when calling update-ruby.sh
Pull Request resolved: https://github.com/facebook/react-native/pull/33484
Test Plan: Call update-ruby.sh with or without this patch. Without this patch, the Gemfile.lock will not be staged, with this patch, the Gemfile.lock will be staged.
Reviewed By: GijsWeterings
Differential Revision: D35118250
Pulled By: cortinico
fbshipit-source-id: 80f2c7fad6fbc3f09697988dcc20f7ac94a21473
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33499
This DIFF turns on the `FB_SONARKIT_ENABLED` flag when installing Flipper ina RN app. The flag is enabled only in Debug config, given that Flipper is installed only in this configuration.
This PR also fixes this issue: https://github.com/facebook/react-native/issues/33497
This PR is required because release 0.67 has the Flag in the app, while release 0.68 moved it in the React-Core pod.
We can't enable the flag at the `React-Core.podspec` level because we should not make assumptions on whether users want flipper or not.
## Changelog
[iOS][Changed] - Enable SonarKit in React-Core when the configuration is `'Debug'`
Reviewed By: cortinico
Differential Revision: D35141506
fbshipit-source-id: 171b7fa8ea7727c633ef963408e86b332c32e9fa
Summary:
Undoing the recent change that enabled Hermes to be built from source by default.
Building Hermes from source now requires the use of the BUILD_HERMES_SOURCE envvar, again.
To be re-enabled shortly.
Pull Request resolved: https://github.com/facebook/react-native/pull/33478
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35100459
fbshipit-source-id: ec83fcdf2432c689b0c02f86fbabcc8625975d51
Summary:
Remove BUILD_HERMES_SOURCE gate and default to building Hermes from source on iOS when Hermes is enabled.
Changelog:
[iOS][Changed] - When Hermes is enabled, the Hermes Engine will be built from source instead of using the pre-built `hermes-engine` CocoaPod.
Reviewed By: cortinico
Differential Revision: D34911987
fbshipit-source-id: 9d6d49498a23f6dae0b97c9f80c689b654db11bd
Summary:
GitHub's tarball endpoint does not provide a last-modified header, which keeps us from using wget's `--timestamping` flag to avoid re-downloading Hermes unnecessarily.
To work around this, we use the commit sha for the requested Hermes version - whether that is Hermes from trunk (`main` branch) or Hermes from a tagged commit - as the filename for the hermes tarball. Then it's as simple as performing a filesystem check to determine if we need to re-download the Hermes tarball. This should work as expected because any changes will result in a different commit SHA.
Additionally, a symbolic link to the pre-compiled HermesCompiler is created after the Hermes tarball is extracted. The result of this is that hermesc won't be recompiled when the `hermes-engine` Pod is built.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D34834139
fbshipit-source-id: 4c49bc11f3551ec8d6cca58fcceccad48ad4a10f
Summary:
For the same reason we don't keep a yarn.lock or Podfile.lock, we shouldn't be keeping a Gemfile.lock in the template. The user will generate this on his own pulling in the current dependencies with the constraints in Gemfile. No need to lock to a specific version.
cc barbieri (author of https://github.com/facebook/react-native/pull/32303)
cc ravirajn22 (for raising the issue)
## Changelog
[iOS] [Fixed] - Remove Gemfile.lock from template
Pull Request resolved: https://github.com/facebook/react-native/pull/33469
Test Plan: no test plan
Reviewed By: javache
Differential Revision: D35074105
Pulled By: cortinico
fbshipit-source-id: 47d1b92329f1d55d4a0adbacbc7e5e45f9d957e0
Summary:
When upgrading `react-native`, the version `RCT-Folly` defined [here](https://github.com/facebook/react-native/blob/main/third-party-podspecs/RCT-Folly.podspec) can change. If that happens, if you run `pod install` after `yarn install`, you will get a similar error to this:
```
[!] CocoaPods could not find compatible versions for pod "RCT-Folly":
In snapshot (Podfile.lock):
RCT-Folly (from `../node_modules/react-native/third-party-podspecs/RCT-Folly.podspec`)
In Podfile:
RCT-Folly (from `../node_modules/react-native/third-party-podspecs/RCT-Folly.podspec`)
React-RCTNetwork (from `../node_modules/react-native/Libraries/Network`) was resolved to 0.66.3, which depends on
RCT-Folly (= 2021.06.28.00-v2)
```
This error occurs because `Cocoapods` does not update pods that point to a local podspec. Locally, you could resolve this issue by running `pod update RCT-Folly --no-repo-update`. On the CI, you have to do a clean checkout (in case you cache the `Pods` folder which we do). All of this makes upgrading `react-native` painful - for the whole community and for us shopify
There are other users who have struggled with this, such as [here](https://github.com/facebook/react-native/issues/32423). The suggestion there is to delete `Podfile.lock` which is unnecessary - but it shows that users are confused what to do with this error and is something worth fixing.
To mitigate these issues, `react_native_pods.rb` automatically marks `RCT-Folly` as changed in the [detect_changes_with_podfile method](https://github.com/CocoaPods/Core/blob/master/lib/cocoapods-core/lockfile.rb#L289) from `Pod::Lockfile` if the version in `node_modules/react-native/third-party-podspecs/RCT-Folly.podspec` and `Pods/Local Podspecs/RCT-Folly.podspec.json` mismatch.
Instead of automatically updating the local podspec (in `Pods/Local Podspecs` directory) we could also:
a) integrate `RCT-Folly` as a local pod (such as `React-Core` and others)
b) integrate `RCT-Folly` as an external dependency (going through Cocoapods' centralized repository)
I don't have enough context on why `RCT-Folly` is bundled the way it is, so I am open to suggestions here.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Fixed] - Fix `pod install` when `RCT-Folly` version has been updated.
Pull Request resolved: https://github.com/facebook/react-native/pull/32659
Test Plan:
I have created a [repository](https://github.com/fortmarek/react-native-upgrade-reproduction) where you can reproduce the issue. You can simply:
1) clone the repo (`git clone https://github.com/fortmarek/react-native-upgrade-reproduction`)
2) Run `yarn install && cd ios && pod install`
3) Change `react-native` version in `package.json` to `0.66.3`
4) Run again `yarn install && pod install`
5) Observe error
To test the fix, you can then:
1) copy-paste the `react_native_pods.rb` file from this branch to `react-native-upgrade-reproduction/node_modules/scripts/react_native_pods.rb`
2) run `pod install` again
This time, the `pod install` command should succeed.
Reviewed By: sota000
Differential Revision: D32720758
Pulled By: cortinico
fbshipit-source-id: 940db9c9f0530f896e47b676dec46bc93cea0085
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33439
This allows us to toggle the publishing of prefab if the `REACT_NATIVE_HERMES_SKIP_PREFAB`
env variable is set. With this we can control how big is the .aar of hermes-engine, reducing
the size from ~200Mb right now to 8Mb.
Changelog:
[Internal] [Changed] - Disable prefab publishing if REACT_NATIVE_HERMES_SKIP_PREFAB is set
Reviewed By: ShikaSD
Differential Revision: D34929265
fbshipit-source-id: eb710b72ee4e17ac04c2924ffdac7a542928e9f8
Summary:
This re-applies Consider relative to pwd installation root when looking for files in rn module via cocoapods by danilobuerger
The `:reactNativePath` provided by `use_native_modules!` is the rn module path relative to the installation root (usually `./ios`). However, when executing cocoapods from a dir thats not the installation root, packages that use the relative `:reactNativePath` variable in their path must also consider the relative to pwd installation root.
This fixes usage of cocoapods with the `--project-directory` flag like
```bash
bundle exec pod install --project-directory=ios
```
## Changelog
[iOS] [Fixed] - Fix usage of cocoapods with --project-directory flag and new arch
Pull Request resolved: https://github.com/facebook/react-native/pull/33427
Test Plan:
1) Enable the new arch
2) Execute from the projects root dir
```bash
bundle exec pod install --project-directory=ios
```
3) It will fail with
```
[!] Invalid `Podfile` file: [codegen] Couldn't not find react-native-codegen..
```
4) Apply the patch
5) Execute from the projects root dir
```bash
bundle exec pod install --project-directory=ios
```
6) It will succeed
Reviewed By: cortinico
Differential Revision: D34890926
Pulled By: dmitryrykun
fbshipit-source-id: f7adc6196874822d5ff38f275414f529d385f2ea
Summary:
The `:reactNativePath` provided by `use_native_modules!` is the rn module path relative to the installation root (usually `./ios`). However, when executing cocoapods from a dir thats not the installation root, packages that use the relative `:reactNativePath` variable in their path must also consider the relative to pwd installation root.
This fixes usage of cocoapods with the `--project-directory` flag like
```bash
bundle exec pod install --project-directory=ios
```
## Changelog
[iOS] [Fixed] - Fix usage of cocoapods with --project-directory flag and new arch
Pull Request resolved: https://github.com/facebook/react-native/pull/33399
Test Plan:
1) Enable the new arch
2) Execute from the projects root dir
```bash
bundle exec pod install --project-directory=ios
```
3) It will fail with
```
[!] Invalid `Podfile` file: [codegen] Couldn't not find react-native-codegen..
```
4) Apply the patch
5) Execute from the projects root dir
```bash
bundle exec pod install --project-directory=ios
```
6) It will succeed
Reviewed By: ShikaSD
Differential Revision: D34784966
Pulled By: dmitryrykun
fbshipit-source-id: d6d5e71bc2fcd32f2cd60a498f39e6f772fc9005
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33413
This moves `CallbackWrapper` and `LongLivedObject` into a new "bridging" library. This library is mostly intended for use by the native module system, but can also be used separately to "bridge" native and JS interfaces through higher-level (and safer) abstractions than relying JSI alone.
Changelog:
Internal
Reviewed By: christophpurrer
Differential Revision: D34723341
fbshipit-source-id: 7ca8fa815537152f8163920513b90313540477e3
Summary:
Flipper-DoubleConversion and Flipper-Glog iOS pods received a build optimization
a few versions back that pre-compiled the pods and references the xcframework slices
Unfortunately, the pre-compile did not include macCatalyst slices, so this disabled support
for flipper on macOS for react-native >0.65
lblasa has re-compiled the pods with the macCatalyst slices added
See https://github.com/facebook/flipper/issues/3117
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Fixed] - update Flipper pods to support re-enable macCatalyst
Pull Request resolved: https://github.com/facebook/react-native/pull/33406
Test Plan:
- [ ] The Flipper repo has a react-native test that appeared to work with these versions, CI should work here
- [ ] Prove there is no regression, a flipper-enabled build test should work for simulator iOS target on arm64
- [ ] Prove there is no regression, a flipper-enabled build test should work for simulator iOS target on x86_64 mac
- [ ] Prove there is no regression, a flipper-enabled build test should work for real device iOS target
- [ ] To prove the issue is resolved, a build should be attempted for a macCatalyst target, and it should work.
Reviewed By: cortinico
Differential Revision: D34789654
Pulled By: lblasa
fbshipit-source-id: 466803dd07b5820220512b7d7d760b94b8aa65f7
Summary:
Downloads a tarball of the Hermes source code when `pod install` is run.
If the current release is pinned to a Hermes tag, it will use that specific tag, otherwise the latest Hermes commit will be used.
# Changelog:
[Internal]
Reviewed By: cortinico
Differential Revision: D34629595
fbshipit-source-id: 5f36af4a43bc2d137dfd702082558ab9d0191140
Riccardo
Kudo Chien
Nicola Corti
Tommy Nguyen
Héctor Ramos
fortmarek
Luna Wei
matinzd
Danilo Bürger
Andrei Shikov
Oleg Kot
Scott Kyle
Mike Hardy