Summary:
TurboModuleRegistry export functions and not a TurboModuleRegistry object. See https://github.com/facebook/react-native/blob/main/Libraries/TurboModule/TurboModuleRegistry.js#L37
## Changelog
[GENERAL] [FIXED] - Fix TurboModuleRegistry TS type
Pull Request resolved: https://github.com/facebook/react-native/pull/35885
Test Plan:
Tested that the import doesn't generate a type error when used correctly.
```ts
import * as TurboModuleRegistry from 'react-native/Libraries/TurboModule/TurboModuleRegistry';
export default TurboModuleRegistry.get<Spec>('RNCSafeAreaContext');
```
Reviewed By: christophpurrer
Differential Revision: D42604208
Pulled By: NickGerleman
fbshipit-source-id: e6259df24aaf6e37b32cc4b51947294fd655837e
Summary:
`accessibilityLanguage` is missing from `AccessibilityPropsIOS` TypeScript interface
## Changelog
[GENERAL] [FIXED] - Added missing `accessibilityLanguage` TypeScript type
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/35882
Test Plan: Ran `yarn test-typescript` and `yarn test-typescript-offline` and there were no errors.
Reviewed By: christophpurrer
Differential Revision: D42604363
Pulled By: NickGerleman
fbshipit-source-id: fb8dd4b5bba78a080473a9dc7b49a07587530229
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35875
Fixes https://github.com/facebook/react-native/issues/35871
Nested VirtualizedLists register to their parents for updates, associated to a specfific cellKey set by VirtualizedListCellContextProvider. This cellKey is usually set when rendering a cell for a data item, but we can also render a nested VirtualizedList by putting one in a ListHeaderComponent/ListFooterComponent/ListEmptyComponent.
D6603342 (https://github.com/facebook/react-native/commit/a010a0cebd4afc0d88336c2c265a5d9dbb19918f) added cellKeys when we render from a header/footer, but not ListEmptyComponent, so that association would silently fail earlier.
D39466677 (https://github.com/facebook/react-native/commit/010da67bef0c22418d0d41b7c2eae664672a4a27) added extra invariants to child list handling, that are now triggered by this case, complaining because we are trying to unregister a child list we never successfully registered, due to a missing cellKey.
This fixes the issue by providing a cellKey for ListEmptyComponent as well.
Changelog:
[General][Fixed] - Fix invariant violation when nesting VirtualizedList inside ListEmptyComponent
Reviewed By: christophpurrer
Differential Revision: D42574462
fbshipit-source-id: f76fa795bf471cb8a929c2efdbd814ea51927663
# Conflicts:
# Libraries/Lists/VirtualizedList.js
Summary:
Removing a stale configuration that was configuring username/password before publishing to NPM. This is effectively unused + the Github Token there is invalid therefore can be removed.
## Changelog
[INTERNAL] - Remove unused .netrc file from CircleCI
Pull Request resolved: https://github.com/facebook/react-native/pull/35785
Test Plan: n/a
Reviewed By: cipolleschi
Differential Revision: D42385163
Pulled By: cortinico
fbshipit-source-id: 0dbbf44459d59f792da4221d6100800a2f4efda2
Summary:
react-native-navigation allows to register React components to be included in the navigation top bar as buttons, the way this work is by using the AppRegistry. When the ViewTreeObserver executes the `CustomGlobalLayout` we are checking for the RootWindowInsets in the `checkKeyboardEvents` which in the case for the top bar component it returns null and the **WindowInsetsCompat.toWindowInsetsCompat** function throws if the insets are null causing the app to crash.
Interestingly in the function `checkForKeyboardEventsLegacy` the null value is being checked, so I guess it was overlooked in the newer function.
## Changelog
[ANDROID] [FIXED] - Fix ReactRootView crash when root view window insets are null
Pull Request resolved: https://github.com/facebook/react-native/pull/35869
Test Plan:
The following videos show how the app crashes as soon as we attempt to pop a screen that contains a react component as a button in the navigation top bar and how it correctly pops to the previous screen after applying the fix
| Crash | Fix |
| -- | -- |
| https://user-images.githubusercontent.com/6757047/213116971-fe693989-f978-438c-b8f9-fc56f2a477c8.mp4 | https://user-images.githubusercontent.com/6757047/213118352-fe258f28-07aa-4d17-98d2-97136464ffd5.mp4 |
Reviewed By: cipolleschi
Differential Revision: D42580156
Pulled By: cortinico
fbshipit-source-id: 4dbd656d7c8148df67668a2a50913206bc35c07f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35857
It seems like there is an incompatibility between NDK 23 (shipped in 0.71)
and the usage of custom `CMAKE_BUILD_TYPE` we do for Hermes.
Specifically the `-DCMAKE_BUILD_TYPE=Release` we specify for the debug
variant of Hermes is partially ignored by the new Android native build toolchain.
See https://github.com/android/ndk/issues/463 for mentions on how the
toolchains requires CMake 3.20+
As AGP 7.3 defaults to use CMake 3.18 unless specified, and NDK 23 unless specified.
AGP 7.4 defaults to use CMake 3.22 unless specified, and NDK 23 unless specified.
See: https://developer.android.com/studio/releases/gradle-plugin#7-4-0
Here I'm:
1. Bumping the docker image to an image that contains the CMake 3.22
2. Updating the logic for building `react-native` & `hermes-engine` to use 3.22
3. Provide fallbacks if the user specified `CMAKE_VERSION`
Template tests will run on AGP 7.3 and will still use CMake 3.18, but I forecast
no problem there as the user is not supposed to specify custom `CMAKE_BUILD_TYPE`.
This is only a problem as we build `hermes-engine` with custom build types.
Changelog:
[Android] [Fixed] - Bump CMake to 3.22.1 to properly honor CMAKE_BUILD_TYPE
Reviewed By: cipolleschi
Differential Revision: D42544864
fbshipit-source-id: efd0f51120370fb808337c201df31d71f4ddfdbc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35872
When downgrading from AGP 7.4 to 7.3 we were forced to resort to older APIs
to bundle resources. It seems like we haven't properly wired the task to make sure
resources generated by Metro are correctly accounted before the generation of
release app bundles/apks.
This fixes it. This fix can also be removed once we are on AGP 7.4
Fixes#35865
Changelog:
[Android] [Fixed] - Fix for resources not correctly bundlded on release appbundles
Reviewed By: cipolleschi
Differential Revision: D42573450
fbshipit-source-id: a810924315f72e02e4c988ae86112bf0a06a9ce5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35860
I've just realized that the `--active-arch-only` is not correctly passed down
to RNGP to set up an abiFilter so users on 0.71 on New Architecture end up
building all the architectures even if `--active-arch-only` is set.
This fix makes sure the `abiFilters` is applied if the user specified
either the `--active-arch-only`, the `reactNativeArchitectures` property
and is not using the Split ABI feature.
Changelog:
[Android] [Fixed] - RNGP - Honor the --active-arch-only when configuring the NDK
Reviewed By: cipolleschi
Differential Revision: D42547987
fbshipit-source-id: 5a34e7087bb4f89de74cc52f9c505e36896fbf03
Summary:
Hi there,
While upgrading to 0.71 we realised the RCTAppDelegate doesn't offer a way to set custom `initProps` that would depend on `launchOptions`.
This PR adds an `initialProps` property to the RCTAppDelegate. This would let us set this property based on `launchOptions` in our implementation of `didFinishLaunchingWithOptions` before calling `[super didFinishLaunchingWithOptions]`
Thanks !
## Changelog
[IOS] [ADDED] - Add `initialProps` property to `RCTAppDelegate`
Pull Request resolved: https://github.com/facebook/react-native/pull/35848
Reviewed By: rshest
Differential Revision: D42543027
Pulled By: cipolleschi
fbshipit-source-id: 55374914890445f8193c12a06a943b7796edb457
Summary:
On iOS 13.0+, app may use SceneDelegate for multiple windows support or CarPlay support. RCTAlertController can't find the correct root vc in such scene based apps.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[iOS] [Fixed] - Fix RCTAlertController not showing when using SceneDelegate on iOS 13.0+.
Pull Request resolved: https://github.com/facebook/react-native/pull/35716
Reviewed By: cipolleschi
Differential Revision: D42253653
Pulled By: makovkastar
fbshipit-source-id: ae4e833abca2af7af8028f3af9bd8d3f60ebd392
Summary:
Enhancing native iOS modules and preventing crashes inside the RCTAlertController
## Changelog
[iOS][Fixed] - Handle properly a `nil` `keyWindows` in the AlertController
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/35689
Reviewed By: cipolleschi
Differential Revision: D42179169
Pulled By: ryancat
fbshipit-source-id: 05a6788f610db1d222e3c10b3c774c75edaf55f5
Summary:
When inheriting `RCTAppDelegate` in a module with swift code, the compiler will have a build error when it goes through module headers. because swift does not support cxx headers. we found this issue when we try to inherit the class at Expo's [`EXAppDelegateWrapper`](https://github.com/expo/expo/blob/main/packages/expo-modules-core/ios/AppDelegates/EXAppDelegateWrapper.h) with RCTAppDelegate in new architecture mode.
## Changelog
[IOS][FIXED] - Fix build errors when inheriting RCTAppDelegate in Swift modules
Pull Request resolved: https://github.com/facebook/react-native/pull/35661
Test Plan:
- ci passed
- tested with expo's setup: https://github.com/expo/expo/pull/20470
Reviewed By: rshest
Differential Revision: D42293851
Pulled By: cipolleschi
fbshipit-source-id: 8a173279db070cc0008c6f8214093951f504dcc1
Summary:
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Fixed] - fixed typo in template build.gradle
Pull Request resolved: https://github.com/facebook/react-native/pull/35209
Reviewed By: cipolleschi
Differential Revision: D41080347
Pulled By: cortinico
fbshipit-source-id: d2e36f232f798a636f98843edbc5651730125fc4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35679
The Codegen cleanup step was not always working due to an issue with the codegen folder path. It was working for RNTester, but not for apps created from the Template.
## Changelog:
[iOS][Fixed] - Fix path issue to properly run the codegen cleanup step
Reviewed By: jacdebug
Differential Revision: D42137600
fbshipit-source-id: ba4cb03d4c6eb17fda70a4aff383908d2e468429
Summary:
This PR introduce an automatic way to detect whether the user sets its podfile to use frameworks.
In this way, users don't have to install pods with a specific environment flag but they can rely on the standard Cocoapods usage
## Changelog
[IOS][ADDED] - Automatically detect whether use_frameworks! is used
Pull Request resolved: https://github.com/facebook/react-native/pull/35636
Test Plan:
- CircleCI is Green
- Added unit tests
- Tested locally with an app
Reviewed By: dmytrorykun
Differential Revision: D42029355
Pulled By: cipolleschi
fbshipit-source-id: 76c92133deabbda59603b043a4d542737f10f044
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35672
While working on some example, I discovered that the helper function `install_module_dependencies` was not adding the proper `-DRCT_NEW_ARCH_ENABLED=1` flag to the compiler flags.
## Changelog:
[iOS][Fixed] - Make sure to add the New Arch flag to libraries
Reviewed By: jacdebug
Differential Revision: D42131287
fbshipit-source-id: 68c492150ba4e4a2ec726b3e8b8a9c7842b543bc
Summary:
This PR adds a safety check in case the Cocoapod build script is not able to clean the build folder.
We had evidences where this process failed, and in this way the user has a clear and actionable message to fix its situation.
## Changelog
[iOS][Added] - Add message with instructions about what to do if the cleanup of the build folder fails.
Pull Request resolved: https://github.com/facebook/react-native/pull/35642
Test Plan:
I was not able to reproduce the issue locally.
The fix is not destructive, let's see if the amount of issues decreases.
Reviewed By: dmytrorykun
Differential Revision: D42067939
Pulled By: cipolleschi
fbshipit-source-id: 433dbfaec42a1bf460dc9a48051aa51ec6e12d16
Summary:
This fixes some style errors found by dtslint, along with some test cases for StyleSheet.compose() where the recent change made it slightly too permissive when explicit return types are given. I also added runs of the TS tests to a script which runs in sandcastle so we can catch this at diff-submission time in the future.
Changelog:
[General][Fixed] - Fix Errors with TypeScript Tests
Reviewed By: lunaleaps
Differential Revision: D42085257
fbshipit-source-id: 7e6ca49d3c3aef822c61c97ecc07b55b0a949d51
Summary:
Adds some imperative VirtualizedList methods to the TS types which are documented on the website and are public enough. Also explicitly add `viewOffset` to `scrollToItem` since `scrollToItem` params are indefinite in flow and are passed to `scrollToIndex` (which supports the prop).
Changelog:
[General][Fixed] - Add missing VirtualizedList Imperative Types
Reviewed By: GijsWeterings
Differential Revision: D42047674
fbshipit-source-id: 60f7b35b049853d9fcb724918b3a0008a75ea573
Summary:
These are all documented on the website and seem to likely work in OSS to at least some extent. Add the missing types corresponding to functions exported from AppRegistry.
Changelog:
[General][Fixed] - Add missing types for AppRegistry
Reviewed By: GijsWeterings
Differential Revision: D42036018
fbshipit-source-id: 0728d6c5602a50e50f1eaf7f76c54ab47dcb0124
Summary:
This is exported from the RN entrypoint and documented on the RN website, so we should give types for it.
Changelog:
[General][Fixed] - Add type for RootTagContext
Reviewed By: christophpurrer
Differential Revision: D42040806
fbshipit-source-id: cb8cdf557098ddbe33c143b7ab5d80bda7f80a6e