Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45630
removeOutstandingSurfacesOnDestruction is safe to fully release, we are deleting the flag
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D60142272
fbshipit-source-id: 5e7470d52cfc964b72f0cec7224a234ce9e6c2c4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45422
When `ReactNativeFeatureFlags.setAndroidLayoutDirection()` is set, we assume in components like ReactHorizontalScrolView that the Yoga contextual layout direction has been set on the underlying component, and skip using I18nManager global direction.
These native views are also used in Paper, so we need to make the change there as well to avoid regressions.
This change mechanically ports the change from Fabric to Paper, at the same layer as used in Fabric (applying ShadowNode layout to the Android view tree).
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D59708408
fbshipit-source-id: 52d6fa80c102250eae7ccccedd7184569f6a727f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45753
Let's turn this off, for clients where the feature flag isn't wired to a config, until the issue with `removeClippedSubviews` is resolved.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D60273063
fbshipit-source-id: 6302a7e1f204459ec7f5cbdb26a521e07e023458
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45690
ViewManager layer often uses `YogaConstants.UNDEFINED` (`NaN`) as null-state value. Teaching PixelUtil how to handle `NaN` values makes glue code around easier. I think this technically isn't needed, since the resultant operations would become `NaN`, but it seems like poor form/hard to reason about to propagate NaN into arithmetic or library functions.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D60265329
fbshipit-source-id: b2f4abaefb30ebd58c2644d072bb7e5bc4b3ee7b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45691
1. Add some accessors, so we can keep accessors and setters symetric
2. Use the shared BorderStyle enum added in last diff
3. Fix some missing invalidation on setting style
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D60252276
fbshipit-source-id: 3dde6ad5926f109cefc7247da4ba1894694b1867
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45687
This adds some more enums and data classes to encapsulate style values we are working with for border/background rendering. Right now, a lot of these are passed around as strings, or raw ints (of differing ordinals). These will be used as the public API of `BackgroundStyleApplicator` up the stack.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D60252277
fbshipit-source-id: 0f8001869421ffffae9727c7904bf5e395505c08
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45685
We built these to be able to parse web style string values, but the types only allow object form, and the TypeScript type is wrong.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D60263730
fbshipit-source-id: 7a6e93924a92e8e62346645cb4f8ab1a37dca34f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45722
Splitting the ReactImageView convertion to another file, to see if this is causing further failures.
Changelog:
[Internal] [Changed] - Convert ReactImageManager to Kotlin
Reviewed By: rshest
Differential Revision: D60285050
fbshipit-source-id: 68415782a40c1eacf4e67fbdd2d70c962c0600c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45711
Migrating this package in one go is proving harder than expected.
Let's split this through in smaller parts: I'm first marking the package as nullsafe.
Changelog:
[Internal] [Changed] - Make `com.facebook.react.views.image` nullsafe
Reviewed By: cipolleschi
Differential Revision: D60282604
fbshipit-source-id: 68879142a88bdc3c837dff91e53c5f5e891773f9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45683
Changelog: [Internal]
this did not make any meaningful progress, let's clean it up and revisit it later.
Reviewed By: fkgozali
Differential Revision: D60219828
fbshipit-source-id: 89a283d7c572dfcd6ef16472e81f3dce1c2cd284
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45706
## Context
Running manual tests when preparing a release, it's time consuming.
We have to do the cherry picks, wait for CI to finish, and then manually test 8 configurations.
Maestro is a tool that allow us to run E2E tests automatically, and we can wire it to CI.
## Change
To avoid flakyness and costs, let's run E2E tests only on main and on stable branches
Changelog:
[Internal] - Exploration to integrate maestro
Reviewed By: blakef
Differential Revision: D60283204
fbshipit-source-id: 806cb8905cb269f18785158dcc5777ef10e0ef44
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45710
## Context
Running manual tests when preparing a release, it's time consuming.
We have to do the cherry picks, wait for CI to finish, and then manually test 8 configurations.
Maestro is a tool that allow us to run E2E tests automatically, and we can wire it to CI.
## Change
Add job to create a new Android app from the template and run maestro test on it
Changelog:
[Internal] - Exploration to integrate maestro
Reviewed By: cortinico
Differential Revision: D60282836
fbshipit-source-id: 0c3b4c1bbacfd6c8695f987c86b7e615a3cef026
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45703
## Context
Running manual tests when preparing a release, it's time consuming.
We have to do the cherry picks, wait for CI to finish, and then manually test 8 configurations.
Maestro is a tool that allow us to run E2E tests automatically, and we can wire it to CI.
## Change
Add job to create a new iOS app from the template and run maestro test on it
Changelog:
[Internal] - Exploration to integrate maestro
Reviewed By: blakef
Differential Revision: D60282811
fbshipit-source-id: 2a1dcb1de09795bd0323357455e98a7fa379a2e7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45713
## Context
Running manual tests when preparing a release, it's time consuming.
We have to do the cherry picks, wait for CI to finish, and then manually test 8 configurations.
Maestro is a tool that allow us to run E2E tests automatically, and we can wire it to CI.
## Change
Add Maestro flow for a new app created from the template
Changelog:
[Internal] - Exploration to integrate maestro
Reviewed By: blakef
Differential Revision: D60282783
fbshipit-source-id: 0aa7f3fae4f5bf31518e02ddc56ca2d4fac4dfa3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45709
## Context
Running manual tests when preparing a release, it's time consuming.
We have to do the cherry picks, wait for CI to finish, and then manually test 8 configurations.
Maestro is a tool that allow us to run E2E tests automatically, and we can wire it to CI.
## Change
Connect RNTester Android to Maestro action
Changelog:
[Internal] - Exploration to integrate maestro
Reviewed By: blakef
Differential Revision: D60282769
fbshipit-source-id: 2a20f1cb249fc5c43b0579c3309efd60369a1da6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45707
## Context
Running manual tests when preparing a release, it's time consuming.
We have to do the cherry picks, wait for CI to finish, and then manually test 8 configurations.
Maestro is a tool that allow us to run E2E tests automatically, and we can wire it to CI.
## Change
Create a github action to run Maestro on Android
Changelog:
[Internal] - Exploration to integrate maestro
Reviewed By: cortinico, blakef
Differential Revision: D60282719
fbshipit-source-id: 9544eea192894696361fada1e519caad35f74154
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45705
## Context
Running manual tests when preparing a release, it's time consuming.
We have to do the cherry picks, wait for CI to finish, and then manually test 8 configurations.
Maestro is a tool that allow us to run E2E tests automatically, and we can wire it to CI.
## Change
Wire RNTester to the Maestro Action
Changelog:
[Internal] - Exploration to integrate maestro
Reviewed By: blakef
Differential Revision: D60282689
fbshipit-source-id: 51c624c2acf7a27ed5527e7453d9a04678df6c66
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45704
## Context
Running manual tests when preparing a release, it's time consuming.
We have to do the cherry picks, wait for CI to finish, and then manually test 8 configurations.
Maestro is a tool that allow us to run E2E tests automatically, and we can wire it to CI.
## Change
Create a reusable GHA to run Maestro tests on iOS
Changelog:
[Internal] - Exploration to integrate maestro
Reviewed By: blakef
Differential Revision: D60282657
fbshipit-source-id: 3a2a427f0954b46fc6c3a8bf753e807371eb0239
Summary:
## Context
Running manual tests when preparing a release, it's time consuming.
We have to do the cherry picks, wait for CI to finish, and then manually test 8 configurations.
Maestro is a tool that allow us to run E2E tests automatically, and we can wire it to CI.
## Change
Add a test flow for RNTester
## Changelog:
[Internal] - Exploration to integrate maestro
Pull Request resolved: https://github.com/facebook/react-native/pull/45574
Test Plan: GHA
Reviewed By: blakef
Differential Revision: D60282147
Pulled By: cipolleschi
fbshipit-source-id: 4ecba84f0b2c7186de2bb9938043e73a0bd9a6bd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45735
This merges several 2 external libraries from .so to be included inside
libappmodules.so.
Changelog:
[Internal] [Changed] - Move react_codegen_* libraries for RNTester to OBJECT
Reviewed By: rozele, rshest
Differential Revision: D60290806
fbshipit-source-id: 6bfa40995d7538e075819d916e8a204464edb75b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45727
All instances mirror types which are already defined in the platform-independent base module. See snapshot changes.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D60286148
fbshipit-source-id: 30665252ff5e449a2c10ff3a3e76d9337daecb80
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45640
Other two libraries that don't need to be dynamic libraries but can just be exposed via libreactnative.so
Changelog:
[Internal] [Changed] - Move react_featureflags and react_render_consistency inside libreactnative.so
Reviewed By: cipolleschi
Differential Revision: D55796945
fbshipit-source-id: be40b1523a560b2783fc7b6312326e20dc8cf595
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43909
As we're moving towards a single `libreactnative.so` file, we need to remove several of our prefab targets. Here I'm cleaning up those that are not having an OnLoad.cpp file which needs to be loaded from SoLoader.
This is breaking for libraries using native dependencies via Prefab (i.e. search for `ReactAndroid::` in CMakeLists.txt files for your project).
If so, the CMakeLists.txt files should be updated as follows:
```diff
- ReactAndroid::react_render_debug
+ ReactAndroid::reactnative
```
This applies to every prefab dependencies (the example is just for `react_render_debug`
Changelog:
[General] [Breaking] - Remove several libs from default App CMake setup
Reviewed By: cipolleschi
Differential Revision: D55751683
fbshipit-source-id: 3aca7897852b5f323d60ede3c5036cae2f81e6c3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43908
This creates a new dynamic library that we want to be the only .so that is loaded from apps/libraries.
Changelog:
[Internal] [Changed] - Create the libreactnative.so dependency
Reviewed By: cipolleschi
Differential Revision: D55751682
fbshipit-source-id: 50f4167dc2f9953a8673b28dba3357e19fe88d6b
Summary:
https://github.com/facebook/react-native/issues/45596
Migrated all the assertions to use `assertThat()` function from AssertJ.
Also updated the `prepareBoostTask_withMissingConfiguration_fails` test to use `assertThatThrownBy` to check if the tested task throws a given exception.
## Changelog:
Migrate tests to assertj in these files:
- `packages/gradle-plugin/react-native-gradle-plugin/src/test/kotlin/com/facebook/react/tasks/internal/PrepareBoostTaskTest.kt`
[INTERNAL] [CHANGED] - Migrated PrepareBoostTaskTest from junit.Assert to assertj.core.api.Assertions.
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/45718
Test Plan:
All tests pass when `./gradlew -p packages/gradle-plugin test` command is ran.
<img width="454" alt="image" src="https://github.com/user-attachments/assets/9e954f7b-2208-48a9-ae15-ab642252e6da">
Reviewed By: GijsWeterings
Differential Revision: D60284566
Pulled By: cortinico
fbshipit-source-id: 11af0a0ca574f935e6aab3a7855b5daaeab1a718
