Summary:
`UIMenuController` is deprecated as of iOS 16. https://github.com/facebook/react-native/commit/e08a1973f67d85acc157111c749c43572469e4c2 migrated a usage into an `available` check. However, it does not properly fall back to the deprecated API in the "else" block of the availability check, instead it uses an early return. It seems this means Xcode still sees the API as used, and spits out a deprecated warning. Let's just refactor the code so we don't have that anymore.
## Changelog:
[IOS] [FIXED] - Remove an early return to suppress a deprecated API warning for `UIMenuController`
Pull Request resolved: https://github.com/facebook/react-native/pull/42277
Test Plan: CI should pass.
Reviewed By: cipolleschi
Differential Revision: D52785488
Pulled By: sammy-SC
fbshipit-source-id: 0b47e8aa8d7c94728e3d68332fbb8f97f8ded34e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42328
This method was deprecated in 0.72. We're going to remove it in 0.74
Technically a breaking change, but users should not be using this method at all at this point.
Changelog:
[Android] [Removed] - Remove deprecated DefaultNewArchitectureEntryPoint.load overload
Reviewed By: mdvacca
Differential Revision: D52802644
fbshipit-source-id: f7c1db783959d93b81407847377f805d7ee2602d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42329
As the title says, this checks against illegal configurations of ReactFeatureFlags in DefaultNewArchitectureEntrypoint
and let the app crash if the user specified and illegal configuration
Changelog:
[Internal] [Changed] - Prevent illegal configurations of ReactFeatureFlags in DefaultNewArchitectureEntrypoint
Reviewed By: mdvacca
Differential Revision: D52802609
fbshipit-source-id: 7bc0a08c17430d7fd2448f65838ce47fad738883
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42327
This diff is the result of running
`buck2 run //xplat/js/scripts/rn-api:generate-rn-api-metadata`
After this lands, `react-native-android-breaking-change-detector` will actually be green again, after the previous diff fixed the infra setup.
Changelog: [General][Fix] Update stale ReactAndroid.api values after CI breakage
Reviewed By: cortinico, mdvacca
Differential Revision: D52800160
fbshipit-source-id: b96533baa1cb704ad43482d7a52db50e6dce9821
Summary:
This PR introduces the `vision` interfaceIdiom to check if the app runs on visionOS.
An update to the documentation should follow this change.
## Changelog:
[IOS] [ADDED] - Introduce `vision` interfaceIdiom
Pull Request resolved: https://github.com/facebook/react-native/pull/42243
Test Plan: This change has been used in `react-native-visionos` and the interfaceIdiom changes **only** when running in the non-compatibility mode. But it's still useful to have this upstream if at some point React native would compile to visionOS natively
Reviewed By: cortinico
Differential Revision: D52730028
Pulled By: cipolleschi
fbshipit-source-id: 711c5c2c6c7fe05b3ff8da7383b5e63e9e04acfa
Summary:
X-link: https://github.com/facebook/yoga/pull/1553
Pull Request resolved: https://github.com/facebook/react-native/pull/42274
Separate from `YGConfigSetPrintTreeFlag` we have a public API `YGNodeSetPrintFunc` which sets a function called, if you manually change a constant in source code during debugging.
This is not debug-only, is exposed as part of the public API (without a way to turn it on from the public API), and takes up a pointer per node doing nothing.
I'm not aware of anyone recently using the capability, and the tracing/event related work done since then would be more powerful for this anyway.
Remove the API.
Changelog: [Internal]
Reviewed By: rozele
Differential Revision: D52767445
fbshipit-source-id: f72927b47cffa4fe6fe886b42f07cc1ba55f141e
Summary:
1. Modal onDismiss is not working on iOS (Fabric).
2. Modal onDismiss is currently only available on iOS. On Android, we don't have a way to know when exactly a modal is dismissed.
Currently, the onDismiss is emitted using a device event as a workaround to the RCTModalHostView unable to receive the component event as it's already unmounted when visible is false.
This PR removes the workaround and keeps RCTModalHostView mounted until the onDismiss event is emitted from the host and sends the onDismiss event on Android.
bypass-github-export-checks
## Changelog:
[ANDROID] [ADDED] - Added support for Modal onDismiss prop
[IOS] [FIXED] - Fix onDismiss is not working on Fabric
[General][Breaking] - The public API of Modal has changed. We don't have anymore a NativeModalManger turbomodule; RCTModalHostViewNtiveComponent's Prop does not require to pass an identifier anymore.
Pull Request resolved: https://github.com/facebook/react-native/pull/42014
Test Plan:
1. Run rn-tester
2. Open the Modal example
3. The second example shows the counter for the show and dismiss count
4. Show and dismiss the modal and verify the count is incremented correctly
https://github.com/facebook/react-native/assets/50919443/108bfb26-c8f6-43b2-ac40-f0b46e48771b
Reviewed By: javache, sammy-SC
Differential Revision: D52445670
Pulled By: cipolleschi
fbshipit-source-id: f419164032c3bef67387200778b274299bf0659f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42306
Internally, we have some computationally expensive checks in Debug mode when running Fabric.
However, these are not very useful in OSS and they were the cause of some issues which generated noise.
With this change, we are enabling those checks only in the Meta specific builds and making sure that the OSS won't incur in that cost.
## Changelog
[Internal] - Disable expensive Fabric checks when running Fabric in OSS
Reviewed By: cortinico, sammy-SC
Differential Revision: D52543696
fbshipit-source-id: 697f14fd21e884f293ea7cee8ee16fff73764996
Summary:
There seems to be a lot of `TARGET_OS_UIKITFORMAC` macro in React Native that don't need to be there. Let's remove them.
First off, what is `TARGET_OS_UIKITFORMAC` targeting? You might think it's [Mac Catalyst](https://developer.apple.com/mac-catalyst/), if you look at the [commit](https://github.com/facebook/react-native/commit/3724810d2168eb182db24acf9e741775df27ae13) introducing the ifdefs. However.. that doesn't seem right because `TARGET_OS_MACCATALYST` exists, and is used elsewhere in the codebase. In fact, if you look at this handy comment inside `TargetConditionals.h` (the file that defines all these conditionals), `TARGET_OS_UIKITFORMAC` is not even on there!
```
/*
* TARGET_OS_*
*
* These conditionals specify in which Operating System the generated code will
* run. Indention is used to show which conditionals are evolutionary subclasses.
*
* The MAC/WIN32/UNIX conditionals are mutually exclusive.
* The IOS/TV/WATCH/VISION conditionals are mutually exclusive.
*
* TARGET_OS_WIN32 - Generated code will run on WIN32 API
* TARGET_OS_WINDOWS - Generated code will run on Windows
* TARGET_OS_UNIX - Generated code will run on some Unix (not macOS)
* TARGET_OS_LINUX - Generated code will run on Linux
* TARGET_OS_MAC - Generated code will run on a variant of macOS
* TARGET_OS_OSX - Generated code will run on macOS
* TARGET_OS_IPHONE - Generated code will run on a variant of iOS (firmware, devices, simulator)
* TARGET_OS_IOS - Generated code will run on iOS
* TARGET_OS_MACCATALYST - Generated code will run on macOS
* TARGET_OS_TV - Generated code will run on tvOS
* TARGET_OS_WATCH - Generated code will run on watchOS
* TARGET_OS_VISION - Generated code will run on visionOS
* TARGET_OS_BRIDGE - Generated code will run on bridge devices
* TARGET_OS_SIMULATOR - Generated code will run on an iOS, tvOS, watchOS, or visionOS simulator
* TARGET_OS_DRIVERKIT - Generated code will run on macOS, iOS, tvOS, watchOS, or visionOS
*
* TARGET_OS_EMBEDDED - DEPRECATED: Use TARGET_OS_IPHONE and/or TARGET_OS_SIMULATOR instead
* TARGET_IPHONE_SIMULATOR - DEPRECATED: Same as TARGET_OS_SIMULATOR
* TARGET_OS_NANO - DEPRECATED: Same as TARGET_OS_WATCH
*
* +--------------------------------------------------------------------------------------+
* | TARGET_OS_MAC |
* | +-----+ +------------------------------------------------------------+ +-----------+ |
* | | | | TARGET_OS_IPHONE | | | |
* | | | | +-----------------+ +----+ +-------+ +--------+ +--------+ | | | |
* | | | | | IOS | | | | | | | | | | | | |
* | | OSX | | | +-------------+ | | TV | | WATCH | | BRIDGE | | VISION | | | DRIVERKIT | |
* | | | | | | MACCATALYST | | | | | | | | | | | | | |
* | | | | | +-------------+ | | | | | | | | | | | | |
* | | | | +-----------------+ +----+ +-------+ +--------+ +--------+ | | | |
* | +-----+ +------------------------------------------------------------+ +-----------+ |
* +--------------------------------------------------------------------------------------+
*/
```
Going even deeper into `TargetConditionals.h`, you will see `TARGET_OS_UIKITFORMAC` defined... and it's always 1 when `TARGET_OS_MACCATALYST` is 1, making it feel even more redundant. My current conclusion is it's either another variant of Mac Catalyst (the one where they just run unmodified UIKit maybe..), or it's an older macro back from when Catalyst was still experimental.
Either way, it's pretty obvious nobody is running or testing this codepath, and it adds bloat, especially to React Native macOS where we have extra ifdef blocks for macOS support (and eventually visionOS support). Let's remove it.
Another change I made while we're here:
I've seen this lingering TODO to replace setTargetRect:InView: / setMenuVisible:animated: (deprecated as of iOS 13, below our minimum OS requirement) with showMenuFromView (deprecated as of iOS 16, in line with the availability check). Let's just.... do that?
## Changelog:
[IOS] [REMOVED] - Remove TARGET_OS_UIKITFORMAC macros
Pull Request resolved: https://github.com/facebook/react-native/pull/42278
Test Plan:
RNTester with Mac Catalyst still compiles:
Reviewed By: cipolleschi
Differential Revision: D52780690
Pulled By: sammy-SC
fbshipit-source-id: df6a333e8e15f79de0ce6f538ebd73b92698dcb6
Summary:
This PR adds `get_folly_config()` to RCTAppDelegate, it was recently introduced here: https://github.com/facebook/react-native/issues/42153
## Changelog:
[INTERNAL] [CHANGED] - Unify folly version and compiler flags for RCTAppDelegate
Pull Request resolved: https://github.com/facebook/react-native/pull/42281
Test Plan: CI Green
Reviewed By: NickGerleman
Differential Revision: D52783503
Pulled By: cipolleschi
fbshipit-source-id: d1497371e84618f93abe8f7fab7ee0cdf5296d27
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42291
In case someone tries to inline out-of-tree platform files with react-native JS Libraries files, it's useful to suppress issues with public API tests, as the public APIs are not intended to match yet.
## Changelog
[Internal]
Reviewed By: christophpurrer
Differential Revision: D52790636
fbshipit-source-id: 7bbaf8ae6d9571ed7d81d06ab4b82f67f518c5a0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42300
Changelog: [Internal]
The version of the `keyword-spacing` lint rule we have installed is apparently buggy. Either way it's unnecessary since we use Prettier.
Reviewed By: christophpurrer
Differential Revision: D52799550
fbshipit-source-id: 2e199938d45c554039b2117163fd403f236bf752
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42267
In case anyone was to try linting the react-native repo with desktop out-of-tree platform files there, this makes things easier.
## Changelog
[Internal]
Reviewed By: christophpurrer
Differential Revision: D52746379
fbshipit-source-id: d59a1c1f9c84c6bee529d6bdd151a7ba680b6680
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42119
Changelog: [Internal]
- Updated spec for native commands of the DebuggingOverlay to have `Array` annotation instead of a workaround with string (and serialization)
- Removed serialization in JS and deserialization on native
Reviewed By: javache
Differential Revision: D51985222
fbshipit-source-id: 3dc5a049ae4984565df9ea32fa181c5885b79539
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41842
Changelog: [Internal]
- bumps `react-devtools-*` packages to 5.0.0 across xplat
- added support for highlighting multiple host components, when hovering over component, which is represented by multiple host fibers.
See test plan, this can be reproduced with a named component, which renders multiple host components inside a React Fragment:
```
<>
<View />
<View />
<View />
</>
```
Reviewed By: gsathya
Differential Revision: D51888628
fbshipit-source-id: 2bd2d9fa50c24f478aa9406ee6bb42a47168bf13
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41843
Changelog:
[General] [Fixed] - inspected elements from React DevTools are now correctly highlighted on a relevant surfaces
For cases when DOM Node APIs are not available (Paper or Fabric without these APIs), we will use newly added `isChildPublicInstance` from renderer.
Similarly to D51713089, this updates implementations to highlight elements only on a single AppContainer.
Reviewed By: javache
Differential Revision: D51822874
fbshipit-source-id: d5992abed5ec6f11f04d2e1e6e6928c2a66aef7c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41818
Changelog: [Internal]
Use `parentElement` API to find lowest AppContainer ancestor, which will be responsible for highlighting an inspected element or rendering trace updates frames on the screen.
Reviewed By: sammy-SC
Differential Revision: D51713089
fbshipit-source-id: d6d07481679484a518a05b58d4394999876ea7d6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41816
Changelog: [Internal]
Forking implementations for trace updates and element highlights from React DevTools: modern and legacy.
Both implementations will later solve the same problem of highlighting the component only on a single AppContainer, but with different approaches:
- Modern will be based on DOM Node APIs: `getBoundingClientRect` and `parentElement`.
- Legacy will be based on `isChildInstance` from renderer and `measure`.
All corresponding API call will be added in a separate diff later on top of these changes.
Reviewed By: sammy-SC
Differential Revision: D51713087
fbshipit-source-id: 1c840d711a541085b1075711f737a8dbc1e31637
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41749
Changelog: [Internal]
- Each trace update frame will have its own unique id, which will be the react tag of the corresponding host fiber.
- Based on these ids, previous frames will be rerendered, not
just removed once new frames are sent from React DevTools.
- Imagine a case when there are 2 components on the screen: the first one rerenders once in a second and the second component rerenders much more frequently, each 5 milliseconds. With our previous implementation, update frames for first component will be removed once the second component has been rerendered.
- Each frame will have a lifetime for 2 seconds, it resets if frame with the same id was sent again from JS (basically component rerendered again, while we were highlighting it).
Android demo:
https://pxl.cl/3Vllz
Reviewed By: sammy-SC
Differential Revision: D51708054
fbshipit-source-id: 7abff9c1a334dccb3a1c08a46487d4bb99cdc448
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41746
Changelog: [Internal]
Now using previously added `highlightElements` and `clearElementsHighlights` commands.
[Improvement] Since DebuggingRegistry is a singleton, it will only subscribe to the React DevTools events once and not *number-of-rendered-AppContainers* times.
All required functionality for highlighting elements on a single AppContainer will be added in one of the next diffs of this stack, changes are incremental.
Reviewed By: sammy-SC
Differential Revision: D51708053
fbshipit-source-id: f94a1bb1f5b876a153d305eeacf65b8a5eca2a08
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41745
Changelog: [Internal]
Support `highlightElements` and `clearElementsHighlights` commands in `DebuggingOverlay` native components.
These later will be used for highlighting inspected component in React DevTools. These commands unblock highlighting elements on the native side, currently we do it on JS side and it mutates the React tree.
We still need to serialize the array before passing it to the native command, because codegen doesn't support it yet.
Reviewed By: javache
Differential Revision: D51603861
fbshipit-source-id: da837b0fc32e36980f207166a679fb8124ff6100
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41744
Changelog: [Internal]
With these changes:
- DebuggingRegitry is responsible for listening to the events from React DevTools and
- AppContainer renders DebuggingOverlay component and subscribes with its reference to the DebuggingRegistry
- [Improvement] Since DebuggingRegistry is a singleton, it will only subscribe to the React DevTools events once and not *number-of-rendered-AppContainers* times
All required functionality for highlighting elements on a single AppContainer will be added in one of the next diffs of this stack, changes are incremental.
Reviewed By: sammy-SC
Differential Revision: D51603860
fbshipit-source-id: 92b029eb54ef63b27af970770eb522915578a0b9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41743
Changelog: [Internal]
There will be a single DebuggingRegistry instance per runtime, which will be responsible for finding lowest AppContainer ancestor for highlighted component.
It will receive refs to root views (ancestors, AppContainers) as subscriptions and later will call all necessary methods.
In the next series of diffs, subscriber will also provide reference to the DebuggingOverlay, on which DebuggingRegistry can call all necessary methods to highlight elements.
Reviewed By: rshest
Differential Revision: D51536787
fbshipit-source-id: e89f9d466a7e7833733981ff0d3ce2dbe349aaaa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42249
Changelog: [Internal]
Manually patching public React renderers artifacts to include `isChildPublicInstance` method, which was added in https://github.com/facebook/react/pull/27783.
To identifly the required changes in code I've ran a diff for 2 commits:
1. The one with the changes
2. Its parent
FB implementation were synced in D51816108.
Reviewed By: sammy-SC
Differential Revision: D52697885
fbshipit-source-id: c62af6e89e8da3ee6f6c7264bacf6e96030e9db8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42285
Changelog: [Internal]
Having a static import of `ReactFabric` blocks from using `ReactNativeElement` class for Paper-only applications.
Although DOM Node APIs are Fabric-only, the ability to use `instanceof ReactNativeElement` is a nice tool for gating purposes, which currently can't be used because of the static import.
Reviewed By: rubennorte
Differential Revision: D52784886
fbshipit-source-id: 705c6ce0b5912d9857d730ebf1e1ecf629e2b8af
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42247
With this change I make `ReactNativeConfig` a JNI class loaded at Fabric Loading time.
This removes the default from `EmptyReactNativeConfig.java` and makes sure we do read the defaults from C++ `ReactNativeConfig.cpp` file.
Changelog:
[Internal] [Changed] - Make ReactNativeConfig a JNI Class
Reviewed By: motiz88
Differential Revision: D52696653
fbshipit-source-id: 99d5e37c65e0e59efcee2c857bb94194fb40d87d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42287
Changelog: [Internal]
`run-ci-e2e-tests.js` currently skips past package build errors and tries to keep going. At best, this fails somewhere downstream of a build error (without any clear diagnostics as to why). At worst, this can miss errors entirely.
Here we extend the script's existing error handling behaviour to cover errors during the build script. It's probably worth following up to make sure all unexpected failures bubble up and stop the script, as opposed to the current error-swallowing default.
Reviewed By: hoxyq
Differential Revision: D52785131
fbshipit-source-id: 08deedfdf5b3d3cb63e77c74b47eb75570a58fbb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42248
I'm duplicating the AndroidManifest.xml file internally/externally as Gradle is really unhappy with it (and gets really noisy):
- It contains a package declaration which should be removed
- It contains a uses-sdk which should also be removed
Changelog:
[Internal] [Changed] - Fix AndroidManifest.xml for RN-Tester in OSS
Reviewed By: christophpurrer
Differential Revision: D52694108
fbshipit-source-id: bb88e6f58cc8cf3a624be4b58bb409535a283a77
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42265
Adds a snapshot test against the `react-native` package which emits the shape of all Flow-typed modules under `Libraries/`, as an approximation of the public JS API.
This provides:
- Visibility for maintainers on any PR which changes the shape of the public API.
- An at-a-glance diff of changed APIs between React Native versions (useful for library integrators and the Release Crew).
Note — **workflow change**: Maintainers modifying public files/function signatures under Libraries/ will need to run `yarn jest -u` and commit the updated snapshot changes.
Changelog: [Internal]
Reviewed By: TheSavior, philIip, mdvacca
Differential Revision: D52729777
fbshipit-source-id: 90ca2924b50205485b6d49e52a2889d8e00a43b9
Summary:
X-link: https://github.com/facebook/yoga/pull/1547
Pull Request resolved: https://github.com/facebook/react-native/pull/42251
Yoga has an odd behavior, where `start`/`end` edges under row-reverse are relative to flex-direction, instead of writing direction.
While Yoga doesn't actually document what this behavior is supposed to be, it goes against CK documentation, historic RN documentation, and the behavior valid on the web. It is also applied inconsistently (e.g. sometimes only on container, sometimes on child). It really is a bug, instead of an intended behavior.
We changed the default behavior for Yoga, but left the existing one behind an errata (so existing fbsource users got old behavior). We have previously seen this behavior show up in product code, including CK when running on FlexLayout.
`row-reverse` is surprisingly uncommon though:
1. Litho has <40 usages
2. RN has ~40 usages in `RKJSModules`,~30 in `arvr/js`, ~6 in `xplat/archon`
3. CK has ~80 usages
4. NT has ~40 usages
There are few enough, mostly simple components, that we can inspect through each of them, looking for signs they will hit the issue (at the potential chance of missing some).
CK accounts for 10/14 usages that I could tell would trigger the issue, since it only exposes start/end edge, and not left/right. It might make sense to make it preserve behavior instead, to reduce risk a bit.
FlexLayout is now separately powering Bloks, which wasn't surveyed, so I didn't touch CK behavior under Bloks.
There could also be other usages in other frameworks/bespoke usages, and this has implications for OSS users. But based on our own usage, of many, many components, this seems rare.
Changelog:
[General][Breaking] - Make `start/end` in styles always refer to writing direction
Reviewed By: pentiumao, joevilches
Differential Revision: D52698130
fbshipit-source-id: 2a9ac47e177469f30dc988d916b6c0ad95d53461
Summary:
Original commit changeset: 9305bc56ba6b
Original Phabricator Diff: D52642168
bypass-github-export-checks
changelog: [Android][Fix] Backout fix that prevented scroll event in nested scroll when scrollEnabled = false, due to causing bugs when interacting with keyboard events
Reviewed By: bvanderhoof, arushikesarwani94
Differential Revision: D52736596
fbshipit-source-id: fa8c5c598e049cc58410892813825852c431eee4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41978
I'm revering the removal of ReactModule codegen.
We are postpoinging the removal of the codegen for the future, the reasons are:
- resources: the experiment that removes the codegen shows neutral metrics, but the codegen is shared between bridge and bridgeless, so we will need to implement and test the removal for bridge and we don't have the time to do this right now.
- reduce fragmentation: we don't want to fragment NativeModules configuration between bridge and bridgeless, doing so will bring a lot of confusion to developers
- we don't want to introduce a public APIs in 0.73 that we know they are not used in production for now, we better remove these "unstable" apis before 0.74 cut
Note: I'm updating ReactAndroid.api because this is an intended change of APIs which were not part of 0.73 and we don't want them to be part of 0.74.
changelog: [internal] internal
Reviewed By: RSNara
Differential Revision: D52223650
fbshipit-source-id: 681bf5e4aab776505f64b1972a6ace6340db4587
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42259
At the end of last year, we reduce build fragmentation in iOS making sure that we were always building both architecture.
In the process, we break the semantic od RCt_NEW_ARCH_ENABLED flag, making several libs stop working in one of the two archs.
This change should restore the semantic, so libraries that were using RCT_NEW_ARCH_ENABLED to run conditional code will still work in the same way. While doing so, I also removed the new USE_NEW_ARCH as we don't want unnecessary flags
## CHANGELOG:
[iOS][Fixed] - Bring the old RCT_NEW_ARCH_ENABLED semantic back for compatibility
Reviewed By: cortinico
Differential Revision: D52727792
fbshipit-source-id: e211b10e7885eada83dd2886375575133ca76c8c
Summary:
Yesterday we landed a change that removed tests for the Old Architecture for RNTester.
That was the right call as there are no build differences in RNTester between the two architectures. But we do have runtime differences, and we had an integration test running on RNTester that we deleted with the previous PR.
This change restores that test, adding this only new job to run that test
## Changelog:
[Internal] - Add back an old arch integration test
Pull Request resolved: https://github.com/facebook/react-native/pull/42262
Test Plan: CircleCI is green
Reviewed By: cortinico
Differential Revision: D52730661
Pulled By: cipolleschi
fbshipit-source-id: 10fbc2540abeebc72f635451f6f650827cf20041
Saad Najmi
Gijs Weterings
Moti Zilberman
Nicola Corti
Oskar Kwaśniewski
Nick Gerleman
Bernhard Owen Josephus
Riccardo Cipolleschi
Eric Rozell
generatedunixname89002005325672
Neil Dhar
Ruslan Lesiutin
Alex Hunt
David Vacca
Riccardo Cipolleschi
Pieter De Baets
Alex Taylor (alta)