Summary:
Allow modifying iOS image cache limits. Currently the image cache imposes some strict limits:
[NSCache.totalCostLimit](https://developer.apple.com/documentation/foundation/nscache/1407672-totalcostlimit?language=objc) of 20MB.
Single Image Size Limit of 2MB (bitmap size).
This may not be enough for applications that make heavy use of images. With this commit it is possible to fine tune them to the applications need.
This can be set for example in the App Delegate with:
```objc
RCTSetImageCacheLimits(4*1024*1024, 200*1024*1024);
```
This would increase the single image size limit to 4 MB and the total cost limit to 200 MB.
## Changelog
[iOS] [Added] - Allow modifying iOS image cache limits
Pull Request resolved: https://github.com/facebook/react-native/pull/33554
Test Plan: There is no easy way to test this except adding the above snippet and checking via break points that the new limits are used.
Reviewed By: cipolleschi
Differential Revision: D35485914
Pulled By: cortinico
fbshipit-source-id: 646cf7cab5ea5258d0d0d0bce6383317e27e4445
Summary:
This PR updates the GitHub actions uses in the repository workflows.
## Changelog
N/A
Pull Request resolved: https://github.com/facebook/react-native/pull/33595
Test Plan: Run the workflows.
Reviewed By: rickhanlonii
Differential Revision: D35495697
Pulled By: cortinico
fbshipit-source-id: a41a83dc61f199f9acbc0ce28d6a23fafc94a99c
Summary:
As we introduced KGP inside `ReactAndroid` (cc ShikaSD), we now need to specify a version for it (as users will consume that build on Android New Architecture.
Currently, the version is loaded in the RN `rootProject` which is not available on user's project. I'm cleaning this up.
## Changelog
[Internal] - Do not specify a Kotlin version in the RN rootProject
Pull Request resolved: https://github.com/facebook/react-native/pull/33589
Test Plan:
Tested on a nightly version with
```
npx react-native init RNNightly --version nightly
```
Reviewed By: mdvacca
Differential Revision: D35476777
Pulled By: cortinico
fbshipit-source-id: 5a819ef5fa9a6886d7b7b683f31d59cb05a49f29
Summary:
While React Native depends on the `metro` package indirectly (via the CLI package), it depends on some secondary Metro packages directly. This diff updates those direct dependencies to use [Metro 0.70.1](https://github.com/facebook/metro/releases/tag/v0.70.1).
Changelog:
[General] Update direct Metro dependencies to 0.70.1
Reviewed By: robhogan
Differential Revision: D35462164
fbshipit-source-id: 5daeb28e60f1babb78c5029e673926c76de65491
Summary:
This is a follow up to my previous diff. It applies the same customization for M1 users to the :ReactAndroid:hermes-engine build.
The two diffs are split so the first one can be cherry-picked into 0.68.1 if needed.
Changelog:
[Android] [Fixed] - Improve support for Android users on M1 machine
Reviewed By: mdvacca
Differential Revision: D35468658
fbshipit-source-id: c07822f6708f872456971378f44257f6c1e967ee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33588
Currently users on M1 machine can't use the New Architecture correctly as they will get build failures when building the native code.
This Diff fixes it by automatically recognizing the host architecture and switching to NDK 24 if user is runnign on `aarch64`
Changelog:
[Android] [Fixed] - Improve support for Android users on M1 machine
Reviewed By: mdvacca
Differential Revision: D35468252
fbshipit-source-id: b73f5262b9408f04f3ae4fd26458a4d17c1ec29a
Summary:
Jest 28 will error if only a string is returned from a transfomer, it needs to be an object of `{code: string, map?: object}`. Returning an object has been supported since https://github.com/facebook/jest/pull/2290, released in Jest v20.
## 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
-->
[Internal] [Fixed] - Return object from Jest preprocessor
Pull Request resolved: https://github.com/facebook/react-native/pull/33576
Test Plan: Green CI?
Reviewed By: motiz88
Differential Revision: D35426748
Pulled By: robhogan
fbshipit-source-id: 3edb79b62b2d34274be192061817d3fcd8a7ba17
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:
This diff adds more folders to the cleanAll gradle task,
a utility task that gets invoked when cleaning the whole project.
Just realized that after the Hermes integration project, we never
added those folders that now need to be cleaned up as well.
Changelog:
[Internal] [Changed] - Add further folders to the cleanAll Gradle task
Reviewed By: sshic
Differential Revision: D35444265
fbshipit-source-id: ee4ded9a4ee9554b5e3f0f8cb85f60a4797e9010
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33581
We currently have some code on the RN Gradle Plugin that we need to ship.
There are both bugfixes needed for RN 0.68.1 and for the current nightly
(therefore needed for RN 0.69).
I've verified that this works on a fresh RN 0.68.0 install with `npm pack`
and triggering a build on a fresh setup from app template, with newArchEnabled set to true.
Changelog:
[Android] [Changed] - Bump React Native Gradle plugin to 0.0.6
Reviewed By: rubennorte
Differential Revision: D35439444
fbshipit-source-id: 662b2211c44b261e3e3c9cddc946107cfb495c79
Summary:
The reason why I'm working on this is to reduce the delta between this and the react-native-macos fork, in particular with the android patch folder "Build": https://github.com/microsoft/react-native-macos/tree/main/android-patches/patches/Build (it's a long story)
While checking the changes in there, I noticed that one of them was a bump of boost. Looking back into main (here), I then noticed that there have been two bumps to boot in the repo so far:
* a combo update 5 years ago to 1.63:
* 193afff926
* 5c24a9110a
* and an update for the iOS side to 1.76 by Kudo last year: https://github.com/facebook/react-native/pull/31840
So this quickly turned into this: the PR wants to re-align the version of boost used in both iOS and Android.
I explored the option of bumping both to 1.78 (latest at the time of writing: https://www.boost.org/users/history/version_1_78_0.html) but then I noticed that there's a Flipper dependency, `Flipper-Boost-iOSX`, on the iOS pods side that has been released only once and it seems to imply that it's 1.76 only compatible https://github.com/priteshrnandgaonkar/Flipper-Boost-iOSX/releases/tag/1.76.0.1.11.
So going to 1.78 at least for now seems like a no-go, and I've settled for just aligning everything to 1.76 and just like iOS, move away from `boost-for-react-native` in favour of the original one.
While doing so, I also noticed that the `React/third-party.xcconfig` still had a reference to 1.68 instead of 1.76 which seems like a leftover from Kudo's PR... it's probably because it was not doing anything in the first place, so lmk if you want me to delete it.
## 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
-->
[Android] [Changed] - Bump boost for Android to 1.76 to align with iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/33565
Test Plan:
CI is green (aside an unrelated ios rntester job that is also broken on main) ✅
Locally both RNTester and new app work:
<img width="432" alt="Screenshot 2022-04-05 at 16 42 31" src="https://user-images.githubusercontent.com/16104054/161815444-0de63919-b90d-4a48-963a-872f0cc4ce79.png">
<img width="346" alt="Screenshot 2022-04-05 at 18 06 01" src="https://user-images.githubusercontent.com/16104054/161815438-b7b1c997-9dcd-47bd-acbe-732155941bb0.png">
Reviewed By: sshic
Differential Revision: D35433032
Pulled By: cortinico
fbshipit-source-id: 0d93f61f8c26eda1dd04127a8b20e799ab6828cb
Summary:
While testing with the RN Nightly versions, I realized we pushed two changes
recently that are not working fine with the gradle setup of our users.
That's becuase we're referencing the `rootProject` directly.
`rootProject` should never be used directly as it resolves to:
- The root of the git repo of `react-native` when building the RN project (so
`./ReactCommon` exists there).
- The /android folder of users' project when building an app that uses RN (so
`./ReactCommon` does not exists there).
Changelog:
[Android] [Fixed] - Do not use `rootProject` directly in Gradle scripts
Reviewed By: sshic
Differential Revision: D35444967
fbshipit-source-id: be0508480a08224302168804b6feb52fd604d8db
Summary:
I'm just adding a macro passing the NODE_MODULES_DIR to the NDK build.
This will make easier to import external libraries for our users.
Changelog:
[Internal] [Changed] - Specify a NODE_MODULES_DIR inside the NDK config for the Android template
Reviewed By: cipolleschi
Differential Revision: D35451821
fbshipit-source-id: 5d79359a1610f2de4ec2d50a78b4c930458185d8
Summary:
Changelog: [Fabric][iOS] Fix: Make RCTSurfacePresenter weakly retain its observers
There is retain cycle because RCTSurfacePresenter is keeping an array of RCTSurfacePresenterObserver, which is strongly retaining the class that owns this RCTSurfacePresenter.
This diff makes RCTSurfacePresenter weakly retain observers instead.
Reviewed By: RSNara
Differential Revision: D35439589
fbshipit-source-id: ddc7813976b543de12af6173b2f1b31c69b043a8
Summary:
Changelog:
[iOS][Changed] - Update `PushNotificationIOS.checkPermissions` to include iOS 10+ notification settings.
`PushNotificationIOS.checkPermissions` is currently limited to only return:
* alert :boolean
* badge :boolean
* sound :boolean
That's has been a number of new properties since iOS 10 that we should support to improve pushability signal. This diff updates the logic to support 4 new available settings:
* critical :boolean,
* lockScreen :boolean,
* notificationCenter :boolean,
* autorizationStatus: number,
Reviewed By: philIip
Differential Revision: D35386762
fbshipit-source-id: 07c87de024756bc95a2c822ac35437ec76b3c903
Summary:
Annotations inside of destructuring (e.g. `const [foo: number] = ...`) are invalid Flow syntax. We currently ignore them, and in the future will error on them (D35304565).
Remove them using the codemod from D35390352
Locally changed WWW_ROOT, FLOW_ROOTS, and excluded paths in scripts/typedjs/flow/runner.config.js (e.g. P492224584) - and then
```
scripts/typedjs/flow/runner codemod removeAnnotationsInDestructuring ~/fbsource/xplat/js
```
formatting files didn't work, so do it manually
Changelog: [Internal]
drop-conflicts
Reviewed By: fred2028
Differential Revision: D35419146
fbshipit-source-id: e4c05506ceec11afcc8e92f13f732510ebabdbc3
Summary:
changelog: [internal]
this never fired, so it's not the cause of the nil moduleRegistry issue
Reviewed By: christophpurrer
Differential Revision: D35419873
fbshipit-source-id: 45693d3aa97d9efed2fe5085c281b57f1629764d
Summary:
Now that the PFH node has been renamed this updates the pfh label.
Produced via `xbgs -l -e '"pfh:ReactNative_CommonInfrastructurePlaceholde"' | xargs sed -i 's/"pfh:ReactNative_CommonInfrastructurePlaceholde"/"pfh:ReactNative_CommonInfrastructurePlaceholder"/'`
Reviewed By: jkeljo
Differential Revision: D35374087
fbshipit-source-id: 61590f69de5a69ec3b8a0478f6dd43409de3c70b
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:
This adds the option for a TurboModule spec to use a "Cxx" suffix to unblock additional capabilities. This extends the pattern where TurboModules can have an "Android" or "IOS" suffix to exclude codegen for the other platform. When in `cxxOnly` mode, the parser will allow function return types (and additional features will be added over time).
Changelog:
[General][Added] C++ TurboModule methods can return functions
Reviewed By: christophpurrer
Differential Revision: D35364346
fbshipit-source-id: 768eb0ec2a1cbe3e458466064247d7e7f01135ff
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33560
X-link: https://github.com/facebook/hermes/pull/720
Turn on ICF for the build whenever it is available. This requires us to
link with LLD, which is only the default starting in NDK r23, so
manually specify LLD for the Android build.
Also turn on LTO for the CircleCI build, so we generate highly
optimised binaries for distribution.
Changelog: [Internal]
Reviewed By: jpporto
Differential Revision: D35344254
fbshipit-source-id: 64b37e6a7817a7b7826cc7480468367b95d63c61
Summary:
We currently enable the debugger by default on all platforms except
Android. On Android, we then manually enable the debugger in debug
builds. Instead, change it so the debugger is manually disabled in
release builds, to simplify the setup.
Changelog: [Internal]
Reviewed By: jpporto
Differential Revision: D35347444
fbshipit-source-id: a97bba0c65c61c211cf9e361e7091343a2c6416f
Summary:
Changelog: [Internal]
Working towards removing configure.py, switch to invoking CMake directly.
Note that with this change, ninja is no longer a requirement, since it will use the default build system on the host.
Reviewed By: cortinico, jpporto
Differential Revision: D35342731
fbshipit-source-id: f04a367bda9fb22642f17e7c2c5cf493e44013d3
Summary:
It is not necessary to call node via yarn. Instead with this commit node is called directly (windows aware). This enables builds on systems that don't have yarn installed.
Fixes https://github.com/facebook/react-native/issues/33525
## Changelog
[Android] [Fixed] - Don't require yarn for codegen tasks
Pull Request resolved: https://github.com/facebook/react-native/pull/33530
Test Plan:
1. react-native init test
2. cd test
3. enable newArchEnabled=true (gradle.properties)
4. enable enableHermes: true (build.gradle)
5. react-native run-android (when the yarn is not installed on the system)
(I have not tested or verified if this works on windows build machines)
Reviewed By: sshic
Differential Revision: D35279376
Pulled By: cortinico
fbshipit-source-id: 430e4a7bcdec7d5377efac747f6b935d634451cc
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:
Other jobs in the React Native Circle config use underscores as the delimiter, so let's standardize on that.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35301098
fbshipit-source-id: 4c720db44faa8c42dece9dccc592b53330d42cc4
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:
When Hermes is used, and if it is built from source on Circle CI, the macos executors can run out of storage space.
Earlier, we solved this issue in the iOS unit test jobs by splitting them into build/test pairs. In the case of test_ios_rntester, there is no convenient way to split the job.
Since test_ios_rntester does not require the use of the iOS simulator, we can go ahead and delete it from the image at run time in order to free up some space and allow the job to finish when Hermes is built from source.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35297994
fbshipit-source-id: a0cddba2fc2900813fecc63eaf23d53e5b8f6e92
Summary:
Split test_ios job into build_ios and test_ios_unit. This allows us to build Hermes from source in `build_ios`, and to subsequently run unit tests in `test_ios_unit` in a fresh macOS machine. Otherwise, the Circle CI machine may run out of space when building the RNTester app.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35295708
fbshipit-source-id: 16833dfec517f6237d125f3e06ec1efa3f967b08
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:
In preparation for the upcoming migration towards using Hermes by default, Circle CI jobs will only test using Hermes. With this, we no longer have a matrix where test_ios runs once with JSC and once with Hermes. Instead, there is a single `test_ios_unit` job that runs with Hermes.
This change is necessary in order to avoid unnecessary complex Circle CI config files in the JSC->Hermes transition.
The CocoaPods cache key needs to be updated to avoid using a stale cache. Keys v4-pods and v5-pods were used during tests and may already be present in the Circle CI cache for the next two weeks, so we must skip ahead to v6-pods-*
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35299690
fbshipit-source-id: 96c146c8b114c3874c64a8d7b6721c90acac0c33
Summary:
ModuleDataCleaner.cleanDataFromModules(**ReactContext**) is just like ModuleDataCleaner.cleanDataFromModules(**CatalystInstance**). However, one key difference is that this new method is bridgeless mode compatible. CatalystInstance doesn't exist in bridgeless mode.
Changelog: [Android][Added] Introduce ModuleDataCleaner.cleanDataFromModules(ReactContext)
Reviewed By: sshic
Differential Revision: D35286939
fbshipit-source-id: 1c09a3b34add88f848eab43b42b39ab624f0818b
Summary:
## Rationale
The CatalystInstance exposes a public API that returns a list of all instantiated NativeModules: [CatalystInstance.getNativeModules()](https://www.internalfb.com/code/fbsource/[d9cd2e5dd41fc3e3022bfb777c8b31c92af8c537]/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/bridge/CatalystInstance.java?lines=73).
This enables a use-case: process all NativeModules that conform to a particular interface, to, for example, remove sensitive data before logging out.
## Changes
This diff moves that CatalystInstance.getNativeModules() API into the ReactContext. This allows us to migrate NativeModules leveraging this use-case off of ReactContext.getCatalystInstance(), which makes them bridgeless-mode compatible.
Changelog: [Android][Added] Introduce ReactContext.getNativeModules()
Reviewed By: sshic
Differential Revision: D35286940
fbshipit-source-id: 1b64351aa3f65ee59e6438a7a95974e219ccc69c
Summary:
Update C++ TurboModule codegen to wrap nullable types in `std::optional` whereas before the conversion would cause a crash.
Changelog:
Internal
Reviewed By: mdvacca, nlutsenko
Differential Revision: D35299708
fbshipit-source-id: 7daa50fe8b16879c5b3a55a633aa3f724dc5be30
Summary:
Use Circle CI's new generation macOS resource class in all iOS and macOS jobs. This resource provides additional resources and should reduce execution time in our iOS and macOS jobs by about 40-50%.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35294738
fbshipit-source-id: 817a8f80e774a11d23d9466d938064ac41625256
Summary:
Use Circle CI's "xlarge" resource class in all Android jobs. This resource provides additional resources and should reduce execution time in our Android jobs.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35294718
fbshipit-source-id: 53a0df2926011b5ac75b2671733a1b1f881150fd
Summary:
Use Circle CI's "xlarge" resource class in all Node jobs. This resource provides additional resources and should reduce execution time in our Node jobs.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35294648
fbshipit-source-id: cfc175b4b327ca02d7094688f870cfea757915e6
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
Danilo Bürger
Simek
Nicola Corti
Vincent Riemer
Arushi Kesarwani
Simen Bekkhus
matinzd
Lorenzo Sciandra
Paige Sun
Keion Anvaripour
George Zahariev
Phillip Pan
Sam Goldman
Christoph Purrer
Chris Olszewski
Pieter De Baets
Neil Dhar
Scott Kyle
Riccardo Cipolleschi
Héctor Ramos
John Porto
Ramanpreet Nara
