Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49817
changelog: [internal]
Remove feature flag excludeYogaFromRawProps. It did not yield any performance wins and the code to support the feature is spread across multiple classes. Removal simplifies complexity.
Reviewed By: javache
Differential Revision: D70389071
fbshipit-source-id: 21751f56aec8de501ff1e1efafda035069d8ef48
Summary:
Migrate com.facebook.react.uimanager.layoutanimation.OpacityAnimation to Kotlin.
I moved out `OpacityAnimationListener` as well in this PR to separate concerns and align more with the codebase.
## Changelog:
[INTERNAL] - Migrate com.facebook.react.uimanager.layoutanimation.OpacityAnimation to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/49822
Test Plan:
```bash
yarn test-android
yarn android
```
Reviewed By: javache
Differential Revision: D70588884
Pulled By: alanleedev
fbshipit-source-id: 1b70f5e5facd5f47b828090e7c63a218229000cb
Summary:
When using the `login-password` prompt type, there is a TypeScript type mismatch issue. The `callbackOrButtons` parameter returns an object with `{login: string, password: string}` structure, but this type variation is not properly included in the **AlertType** type definition. This causes TypeScript to show type errors when using callback functions that expect credentials in the format `(credentials: {login: string, password: string}) => void`.
## Changelog:
- [General] [Fixed] Add missing type variation `{login: string, password: string}` to **AlertType** type definition to properly support `login-password` prompt callbacks
Pull Request resolved: https://github.com/facebook/react-native/pull/49757
Test Plan: This change is purely type-related and doesn't affect runtime behavior.
Reviewed By: NickGerleman
Differential Revision: D70797036
Pulled By: alanleedev
fbshipit-source-id: 8e27a39f0c8f49083730c683b41b69173715bd68
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49927
This change automates updating App's Info.plist with the new `RCTNewArchEnabled` boolean entry. The value depends on how the pod install is set up. In this way, we maintain the previous UX to enable/disable the New Arch.
## Context
The RCT_NEW_ARCH_ENABLE flag is a compile time flag we used for almost two years to configure the iOS apps and to determine whether the app should build with the New Arch or not.
However, given that we are looking into prebuilding React Native, we have to get rid of all the compilation flags, because they would require us to prebuild a combinatorial number of artifacts for react native. For example:
- New Arch / Hermes
- Old Arch / Hermes
- New Arch / JSC
- Old Arch / JSC
- ...
## Backward compatibility
We are going to keep adding the RCT_NEW_ARCH_ENABLED flag in all the dependencies, through the cocoapods inrastructure, so libraries, which are not prebuilt, will be build for the right architecture by the app itself.
## Changelog:
[iOS][Added] -
Reviewed By: cortinico
Differential Revision: D70888212
fbshipit-source-id: 541a818e02ccb96c822de29b0714646d1e69a5a9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49924
This change deprecates the RCT_NEW_ARCH_ENABLEd flag to toggle the New Architecture.
The new approach bring iOS closer to Android: to diasable the New Architecture, user needs to modify the App's Info.plist and add a `RCTNewArchEnabled` boolean entry and set it to `NO`.
The absence of the entry implies that the New Arch is enabled. (Defaults to enabled)
This also deprecates the `RCTSetNewArchEnabled` function because it makes no sense now
## Context
The RCT_NEW_ARCH_ENABLE flag is a compile time flag we used for almost two years to configure the iOS apps and to determine whether the app should build with the New Arch or not.
However, given that we are looking into prebuilding React Native, we have to get rid of all the compilation flags, because they would require us to prebuild a combinatorial number of artifacts for react native. For example:
- New Arch / Hermes
- Old Arch / Hermes
- New Arch / JSC
- Old Arch / JSC
- ...
## Backward compatibility
We are going to keep adding the RCT_NEW_ARCH_ENABLED flag in all the dependencies, through the cocoapods inrastructure, so libraries, which are not prebuilt, will be build for the right architecture by the app itself.
## Changelog:
[iOS][Deprecated] - deprecate the `RCT_NEW_ARCH_ENABLED` and the `RCTSetNewArchEnabled`
Reviewed By: cortinico
Differential Revision: D70885454
fbshipit-source-id: 4b8404ead4900d9787049ebd0b8b3c29b272f913
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49929
X-link: https://github.com/facebook/metro/pull/1459
In the next version of Flow, we will stop bundling many of the builtin libdefs, and they have been moved to flow-typed. This diff checks in them to prepare for the deployment of the next version of Flow.
Changelog: [Internal]
Reviewed By: SamChou19815
Differential Revision: D70896122
fbshipit-source-id: aa6bd0b1e653b983a345b0e202c8dad5058a0001
Summary:
GHA passes the version to the script with a `v` prefix. However, when we receive the version from NPM, the `v` prefix is not here.
We can fix the script by dropping the `v` when it is passed to the function.
bypass-github-export-checks
## Changelog:
[Internal] - Fix verifyPackageOnNPM
Pull Request resolved: https://github.com/facebook/react-native/pull/49944
Test Plan: GHA
Reviewed By: cortinico, fabriziocucci
Differential Revision: D70960414
Pulled By: cipolleschi
fbshipit-source-id: 4234103ebe49cf715aea4a1473a8a60978f07a9f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49936
Ensure LegacyArchitectureLogger.assertWhenLegacyArchitectureMinifyingEnabled is called only once per class loading in kotlin
changelog: [internal] internal
Reviewed By: alanleedev
Differential Revision: D70922132
fbshipit-source-id: ce4d68dc2ab0f61266e4bb5cddfc175c364f568a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49938
Recycling a `ReactViewGroup` will lead to all child views being removed from the view. To avoid having view recycling corrupt the clipping state set for the child views, ahead of base view recycling preparation this diff disables `removeClippedSubviews` so that layout changes don't run over all child views that will end up being removed anyway.
The bug reported earlier should already have been resolved by D70672120 since the view recycling of a child view would remove the view from the parent. Meaning the ReactViewGroup can only have subviews that are not prepared for recycling, any recycled view would have been removed from their parent (the ReactViewGroup)
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D70921641
fbshipit-source-id: a8b311169b268c09400d2b62008184e379f6fe79
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49934
The typing of internal version of jest and the libdef in react-native has diverged a bit. This diff aligns the typing for `describe`
Changelog: [Internal]
Reviewed By: gkz
Differential Revision: D70917375
fbshipit-source-id: 9c2ab98a08394aa187712f4966748a8a60e202b1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49900
This appears to fix an issue where removing a sibling with zIndex breaks drawing of the next sibling. The theory is that eager return in `onViewRemoved` prevents the view from reverting into a state where it no longer uses custom draw order. However, tracing back history, this eager return was [added](https://github.com/facebook/react-native/pull/43389) to fix a bug in Reanimated. cc bartlomiejbloniarz to confirm if [this Reanimated issue](https://github.com/software-mansion/react-native-reanimated/issues/5715) resurfaces from this change.
Fixes#49838
## Changelog
[Android][Fixed] Fixes issue with z-indexed sibling removal
Reviewed By: NickGerleman, cipolleschi
Differential Revision: D70795631
fbshipit-source-id: 500af92226be29af73f36f911ffff27a0c083ae9
Summary:
Currently, when integrating into a native app using ReactNativeFactory, when we forget to set `dependencyProvider` we get a random crash exception instructing us (depending on native modules in our app) about an unrecognized selector:

After this change we get a proper error informing us that we for got to set dependencyProvider:

## Changelog:
[IOS] [ADDED] - Useful error message about setting dependency provider
Pull Request resolved: https://github.com/facebook/react-native/pull/49843
Test Plan: CI Green
Reviewed By: cortinico
Differential Revision: D70631515
Pulled By: cipolleschi
fbshipit-source-id: d99c8fa12fdb0624a01fe16c50fe0f2d10554f94
Summary:
Migrate com.facebook.react.bridge JavaScriptContextHolder & JavaScriptExecutor to Kotlin.
In this PR I also marked the return of HermesExecutor.initHybridDefaultConfig as non-nullable to keep the conversion without logic changes. I checked that this was changed unintentionally to nullable in 12e321daf0 but I think it was not supposed to be.
## Changelog:
[INTERNAL] - Migrate com.facebook.react.bridge JavaScriptContextHolder & JavaScriptExecutor to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/49909
Test Plan:
```bash
yarn test-android
yarn android
```
Reviewed By: javache
Differential Revision: D70871012
Pulled By: Abbondanzo
fbshipit-source-id: 1c15927056baf166e520e896e92bebf664fa0229
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49931
This change fixes the app startup in the Old Architecture by implementing the loadSourceForBridge:onProgress:onComplete method in the RCTDefaultReactNativeFactoryDelegate object.
The method was missing here, so the Bridge was never trying to load the JS bundle from Metro, resulting in an empty app.
## Changelog:
[iOS][Fixed] - Implement the loadSourceForBridge:onProgress:onComplete in the RCTDefaultReactNativeFactoryDelegate.
Reviewed By: cortinico
Differential Revision: D70898811
fbshipit-source-id: 3e5d519a1965e92ace91ca6d5b316a9069279448
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49906
Task.call is equivalent to a try-catch and wrapping the result in a Task. Inlining this is cheaper than creating a TaskCompletionSource and a Runnable.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D70803554
fbshipit-source-id: 0886176be974eff67c983ce1475ad685a8021b14
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49926
Those files can be fully removed as it's not referenced at all in OSS/Internal
Changelog:
[Internal] [Changed] -
Reviewed By: fabriziocucci
Differential Revision: D70888664
fbshipit-source-id: 4cacc449aa141e0465f771bf8c52d573d4227ef5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49922
Spamming the DB with "heartbeat" events with close to 0 ping didn't give us any useful information. Instead, report high ping situations.
Changelog:
[General][Internal] Remove reporting all device and debugger heartbeat events, only report heartbeats with high round trip latency
Reviewed By: GijsWeterings
Differential Revision: D70707457
fbshipit-source-id: 6bc8a55fd32dfa60fb4f7764ac00a6218417dcb5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49907
These tests have been disabled for a while due to feature flags being introduced, fusebox flags with native dependencies, and the removal of Powermock.
Changelog: [Internal]
Reviewed By: Abbondanzo
Differential Revision: D70803553
fbshipit-source-id: d1ae6e4ca6c0d22e6a8c89bf01b28333929fa8a6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49912
Changelog: [internal]
This migrates all Fantom tests to use package-relative imports from `react-native` instead of relative paths.
Note that a lot of the current deep imports (e.g.: `import ReactNativeElement from 'react-native/src/private/webapis/dom/nodes/ReactNativeElement'`) will not be necessary when we release those APIs as public.
Reviewed By: sammy-SC
Differential Revision: D70779722
fbshipit-source-id: f0d28e00ca9881dc2a3cd151b75327b26711277e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49911
Changelog: [internal]
The approach in Fantom tests is to use the public API as much as we can, but forcing us to use relative imports in tests makes it harder to see what's the public API and what's not. This disables the lint rule so we can use package imports in Fantom tests without warnings/errors.
Reviewed By: sammy-SC
Differential Revision: D70779721
fbshipit-source-id: b244e6a36060e6bc60318fe285ffcf3a81a78acd
Summary:
- Update ignore micromatch pattern to filter out `__test_fixtures__` from build output
- Remove `babel/plugin-transform-object-rest-spread`
- Remove `babel/plugin-transform-async-to-generator`
- Remove `babel/plugin-transform-destructuring`
The `package.json:engines:node` field is already set to `>=18` which makes the three Babel transforms that were removed redundant.
## Changelog:
[INTERNAL] [CHANGED] - Remove fixtures files and outdated Babel transforms from `react-native/codegen` build output
Pull Request resolved: https://github.com/facebook/react-native/pull/49916
Test Plan: - Ran against Node 18
Reviewed By: robhogan
Differential Revision: D70885090
Pulled By: cortinico
fbshipit-source-id: 328b75a6031a7ca6a9b3ed170061ffb0a47d6d93
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49898
Changelog: [internal]
In the method to access the native node reference from elements, we weren't considering the case where the element is the `documentElement`, which is a special case we were handling correctly in the case of native node references from nodes (where we also handle it possibly being a document node).
Because of this, methods in `Element` and `ReactNativeElement` weren't working correctly on the `documentElement`. We didn't catch this initially because we only tested the traversal methods defined in node in the test for `ReactNativeDocument`.
This fixes the issue.
Reviewed By: javache
Differential Revision: D70792748
fbshipit-source-id: c42d05a066efaffccade94e9d3835fb7172e2335
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49896
This change makes possible to opt-out from the New Architecture.
Env variables are always `string`s in ruby and the check was always failing because it was comparing it with a number (always false)
## Changelog:
[iOS][Fixed] - enable back the opt-out from the New Architecture
Reviewed By: cortinico
Differential Revision: D70789827
fbshipit-source-id: 7d3f96c3db22f2715dec2b649534b20e3273ea3e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49860
changelog: [internal]
now that Fantom supports tests with <Modal />, add a test to cover scenario where <ScrollView /> is inside of <Modal />.
Reviewed By: rubennorte, rshest
Differential Revision: D70696834
fbshipit-source-id: 5f51917ac5c6a2cf451906e302ee2b62c15449ea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49859
changelog: [internal]
this will be used for testing purposes in Fantom.
This diff also cleans up `ModalInjection.js` which is unused.
Reviewed By: rubennorte
Differential Revision: D69883384
fbshipit-source-id: 4ff278ef174c95fd5a93f70519f14c5190a5ada5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49894
Update `babel` entries in `yarn.lock` and run:
`yarn update-babel-flow-lib-defs`
...from Metro, to regenerate our Flow definitions from Babel source, then sync to RN.
Changelog: [Internal]
Facebook
D70778791 updated some `xplat/js/yarn.lock` Babel entries, which caused `xplat/js/tools/metro/scripts/__tests__/babel-lib-defs-test.js` to start failing only when Yarn had *not* been run in `xplat/js/tools/metro`, because the hoisted `xplat/js` Babel deps were a greater version than the locked `xplat/js/tools/metro` Babel deps.
This realigns them and updates the types to unbreak the test both internally an in OSS.
Reviewed By: vzaidman
Differential Revision: D70785807
fbshipit-source-id: 59ee8adc296f9ca155dde04c1429273656a26244
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49895
Minor thing, but the fact that these fixture `package.json`s for testing a release script reference real Metro packages and versions always trips me up when I'm updating Metro (grepping, etc).
There's no need for them to mention Metro - any non-RN package is sufficient to test that the script preserves other dependencies. This swaps them for dummy packages.
Changelog: [Internal]
Reviewed By: vzaidman
Differential Revision: D70789598
fbshipit-source-id: 32f394bf1f783534b76d260908538d7b5716ef1f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/49885
Updates all `metro*` dependencies to the latest `^0.82.0`.
The breaking changes in this release apply only to frameworks and integrators.
This update brings `package.json#exports` resolution enabled by default, and lazy hashing for much faster Metro startup.
Release notes:
https://github.com/facebook/metro/releases/tag/v0.82.0
Changelog:
[General][Changed] Update Metro to ^0.82.0
Reviewed By: vzaidman
Differential Revision: D70778791
fbshipit-source-id: ffb55ed384d721205aa4d7f528c63c0b0a38abc5
Summary:
acquireWakeLockNow was static before but wasn't marked as static in https://github.com/facebook/react-native/commit/9afad527b831ec0c5d50e88daacbaacbc476d478 when changing code to Kotlin.
This breaks react-native-firebase but I've submitted the bug report there as I guess it might be fixed there too.
## Changelog:
[ANDROID] [FIXED] - Marked acquireWakeLockNow as static
Pull Request resolved: https://github.com/facebook/react-native/pull/49875
Test Plan: No tests as it reverts the broken change
Reviewed By: rshest
Differential Revision: D70773675
Pulled By: javache
fbshipit-source-id: d7363702dfec078b7e6d2693d05b8ab87e818522
Summary:
This PR adds a step in CI to sign the xcframework if we have a certificate available
bypass-github-export-checks
## Changelog:
[Internal] - Sign XCFrameworks in CI
Pull Request resolved: https://github.com/facebook/react-native/pull/49871
Test Plan: GHA
Reviewed By: cortinico
Differential Revision: D70734340
Pulled By: cipolleschi
fbshipit-source-id: 244422bdf9a8e0a2075a727a91805f762d4f95c9