#publish-packages-to-npm

Summary:
Pull Request resolved: facebook#39476

This diff enables native view config interop layer in bridgeless mode by default for OSS.
It also removes redundant `enableNativeViewConfigsInBridgelessMode` JS feature flag.
Changelog: [General][Added] - Native view config interop layer enabled in bridgeless mode.

Reviewed By: luluwu2032

Differential Revision: D49318325

fbshipit-source-id: ea2e38b2ea10637b578d98e38d97eed923498fb3

Summary:
Pull Request resolved: facebook#39661

Changelog:
[Android][Changed] - Enable Template with Bridgeless

Reviewed By: cortinico

Differential Revision: D49464580

fbshipit-source-id: 26dd8e2a0b9a66421d58f147eed4d2fd28817dc7

…#39698)

#publish-packages-to-npm

Summary:
Pull Request resolved: facebook#39640

changelog: [internal] internal

Reducing visibility from public to package only for `ReactHostImpl.getDefaultHardwareBackBtnHandler()` since it's only used within package

Reviewed By: mdvacca

Differential Revision: D49612859

fbshipit-source-id: 3c40888da732f33dc046d9363b08119e707f4ea4

Summary:
Pull Request resolved: facebook#39687

Bridgeless mode is releasing in 0.73.

Bridgeless mode isn't stable inside RNTester (in 0.73) without the TurboModule interop layer: T164853040.

**Changes:** Enable the TurboModule interop layer in RNTester (Bridgeless Mode).

**Urgency:** This will unblock the 0.73.

Changelog: [General][Added] - Enable TurboModule interop in Bridgeless mode

Reviewed By: fkgozali, dmytrorykun, luluwu2032

Differential Revision: D49653919

fbshipit-source-id: a4a09a99544c2ef8713484dbeab5cb04f29256cc

