Summary:
Patch release bumps that just change arm64 slice packaging
See https://github.com/facebook/flipper/issues/3117#issuecomment-1123759397
These pods were just released by lblasa and this PR integrates them - I personally confirm success on an arm64 doing a macCatalyst build for the first time since react-native 0.64, and users report intel works fine as well - no regression
## Changelog
[Catalyst][Fix] - use pods with arm64 macCatalyst slices
Pull Request resolved: https://github.com/facebook/react-native/pull/33809
Test Plan:
Run a macCatalyst build on intel machine and m1 machine, I use this harness as part of release-testers facebook group, and it exercises macCatalyst build if you pass in a valid development team (for signing) https://github.com/mikehardy/rnfbdemo/blob/main/make-demo.sh
(the test harness is locally modified to no longer exclude M1 builds and with a patch-package that implements this PR, pending this merge+release...)
Reviewed By: cortinico
Differential Revision: D36339335
Pulled By: cipolleschi
fbshipit-source-id: d4574fc960e6ff345b31a83ff4629e22edfcf2f7
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:
Pull Request resolved: https://github.com/facebook/react-native/pull/33802
We use to have a couple of tests for the script phases script that were not running during the CI.
This diff connect them with the two CI, so that they run together with the other ruby tests.
## Changelog
[iOS][Added] - Run script phases tests in CI
Reviewed By: fkgozali
Differential Revision: D36283211
fbshipit-source-id: 01b257cdc99b0bc196d60d49ac76cf044d61a7e9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33791
This flag is used as a duplication for the `RCT_NEW_ARCH_ENABLED` flag. There is a [spot](d96806bbc6/scripts/react_native_pods.rb (L31)) in the code where, if `RCT_NEW_ARCH_ENABLED`, then the `USE_CODEGEN_DISCOVERY` is set to true as well.
Maintain two different flags for similar reasons is cumbersome and error-prone. This diff removes the `USE_CODEGEN_DISCOVERY` in favor of the `RCT_NEW_ARCH_ENABLED` flag.
## CHANGELOG
[iOS][Removed] - Remove USE_CODEGEN_DISCOVERY flag
Reviewed By: cortinico
Differential Revision: D36244618
fbshipit-source-id: 8e8979268b7aa25b895236b0c3a86fb57c6f2ea6
Summary:
This Diff moves all the Flipper.rb related setup in the cocoapods scripts to a dedicated script.
It also removes the not needed dummy files and add tests for flipper.
## Changelog
[iOS][Internal] - Extract Flipper setup in a separate file and add tests
Reviewed By: cortinico
Differential Revision: D36129808
fbshipit-source-id: 5446203a69b527146c893aa9611e98688e20b778
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](26958fccf4) 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](9772c6209d) 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:
Pull Request resolved: https://github.com/facebook/react-native/pull/33729
This PR addresses [this comment](https://www.internalfb.com/diff/D35820848?dst_version_fbid=496290878846487&transaction_fbid=355967423221044).
It makes the CodeGen to the `outputDir` as base directory for the codegen.
Finally, it updates the unit tests accordingly.
## Changelog
[iOS][Changed] - use `outputDir` as base directory for the codegen and remove the possibility to customize the intermediate path. The generated code requires specific paths in the `#include` directive.
Reviewed By: cortinico, dmitryrykun
Differential Revision: D35935282
fbshipit-source-id: a9ad4e296efb042cf34b20db5eebb59614beb5f6
Summary:
This Diff splits the `generate-specs-cli.js` script into:
* `generate-specs-cli-executor.js`: which contains the logic to generate the code for iOS.
* `generate-specs-cli.js`: which contains the argument parsing logic and invokes the executor.
Finally it introduces some tests.
## Changelog
[iOS][Changed] - Refactor part of the codegen scripts and add tests.
Reviewed By: cortinico, dmitryrykun
Differential Revision: D35892576
fbshipit-source-id: 6a3205af049bf55aa4ecaf64544ebc4eb7b13f73
Summary:
This Diff splits the `generate-artifacts.js` script into:
* `generate-artifacts-executor.js`: which contains the logic to generate the code for iOS.
* `generate-artifacts.js`: which contains the argument parsing logic and invokes the executor.
Finally, it introduces some tests.
## Changelog
[iOS][Changed] - Refactor part of the codegen scripts and add tests.
Reviewed By: cortinico, dmitryrykun
Differential Revision: D35846674
fbshipit-source-id: 14873c3fe762606e9004a29e4a6b986bf6a8f055
Summary:
This Diff introduces some changes in the CodeGen to properly generate the types in the right folder.
## Issue
The codegen on iOS defines the output folder once, before creating the generated code.
When the code we have to generate is just a TurboModule (TM) or a Fabric Component (FC), this mechanism works properly.
However, if a library has to generate both TM and FC, actually using the library type `all`, all the code is generated using the TurboModules' output folder.
(**Note:** Android only works in this way)
This generates invalid code because all the FC's `#import` directives assumes that the code is generated in the FC output path which, in this case, is not.
## Solution
The adopted solution moves the responsibility to decide where the files has to be generated to the CodeGen step instead of in the preparatory phases.
The two paths are precomputed in the `generate-artifacts.js` script (the entry point for the CodeGen) and they are passed to all the scripts that requires them.
Once they reach the `RNCodegen.js` file, the generators creates the files and save them in the proper paths.
## Changelog
[iOS][Changed] - CodeGen now supports the `"all"` library type.
Reviewed By: cortinico, dmitryrykun
Differential Revision: D35820848
fbshipit-source-id: ce7f5393936e2ae17f8b2c970f6a011d27f641f2
Summary:
This PR adds a step in the iOS legocastle script to run the ruby tests in the cocoapods folder.
These tests are executed before the pod installation step: this because we would like to fail as fast as possible in case of issues.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D36006781
fbshipit-source-id: 8afbc1ccc751d2dc736bdc23ec382ebd7b5c7f4f
Summary:
This Diff prepares a set of dummy tests to make sure that our infra supports tests in ruby.
It also adds a scripts in the `__tests__` folder which can be invoked to run all the tests. The script performs a discovery of all the tests in the cocoapods folder.
Next steps will configure Sandcastles and CircleCI.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35968556
fbshipit-source-id: b8bf23d30dc5358ab603e396cce1c6639dd0f567
Summary:
This PR reestablish the WebSocketTest in CI which is making the `test_ios_unit` fail.
**Note:** the test_ios_unit is actually running integration tests...
## Changelog
[iOS] [Changed] - Fix the test_ios_unit test
Pull Request resolved: https://github.com/facebook/react-native/pull/33721
Test Plan: The CI of this PR is green. 😬
Reviewed By: cortinico
Differential Revision: D36002823
Pulled By: cipolleschi
fbshipit-source-id: 20eeb08bfd02658ad6579085241f81654f74c1af
Summary:
During the release of .69, we (fortmarek and me) discovered a couple of bits that needed
some intervention.
- `sdks/.hermesversion` was gitignored, so we could not commit that.
- `scripts/bump-hermes-version.js` was not executable, so we had to chmod +x to
make it runnable.
Here I'm fixing it.
Changelog:
[Internal] [Changed] - Fix release infrastructure failures discovered during .69 release
Reviewed By: cipolleschi
Differential Revision: D36003808
fbshipit-source-id: c4d82ed5e2c63988699035ac84b0e87ed8894540
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 (0480f56c5b) 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 (f8d7e0a968)
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](4eef075a58/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:
Fix CircleCI build for test_ios_rntester.
Broken due to [this commit](fefa7b6ac8) after adding dev tools profiler.
## Changelog
[Internal] [Fixed] - Fix rn tester app CI
Pull Request resolved: https://github.com/facebook/react-native/pull/33585
Test Plan: CI should be green.
Reviewed By: neildhar
Differential Revision: D35462642
Pulled By: cortinico
fbshipit-source-id: dbcb0a7e2e58fac1c77b2dbe4b833812175dc87c
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 (802b3f778b).
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
Summary:
Changelog: [Internal] This diff add support of relative paths in `app_path` argument of `use_react_native` function.
Ruby's `relative_path_from` function requires both paths to be either relative or absolute. I added `realpath()` call that converts any path to absolute.
Reviewed By: ShikaSD
Differential Revision: D33311728
fbshipit-source-id: 393a7b4f0eb26831f4d9f4cec8ec180b41cad580
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33209
Downloads Kotlin compiler JARs with Buck before starting docker build. This solution is slower than checking in JARs directly, but it allows to keep lighter size of the repo for people who want a complete checkout.
Changelog: [Internal] - Update CI build to download Kotlin jars for buck
Reviewed By: cortinico
Differential Revision: D34582932
fbshipit-source-id: 290398579ce2a4d57c7af318c66526689db6073c
Summary:
React Native releases that bundle the Hermes source code will have a `sdks/.hermesversion` file which indicates the specific git tag used when pulling the Hermes source code.
This script provides a method for release coordinators to specify which Hermes tag will be used in a given release. The Hermes tag should already exist on the `facebook/hermes` repository on GitHub, although this script makes no determination as to its validity.
# Changelog
[Internal] Added new script for release coordinators
Reviewed By: cortinico
Differential Revision: D34460693
fbshipit-source-id: b2f882ba66d925034c3803aafe81de5204d9e33f
Summary:
If Hermes is enabled on a project and the envvar `BUILD_HERMES_SOURCE` is truthy, a React Native project will build Hermes from source when running `pod install`:
```
cd ios/
BUILD_HERMES_SOURCE=1 pod install
```
* Requires `cmake` and `ninja` to be installed: `brew install cmake ninja`.
* Requires a `react-native` release with Hermes source code bundled in (`scripts/publish-npm.js --include-hermes && npm pack`).
# Changelog
[Internal]
Reviewed By: cortinico
Differential Revision: D34313581
fbshipit-source-id: 4ba5f82aa6c7027fd37f1982127fc5f63d931ded
Summary:
If `--include-hermes` flag is set, the Hermes source code will be downloaded and included in the `react-native` npm package as part of the release.
Hermes will be available at `node_modules/react-native/third-party-podspecs/hermes`.
# Changelog
[Internal] Update build scripts to provide option to bundle Hermes source code
Reviewed By: cortinico
Differential Revision: D34255926
fbshipit-source-id: 76c1e9811a05a4a827ceba13e572d0ea756ac724
Mike Hardy
Héctor Ramos
Riccardo Cipolleschi
fortmarek
Nicola Corti
Luna Wei
Kudo Chien
matinzd
Danilo Bürger
Andrei Shikov
Oleg Kot
Scott Kyle
Dmitry Rykun
Samuel Susla