…nabled (facebook#39696)

Summary:
Pull Request resolved: facebook#39696

`Commands` and `Constants` should be set in native only if component data is instantiated via native view config interop layer.
Changelog: [Internal]

Reviewed By: RSNara

Differential Revision: D49684166

fbshipit-source-id: ceaa29c2ed3336aa6e21a116a3f5f94e03c225c1

#publish-packages-to-npm

Summary:
Pull Request resolved: facebook#39710

Last week Apple released Xcode 15, which required us to ship a workaround for the new linker.
Unfortunately, the previous fix was not good enough and there were some edge cases that were not covered.
For example, in some occasions the flags are read as an array and the `-Wl` and the `-ld_classic` flags were separated and not properly removed when moving from Xcode 15 to Xcpde 14.3.1.

This change fixes those edge cases, with a more robust solution where:
- We convert the flags to a string.
- We trim the string and the values properly.
- We add the flags when running `pod install` with Xcode 15 as the default iOS toolchain.
- We remove the flags when running `pod install` with Xcode <15 as the default iOS toolchain.

## Changelog:
[Internal] - Make the Xcode 15 workaround more robust.

Reviewed By: dmytrorykun

Differential Revision: D49748844

fbshipit-source-id: 34976d148f123c5aacba6487a500874bb938fe99

Summary:
Sync latest `debugger-frontend` artifacts, based on motiz88/rn-chrome-devtools-frontend#12.

Changelog: [Internal]

Reviewed By: motiz88

Differential Revision: D49502838

fbshipit-source-id: 25805066670ac35ec976dc820a73a722ee182dd2

Summary:
Pull Request resolved: facebook#39755

The goal of this diff is to fix:
```
JNI DETECTED ERROR IN APPLICATION: JNI NewGlobalRef called with pending exception java.lang.NoSuchMethodError: no static or non-static method
"Lcom/facebook/react/jscexecutor/JSCExecutor;.initHybrid(Lcom/facebook/react/bridge/ReadableNativeMap;)Lcom/facebook/jni/HybridData;"

```

changelog: [internal] internal

Reviewed By: luluwu2032

Differential Revision: D49831595

fbshipit-source-id: 9ce22cdccdd02af74edb27be2df72a469d3166c9

#publish-packages-to-npm

#publish-packages-to-npm

This is an eager cherry pick of facebook#39784 for `0.73-stable`.

This reverts commit 6b9cf50.

This reverts commit b6c0703.

Applies correct fix for `_formatVersion` misalignment — based on facebook#36657.

This is an eager cherry pick of facebook#39788 for `0.73-stable`.

#publish-packages-to-npm

This reverts commit 725b1c9.

Summary:
The Loading.../Refreshing... indicator is currently broken on Android.
The reason is related to D42599220
We used to have a Toast shown to users on Android as a fallback, but as the
DevLoadingView is not always loaded as a module in the core package, this ends up in the banner never beign shown to the user (on RN Tester or template apps).

Changelog:
[Android] [Fixed] - Fix broken Loading/Refreshing indicator on Android

Reviewed By: cipolleschi

Differential Revision: D49876757

fbshipit-source-id: 400e002327ebca908e3e7a7f81c5066888ac4e9b

Summary:
Pull Request resolved: facebook#39807

We used to need this file so that we could read the react native version when [creating Hermes artifacts](facebook@e4b5d3e#diff-78a8a19706dbd2a4425dd72bdab0502ed7a2cef16365ab7030a5a0588927bf47R1507). Originally, that change was introduced [here](facebook@e4b5d3e#diff-78a8a19706dbd2a4425dd72bdab0502ed7a2cef16365ab7030a5a0588927bf47)

Despite the fact that that approach was wrong, as we already have the right version in the package.json which is guaranteed to be present, a lot has changed since then and we don't need that file anymore.

## Changelog:
[Internal] - Remove lines that write a .version file while releasing on npm

Reviewed By: lunaleaps

Differential Revision: D49909718

fbshipit-source-id: bd23d6d73001d0b58bf6b0321ed6d4ceb3523e7a

…figs in bridgeless mode (facebook#39704)

Summary:
Pull Request resolved: facebook#39704

Default to native view configs in bridged mode and to static view configs in bridgeless mode.
Remove `setRuntimeConfigProvider` calls from RNTester and from the Template.
Changelog: [Internal]

Reviewed By: RSNara

Differential Revision: D49687252

fbshipit-source-id: 140e1c510ba3fbc153978b59c8bb4b4e35bc7571

Summary:
Pull Request resolved: facebook#39828

Active Suppert released a new Gem which is incompatible with Cocoapods 1.13.0, the latest release, as they removed a method used by cocoapods.

This fix ensures that we install compatible versions of the Gem.

## Changelog:
[iOS][Fixed] - Set the max version of Active support to 7.0.8

Reviewed By: hoxyq

Differential Revision: D49949782

fbshipit-source-id: 278097502d3a416567cc8c0b90090fee4fb21503

…h. (facebook#39803)

Summary:
Fixes - facebook#38626 (comment). Explained the issue [here](facebook#38626 (comment)).

## Changelog:

[IOS] [FIXED] - View flips horizontally in paper arch on RTL

Pull Request resolved: facebook#39803

Test Plan: Run RNTester in Paper mode on iOS

Reviewed By: NickGerleman

Differential Revision: D49952227

Pulled By: lunaleaps

fbshipit-source-id: 7240552e499765859dceea0a0406561cc3a3148f

Summary:
Changelog: [Internal] - Set the hermes value as specified by the test-e2e-local script flag. Right now, the script incorrectly ignores the flag

By default, the template project has `hermesEnabled=true`

Reviewed By: cipolleschi

Differential Revision: D49831355

fbshipit-source-id: 7fb8613fa86f2c6140b7d25b16aeb583e6e26c12

…acebook#40766)

Summary:
Pull Request resolved: facebook#40766

This changeset allows users to opt into the new debugger frontend experience by passing `--experimental-debugger` to `react-native start`. **We are defaulting this option to `true`** for now, but will continue to evaluate this feature before 0.73 ships. It restores Flipper (via `flipper://`) as the default handling for `/open-debugger` (matching 0.72 behaviour) when this flag is not enabled.

Detailed changes:

- Replaces `enableCustomDebuggerFrontend` experiment in `dev-middleware` with `enableNewDebugger`. The latter now hard-swaps between the Flipper and new launch flows.
    - Removes now-unused switching of `devtoolsFrontendUrl`.
- Implements `deprecated_openFlipperMiddleware` (matching previous RN CLI implementation).
- Disables "`j` to debug" key handler by default.
- Marks "`j` to debug" and `/open-debugger` console logs as experimental.

Changelog:
[Changed][General] Gate new debugger frontend behind `--experimental-debugger` flag, restore Flipper as base launch flow

Reviewed By: motiz88

Differential Revision: D50084590

fbshipit-source-id: 5234634f20110cb7933b1787bd2c86f645411fff

…acebook#39957)

Summary:
Pull Request resolved: facebook#40733

Node package managers may purge or recreate `node_modules/react-native` when adding/removenf project dependencies. Storing hermes iOS artifacts inside `node_modules/react-native/sdks` is not reliable.
This diff moves those artifacts to `Pods/hermes-engine-artifacts`.
Should fix facebook#39903
Changelog: [Internal]

Reviewed By: cipolleschi

Differential Revision: D50081559

fbshipit-source-id: a130898e12fb6275cadaef7617bf4b6a09e6487e

Summary:
Pull Request resolved: facebook#39644

This makes Android Paper/Classic renderer fire `onLayout` events top down, like in Fabric/new Architecture. This gives a much more sane model for using layout events to calculate bottom/right-edge insets.

I was under the impression that Paper in general was bottom-up, but it turns out that is only true for Android and Windows (iOS seems totally deterministic).

This is a behavior change, but to my knowledge was never hit during the Fabric migration, and any JS code already written for both Android and iOS cannot make assumptions here anyways.

Changelog:
[General][Changed] - Make layout events top-down on Android classic renderer

Reviewed By: mdvacca

Differential Revision: D49627996

fbshipit-source-id: 29964b421dd420681d45348c7db16f211a6c087f

Summary:
Pull Request resolved: facebook#40748

The ordering of `onLayout` events is non-deterministic on iOS Paper, due to nodes being added to an `NSHashTable` before iteration, instead of an ordered collection.

We don't do any lookups on the collection, so I think this was chosen over `NSMutableArray` for the sake of `[NSHashTable weakObjectsHashTable]`, to avoid retain/release. Using a collection which does retain/release seems to cause a crash due to double release or similar, so those semantics seem intentional (though I'm not super familiar with the model here).

We can replicate the memory semantics with ordering by using `NSPointerArray` (which is unfortunately not parameterized). This change does that, so we get consistently top-down layout events (matching Fabric, and Android Paper as of D49627996). This lets us use multiple layout events to calculate right/bottom edge insets deterministically.

Changelog:
[iOS][Changed] -  Deterministic onLayout event ordering for iOS Paper

Reviewed By: luluwu2032

Differential Revision: D50093411

fbshipit-source-id: f6a9d5c973b97aede879baa8b952cc1be2447f28

…ebook#39646)

Summary:
Pull Request resolved: facebook#39646

We can dramatically simplify this code and remove quirks/hacks, now that we can assume layout events are always fired top down.

Changelog: [Internal]

Reviewed By: yungsters

Differential Revision: D49628669

fbshipit-source-id: 7de5bbc4597eba1c59aaa7672c70e76d2786c7ef

Summary:
Pull Request resolved: facebook#40751

In D48379915 I fixed inverted `contentOffset` in `onScroll` events on iOS. I thought I tested on Paper, but I think this was during a period where the Paper route in Catalyst was actually launching Fabric (oops).

In Paper, at least under `forceRTL` and English, `[UIApplication sharedApplication].userInterfaceLayoutDirection` is not set to RTL. We instead have a per-view `reactLayoutDirection` we should be reading.

This sort of thing isn't currently set on Fabric, which checks application-level RTL. This seems... not right with being able to set `direction` in a subtree context, but Android does the same thing, and that would take some greater changes.

Changelog:
[iOS][Fixed] - Fix iOS Paper Scroll Event RTL check

Reviewed By: luluwu2032

Differential Revision: D50098310

fbshipit-source-id: e321fca7b2f7983e903e23237bc2d604c72f98a3

Summary:
Pull Request resolved: facebook#40795

Changelog: [Internal]

Reviewed By: hoxyq

Differential Revision: D50178494

fbshipit-source-id: b833b6accadd2902d97a45e030cd48d1b62ac438

Summary:
The reference to runtime assumes the queue will ensure references to runtime are valid when invoked. This
isn't the case if you create a breakpoint, Hermes hit that breakpoint and your refresh the app. This consistently
will crash the app.

The fix is to not assument this, similar to ReactCommon/react/runtime/hermes/HermesInstance.cpp

Reviewed By: javache

Differential Revision: D50225678

fbshipit-source-id: b45cae1f5f687bc8c699fd74b187376a547012c5

Summary:
## Changelog:
[Internal] - Run all the tests in CI when not on a PR

Reviewed By: cortinico

Differential Revision: D50220596

fbshipit-source-id: be1a30d713e9d427858cf22bd3ca9549ad513057

Summary: Changelog: [Internal]

Reviewed By: cortinico

Differential Revision: D50327180

fbshipit-source-id: 6ee08fadd313828ddbc7702d5b3b1174a91b1ac1

facebook#41005)

Summary:
… request to local pathname comparator variables to fix issue with other rightward elements of url such as query or fragment entering the comparison and causing 404 errors for key debugging routes.

A change in Chromium appended the query "?for_tabs" to the /json/list request made by Chrome DevTools to find remote debugger targets.

The current comparison in InspectorProxy.js compares the entire node IncomingMessage url field to the local pathname constants. The issue arises as url can also contain the query and fragment portions so the original comparison of "/json/list" === "/json/list" which resolved as true would become "/json/list?for_tabs" === "/json/list" and evaluate to false ultimately resulting in a 404 for the request.

In summary, all these changes/issues caused remote debugging of Hermes code in React Native apps to become unavailable, greatly impacting developer experience.

## Changelog:

[GENERAL] [FIXED] JS Debugging: Fix inspector-proxy to allow for DevTools requests with query strings

Pull Request resolved: facebook#41005

Reviewed By: NickGerleman

Differential Revision: D50342265

Pulled By: robhogan

fbshipit-source-id: a65f2908f0bea9fc15e1e3e4e6d31a3b9598e81f

…acebook#40939)

Summary:
Pull Request resolved: facebook#40939

Currently some libs on RN 0.73 are broken as the default for Build Config generation changed
from true to false since AGP 8.x. This reverts the behavior to the old flag.

Closes facebook#40791
Closes facebook#40559

Changelog:
[Internal] [Changed] - Make sure buildConfig is turned on for all the 3rd party libraries

Reviewed By: mdvacca

Differential Revision: D50270382

fbshipit-source-id: 02dcb031c577f65be2f41d9da0334c1b3d89e4c5

…book#40757)

Summary:
Fix facebook#40560

## Changelog:

[ANDROID] [FIXED] - Ensure that `configureJavaToolChains` is only executed once during configuration

Pull Request resolved: facebook#40757

Test Plan:
- Create a fresh `react-native@0.73.0-rc.1` project
- Install `react-native-webview`
- Apply [this patch](https://github.com/react-native-webview/react-native-webview/pull/3175/files) for `react-native-webview` (caused by another issue facebook#40559)
- Edit `android/gradle.properties` and set `newArchEnabled` to true
- Build application
- (Expected) Application fail to build
- Apply this PR
- (Expected) Application build successfully

**Additional explanation:**

According to the implementation of `configureJavaToolChains`, all the subprojects (both the app and the libraries) will have their toolchains setup in one execution of the method. Therefore, it is okay for the method to be invoked only when configuring the plugin for the app.

On the other hand, invoking the method for more than one time will cause the issue stated in facebook#40560.

Reviewed By: cipolleschi

Differential Revision: D50361871

Pulled By: cortinico

fbshipit-source-id: bd5e18df97988122788d0482dba954e517a0cb5c

…nce (facebook#39834)

Summary:
Pull Request resolved: facebook#39834

Bridgeless is instacrashing on fast-refresh. This fixes it.

Changelog:
[Android] [Fixed] - Fix instacrash on bridgeless due to calling showMessage on null instance

Reviewed By: cipolleschi

Differential Revision: D49929822

fbshipit-source-id: a2ce65797abd34d6a3e2b7f2c50d38a62ea8bdea

Summary:
Pull Request resolved: facebook#40998

changelog: [Android] Add back interface FabricViewStateManager to unblock 0.73

I incorrectly deleted FabricViewStateManager in D47993140. This is a breaking change even for old architecture. Let's add it back and mark it as deprected so we can remove it later on.
This interface is not used in react-native anymore.

We are removing FabricViewStateManager because it simply wraps StateWrapper and provides no additional anymore.

Reviewed By: cortinico

Differential Revision: D50318633

fbshipit-source-id: aeb1c66c35018e336339616b564dee6f3156b54b

Summary:
Pull Request resolved: facebook#40767

Fix the following issue:
```Invariant Violation: TurboModuleRegistry.getEnforcing(...):
'ExceptionsManager' could not be found. Verify that a module by this name is registered in the native
binary.Bridgeless mode: true. TurboModule interop: true. Modules loaded: {"NativeModules":[],"TurboModules":
["PlatformConstants","AppState","SourceCode","BlobModule","WebSocketModule","DevSettings","DevToolsSettingsManager","LogBox","Networking","Appearance","DevLoadingView","DeviceInfo","DeviceEventManager",
"SoundManager","ImageLoader","DialogManagerAndroid","NativeAnimatedModule","I18nManager","AccessibilityInfo","StatusBarManager","StatusBarManager","IntentAndroid","ToastAndroid","ShareModule","Vibration"],
"NotFound":["NativePerformanceCxx","NativePerformanceObserverCxx","RedBox","BugReporting","HeadlessJsTaskSupport","FrameRateLogger","KeyboardObserver",
"AccessibilityManager","ModalManager","LinkingManager","ActionSheetManager","ExceptionsManager"]}
```

Changelog:
[Android][Changed] - Add Add ExceptionsManagerModule to CoreReactPackage

Reviewed By: cortinico

Differential Revision: D50017783

fbshipit-source-id: 8642bb23bdae50a1e702f5e0586b0ede80007bb1

# Conflicts:
#	packages/rn-tester/android/app/src/main/java/com/facebook/react/uiapp/RNTesterApplication.kt

Summary:
Pull Request resolved: facebook#39959

We're still accessing project.buildDir which will be removed in Gradle 9.0
I'm cleaning it up here.

Changelog:
[Internal] [Changed] - Fix compilation warnings introduced by Gradle 8.4

Reviewed By: yungsters

Differential Revision: D50016573

fbshipit-source-id: de7a725f61b503f08991ebf85b9a002cefab221a

Summary:
- ref: reactwg/react-native-releases#64 (comment)

With react-native@0.73.0-rc.2 and fresco@3.0.0, `dlopen failed: library "libnative-imagetranscoder.so"` error made crash in android. so, I patched fresco version to 3.1.0, so that resolves the crash error according to facebook/fresco#2722 (comment) this comment.

## 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
-->

[ANDROID] [FIXED] - b1fccb0 bumped fresco version to 3.1.0.

Pull Request resolved: facebook#41024

Test Plan: after bumping fresco version, error not occurs.

Reviewed By: cipolleschi

Differential Revision: D50359564

Pulled By: cortinico

fbshipit-source-id: d24caecc057bad4d9c94e378422ab18c106a7ee6

# Conflicts:
#	packages/react-native/gradle/libs.versions.toml

…ebook#39835)

Summary:
…king root view frame changes

Looking through where this was introduced (facebook#37649), it seems the notification went from tracking root view size changes to window size changes. However, it was not renamed. I was using it for root view changes in RN-macOS, which.. I guess I'll refactor. Meanwhile, let's update the name?

## Changelog:

[IOS] [CHANGED] - Rename `RCTRootViewFrameDidChangeNotification` as it's not tracking root view frame changes

Pull Request resolved: facebook#39835

Test Plan: CI should pass

Reviewed By: cipolleschi

Differential Revision: D50173742

Pulled By: javache

fbshipit-source-id: 4651696174c439800984a5e6cf642200bb9c4f3c

Summary:
Pull Request resolved: facebook#41009

This change should fix [facebook#39971](facebook#39971), computing the relative path from the App path to the pod installation root and using that instead of the absolute path to the `react-native.config.js` file

## Changelog
[Internal] - Stabilize RCTAppDelegate podspec

Reviewed By: cortinico

Differential Revision: D50323710

fbshipit-source-id: e29e62228d08c752e822d7a9ab5b1a2b5dcd6eb4

Summary:
For a very long time when a promise rejects without an attached catch we get this warning screen without a correct stack trace, only some internal calls to the RN internals.

<img src="https://github.com/facebook/react-native/assets/1634213/75aa7615-ee3e-4229-80d6-1744130de6e5" width="200" />

I created [an issue for discussion](react-native-community/discussions-and-proposals#718) in the react-native-community repo and we figured out it was only a matter of symbolication. While it cannot be done on release without external packages and source maps, at least while developing we can provide a symbolicated stack-trace so developers can better debug the source of rejected promise.

I got the stack trace symbolicated and the correct code frame. I'm missing some help trying to display it in the warning view but at the very least I can now correctly show the line of the error and log the codeframe to the console.
## Changelog:

<!-- Help reviewers and the release process by writing your own changelog entry.

Pick one each for the category and type tags:

[GENERAL] [FIXED] - Show correct stack frame on unhandled promise rejections on development mode.

For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests

Pull Request resolved: facebook#40914

Test Plan:
I simply created a throwing function on a dummy app, and checked the output of the console and the warning view:

```ts
import React from 'react';
import {SafeAreaView, Text} from 'react-native';

async function throwme() {
  throw new Error('UNHANDLED');
}

function App(): JSX.Element {
  throwme();

  return (
    <SafeAreaView>
      <Text>Throw test</Text>
    </SafeAreaView>
  );
}

export default App;
```

Here is the output

<img src="https://github.com/facebook/react-native/assets/1634213/2c100e4d-618e-4143-8d64-4095e8370f4f" width="200" />

Edit: I got the warning window working properly:

<img src="https://github.com/facebook/react-native/assets/1634213/f02a2568-da3e-4daa-8132-e05cbe591737" width="200" />

Reviewed By: yungsters

Differential Revision: D50324344

Pulled By: javache

fbshipit-source-id: 66850312d444cf1ae5333b493222ae0868d47056

Summary:
Pull Request resolved: facebook#41050

This change aligns all the podspecs to 13.4, including 3rd party libraries. This should fix facebook#39826

## Changelog
[iOS][Changed] - Align all pods to 13.4

Reviewed By: huntie

Differential Revision: D50405114

fbshipit-source-id: 2d1b50ed8433e8cdc2214eb17e15be6ea81107a1

# Conflicts:
#	packages/react-native/scripts/cocoapods/utils.rb

Summary:
The SocketRocket version was upgraded to 0.6.1 on the 0.72-stable branch but for some reason it was not updated in main, causing a downgrade when running `pod install` with 0.73.0 RC1

Original commit bumping SocketRocket -> facebook@8ce471e

## Changelog:

[IOS] [CHANGED] - Bump SocketRocket to 0.6.1

Pull Request resolved: facebook#40774

Test Plan: Run rntester locally

Reviewed By: cipolleschi

Differential Revision: D50137261

Pulled By: arushikesarwani94

fbshipit-source-id: dfc2760f5d5611881126ad114d8f6ada23630a29

# Conflicts:
#	packages/react-native/React-Core.podspec
#	packages/react-native/React/CoreModules/React-CoreModules.podspec
#	packages/rn-tester/Podfile.lock

…ebook#40789)

Summary:
Commit 8b88883 broke the Cache for RNTester because the cached version of the pods does not know about the exitence of SocketRocket 6.1.0
Bumping the keys should force a redownload of the cocoapods specs repo

## Changelog:
[Internal] - Bump RNTester cache keys

Pull Request resolved: facebook#40789

Test Plan: CircleCI is green

Reviewed By: GijsWeterings

Differential Revision: D50169281

Pulled By: cipolleschi

fbshipit-source-id: 83e251495bfa43d62384470efe97c5505d76684f

# Conflicts:
#	packages/rn-tester/Podfile.lock

This reverts commit 034d815.

Summary:
Rewrite `RNTesterApplication` to Kotlin as per [Help us Kotlin-ify React Native tests - Round 2](facebook#38825)

## Changelog:

[ANDROID] [CHANGED] - Rewrite RNTesterApplication to Kotlin, add AnnotationTarget property.

Pull Request resolved: facebook#39557

Test Plan:
`yarn && yarn android` ✅

The only thing I'm kinda unsure of is whether `AnnotationTarget.PROPERTY` should be added, but it didn't let me annotate `reactHostInterface` without that and didn't compile.
<img width="637" alt="image" src="https://github.com/facebook/react-native/assets/33528752/8bc84870-f3f2-4a46-b076-6ee7e38bd735">

 cortinico mdvacca

Reviewed By: cortinico

Differential Revision: D49598401

Pulled By: mdvacca

fbshipit-source-id: 105ae0c13c93dae0eeb2b6fa9040f03f42d2736a

Summary:
We don't need this if-than-else because the initializeFlipper already checks if we're on bridgeless or not

Changelog:
[Internal] [Changed] - Do not guard initializeFlipper for bridgeless for RN Tester

Reviewed By: NickGerleman

Differential Revision: D49881903

fbshipit-source-id: e6bfc941b43382580bd418a5f27ad9426d300c69

Summary:
Pull Request resolved: facebook#39810

Two issues will be fixed:
- Bridgeless has lazy view manager loading by default so the React Package that provides view managers must implement ViewManagerOnDemandReactPackage, we might could refactor the design of package classes later
- ThemedReactContext should **NOT** be used directly to call function ```getJSModule```, since it doesn't overrides ```getJSModule``` for Bridgeless, we can use it's internal variable ```meactApplicationContext``` which should be an instance of BridgelessReactContext

Reviewed By: cortinico

Differential Revision: D49912656

fbshipit-source-id: a0bdd717612398e8d7a6f36d36dba241a3b06bd7

Summary:
Pull Request resolved: facebook#39769

Move ReactHost to com.facebook.react

bypass-github-export-checks

changelog: [internal] internal

Reviewed By: javache

Differential Revision: D49834870

fbshipit-source-id: 2cfdd34297399115457424f0ba1279fd477da4a1

Summary:
Pull Request resolved: facebook#39987

Changelog: [Internal]

Reviewed By: fkgozali

Differential Revision: D49983211

fbshipit-source-id: c362d5b93e159bfb5ca17bea0ec0484adcdb4dca

Summary:
Pull Request resolved: facebook#40767

Fix the following issue:
```Invariant Violation: TurboModuleRegistry.getEnforcing(...):
'ExceptionsManager' could not be found. Verify that a module by this name is registered in the native
binary.Bridgeless mode: true. TurboModule interop: true. Modules loaded: {"NativeModules":[],"TurboModules":
["PlatformConstants","AppState","SourceCode","BlobModule","WebSocketModule","DevSettings","DevToolsSettingsManager","LogBox","Networking","Appearance","DevLoadingView","DeviceInfo","DeviceEventManager",
"SoundManager","ImageLoader","DialogManagerAndroid","NativeAnimatedModule","I18nManager","AccessibilityInfo","StatusBarManager","StatusBarManager","IntentAndroid","ToastAndroid","ShareModule","Vibration"],
"NotFound":["NativePerformanceCxx","NativePerformanceObserverCxx","RedBox","BugReporting","HeadlessJsTaskSupport","FrameRateLogger","KeyboardObserver",
"AccessibilityManager","ModalManager","LinkingManager","ActionSheetManager","ExceptionsManager"]}
```

Changelog:
[Android][Changed] - Add Add ExceptionsManagerModule to CoreReactPackage

Reviewed By: cortinico

Differential Revision: D50017783

fbshipit-source-id: 8642bb23bdae50a1e702f5e0586b0ede80007bb1

Summary:
Pull Request resolved: facebook#40940

Currently the `onIntArrayChanged` event is invoked
 only once inside RN Tester. I'm changing the logic to make sure it fires whenever we click "Set Opacity"

Changelog:
[Internal] [Changed] - Make sure onIntArrayChanged is invoked on RN Tester

Reviewed By: mdvacca, dmytrorykun

Differential Revision: D50264765

fbshipit-source-id: 93a60fd1b657c3d8b8182cab6bb7cd4368ac9a42

Summary:
Pull Request resolved: facebook#40942

The Fabric Interop example for Android is broken. This is due to the Kotlin conversion which moved the `Color.colorToHSV(color, hsv)` statement *after* the HSV array is read so the array is always [0,0,0].

I'm fixing it here.

Changelog:
[Internal] [Changed] - Fix broken Fabric Interop example

Reviewed By: cipolleschi

Differential Revision: D50264766

fbshipit-source-id: 27ae5289408c7c23c667d6d7112437fa7ebe36d5

Summary:
Pull Request resolved: facebook#40929

This diff reduces the footprint that bridgeless is imposing on the new app template. Specifically:
- I've created a `.toReactHost` method that converts a DefaultReactNativeHost to a DefaultReactHost
- I've updated RN Tester to use the same setup as the New App template which reduces code duplication.

I also had to remove a couple of `UnstableReactNativeAPI` as those were bleeding in the new app template.
I don't think we should ask users to opt-in in `UnstableReactNativeAPI` in the New App template itself as
this means that all the apps will get this opt-in.
Instead we should keep it only for specific APIs that we want the users to opt into.

Changelog:
[Internal] [Changed] - Simplify new app template for bridgeless

Reviewed By: cipolleschi, luluwu2032

Differential Revision: D50227693

fbshipit-source-id: e86c54d5156cc27f1f898b43ca89c57d5cf148b8

Summary:
Pull Request resolved: facebook#40941

Events are currently not working for Fabric Interop on Bridgeless. That's because the `BridgelessReactContext` is not checking for interop modules on `getJsModule` calls, so the `InteropEventEmitter` is never returned.

This extends `BridgelessReactContext` so that  `InteropEventEmitter` is returned if the Interop Layer is turned on.

Changelog:
[Internal] [Changed] - Make events work for Fabric Interop on Bridgeless

Reviewed By: cipolleschi

Differential Revision: D50266484

fbshipit-source-id: 0188d71bdc7acc8c188d886d45f0258914ad7af7

Summary:
Pull Request resolved: facebook#41047

Array events are currently broken in the sample for RN Tester. This is because the event name is not registered correctly.

I'm updating the event registration to be correct.

Changelog:
[Internal] [Changed] - Make IntArray events work on Bridgeless for RN-Tester

Reviewed By: cipolleschi

Differential Revision: D50266485

fbshipit-source-id: 13bbce91a41281383d4857048e573b6d9cc5387b

#publish-packages-to-npm

Summary:
Pull Request resolved: facebook#41055

This should fix the issue highlighted in [this comment](reactwg/react-native-releases#64 (comment)).
Basically, before the fix, we were not supporting flavours correctly, as we assumed that only Debug and Release were available.

With this change, we infer whether we have to fetch Hermes for Debug or Release based on the actual flags that are passed. In this way, the users can customize their app's flavors more freely.

## Changelog:
[Internal] - Support multiple flavors when downloading Hermes

Reviewed By: huntie

Differential Revision: D50408381

fbshipit-source-id: 6990218b286b4dd823323bc63de90279efc9e74e

Summary:
Pull Request resolved: facebook#41058

Glog has a piece of code which looks like this:
```
namespace google {

// They need the definitions of integer types.
#include "glog/log_severity.h"
#include "glog/vlog_is_on.h"
```

This fragment is:
- Always valid when the pod does not define a module
- Valid for Xcode >= 14.3, when the pod do define a module
- Invalid for Xcode < 14.3, when the pod do define a module

Modules are required to support Swift, so, in the long run, we want to have `DEFINES_MODULE` set to `YES` for `Glog`.

This is a temporary workaround to keep supporting older versions of Xcode while Apple keeps allowing to use Xcode 14.1 to submit apps to the store.
Historically, Apple pushes the minimum version of Xcode every April, so we expect to be able to remove this workaround in April 2024.

## Changelog:
[Internal] - Make Glog work with older versions of Xcode

Reviewed By: cortinico

Differential Revision: D50410487

fbshipit-source-id: 96145cdf9ba1bc75622403d3c06454d6d4bfd967

Summary:
Pull Request resolved: facebook#40732

This change allows the Fabric Interop Layer to work in bridgeless mode.

Given that the legacy components requires a Bridge to send events and use commands, this change simulates a bridge when it doesn't exists (i.e.: we are in bridgeless mode).

In order to make it work, we had to simulate a few elements from the Bridge and the UIManager.

## Changelog:
[iOS][Fixed] - Make the Fabric interop layer works in bridgeless mode.

## Facebook:
As an alternative approach, we could have created a `protocol RCTBridging`, have the `RCTBridge` conform to that protocol, and create a new type for it.
Practically this would have been much more cumbersome:
1. The [RCTBridge](https://www.internalfb.com/code/fbsource/[916531b9bf7a9943036807f7563c925b4c3e0101]/xplat/js/react-native-github/packages/react-native/React/Base/RCTBridge.h?lines=87-238) interface is quite big. All the props and method should be part of the protocol.
2. Extensions declared on RCTBridge would not have worked. For example, [`RCTBridge (RCTUIManager)`](https://www.internalfb.com/code/fbsource/[916531b9bf7a9943036807f7563c925b4c3e0101]/xplat/js/react-native-github/packages/react-native/React/Modules/RCTUIManager.h?lines=170-174).
3. It would require a major overhaul of the APIs, returning `id<RCTBridging>` in place of **every** function that takes/return an instance of `RCTBridge *`.

Clearly, not a feasible way to go.

Reviewed By: RSNara

Differential Revision: D50079929

fbshipit-source-id: 77d4370e9043c8e06b676bff3987511c042b0f9c

Summary:
Pull Request resolved: facebook#41159

Changelog: [Internal]

Cleanup from D48966244. The deprecated `jsinspector` files are no longer used by any code in either fbsource or `react-native`.

Reviewed By: hoxyq

Differential Revision: D50530796

fbshipit-source-id: b539b097cb6caf6c50a482fa93bf5d7886e76e52

cherry-pick 7853b06

Co-authored-by: Lulu Wu <luluwu@meta.com>
Co-authored-by: Gabriel Donadel <donadeldev@gmail.com>
fix `java.lang.NoSuchMethodError` for Bridgeless (facebook#41081)
resolved: facebook#41081
resolved: facebook#40999
resolved: facebook#41165
Fix RNTester not showing Redbox when Metro is not connected (facebook#41191)
resolved: facebook#41191
resolved: facebook#41190
resolved: facebook#41085
resolved: facebook#41206

Summary:
Original commit changeset: 93eba1eb3106

Original Phabricator Diff: D50694805

changelog: [internal] internal

Reviewed By: fkgozali

Differential Revision: D50853438

fbshipit-source-id: 687cb100dfea28f3ea63812e1dd5b21e4c8ceb0e

Summary:
Fixes: facebook#39524

## Changelog:

<!-- 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
-->
[ANDROID] [FIXED] - Fix textTransform not working in new architecture

Pull Request resolved: facebook#41223

Test Plan:
**Before:**
<img width="307" alt="image" src="https://github.com/facebook/react-native/assets/34857453/d44e6030-0a49-42c9-be44-cf7541583af0">

**After:**
<img width="307" alt="image" src="https://github.com/facebook/react-native/assets/34857453/fb717cec-72d3-41d7-8c48-4ec9a9ecb16b">

Reviewed By: javache

Differential Revision: D50773216

Pulled By: NickGerleman

fbshipit-source-id: 769bf67f2661ff4ff7b88121493bdd27564458d3

…acebook#41270)

Summary:
Pull Request resolved: facebook#41270

`scheduleCellsToRenderUpdate()` is called in response to new measurements, or component changes. It has logic to decide whether to immediately calculate new state, or to defer it until a later batched period.

It will not immediately update state if we don't yet have measurements for cells, but this condition is after another which calculates priority, relying on these measurements. These are garbage if we don't yet have measurements, and trigger an invariant violation in horizontal RTL.

This switches around the conditions, to avoid offset resolution if we don't yet have valid measurements.

I suspect some "hiPri" renders where cells shift are bugged right now when we update state in response to content size change, before we have new corresponding cell layouts.

Changelog:
[General][Fixed] - Bail on hiPri render on missing layout data before checking priority

Reviewed By: yungsters

Differential Revision: D50791506

fbshipit-source-id: 8dbffc37edd2a42f7842c0090d344dcd6f3e3c6d