Revert D49509633: Multisect successfully blamed "D49509633: [react-native][PR] fix: Text cut off issues when adjusting text size and font weight in system settings" for test or build failures

Summary:
This diff is reverting D49509633
D49509633: [react-native][PR] fix: Text cut off issues when adjusting text size and font weight in system settings by ryancat has been identified to be causing the following test or build failures:

Tests affected:
- [xplat/endtoend/jest-e2e/apps/facebook_xplat/ReactNativeTTRCTester/__tests__/ReactNativeTTRCTester-errorReportedManually-android-e2e.js](https://www.internalfb.com/intern/test/281475019301157/)

Here's the Multisect link:
https://www.internalfb.com/multisect/3131615
Here are the tasks that are relevant to this breakage:

We're generating a revert to back out the changes in this diff, please note the backout may land if someone accepts it.

If you believe this diff has been generated in error you may Commandeer and Abandon it.

Reviewed By: NickGerleman

Differential Revision: D49645585

fbshipit-source-id: 414531e067cffa109d0663d6af185dcaf8fb9c4e

Summary:
This is my proposed solution to https://github.com/facebook/react-native/issues/41677.

Fixes https://github.com/facebook/react-native/issues/41677.

## Changelog:

[ANDROID] [FIXED] - Fix android root view group removal during instance re-creation

Pull Request resolved: https://github.com/facebook/react-native/pull/41678

Test Plan:
Both with fabric enabled and disabled (new architecture):

1. Clone repro repo: https://github.com/wschurman/rn-reload-repro
2. Build and run on android (I use android studio)
3. Click reload button, see timestamp doesn't change (indicating that the view is not removed)
4. Apply this PR as a patch.
5. Re-build and run.
6. Click reload button, see view is correctly disposed of and the new view is set.

Reviewed By: cortinico

Differential Revision: D51658524

Pulled By: javache

fbshipit-source-id: d9a026cde677ad1ec113230bc31bd9297bca8bfc

#publish-packages-to-npm

Summary:
`build_codegen!` currently assumes that `react-native/codegen` gets installed next to `react-native`. In a pnpm setup, it's found under `/~/react-native/node_modules/react-native/codegen` instead.

However, as dmytrorykun pointed out, we don't actually need to build it outside of this repository.

## Changelog:

[GENERAL] [FIXED] - `react-native/codegen` shouldn't be built unless it's in the repo — fixes `pod install` failures in pnpm setups

Pull Request resolved: https://github.com/facebook/react-native/pull/41399

Test Plan: We have a patched version of `react-native` working in a pnpm setup here: https://github.com/microsoft/rnx-kit/pull/2811

Reviewed By: dmytrorykun

Differential Revision: D51201643

Pulled By: cipolleschi

fbshipit-source-id: 53767ae08686a20f03b3b93abcbc7d5383083872

In pnpm setups, codegen will fail during build because it cannot find
its dependencies. Some of the dependencies it relies on at runtime are
currently declared under `devDependencies`. This change moves them to
`dependencies`.

#publish-packages-to-npm

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41621

Currently, if you have a dependency that is alphabetically smaller than `app`, it's evaluation will happen before `app`.
This means that the namespace auto-discovery and the JVM toolchain configuration won't be working and the project will fail to buid.

This fixes it by introducing a root-project Gradle Plugin that takes care of enforcing the evaluation order on the `app` project.

Fixes #41620

Changelog:
[Android] [Fixed] - Fix projects being broken on dependencies starting with `a..`

Reviewed By: huntie

Differential Revision: D51547294

fbshipit-source-id: 65df7149548b7087dd8928e556fb803b3baf7b79

This reverts commit 02a411e9.

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41614

Fixes https://github.com/facebook/react-native/issues/41545

SafeAreaView works by adding padding in order to shift content out of the safe area. This may change the layout dimensions of the SafeAreaView, in turn effecting its safe area insets.

This can cause layout results to change, which in turn changes the inset value. Because of this, there is a tolerance, where safe area inset changes do not trigger a new update.

Yoga is instructed to round layout dimensions to the closest physical pixel, so a very small difference in layout may result being off by about a pixel. Right now the tolerance is exactly one physical pixel, and if there is FP error here, we may not pass the test, and start oscillating with different layout values.

After changing affected ShadowNode order to always be root-first, the first call to set the frame of the `SafeAreaView` happens when a non-zero-sized RootView is present, which I think may lead to a safe area inset update communicated that wasn't before? Or other cosmic butterflies. Layout rounds to one physical pixel in difference, and our tolerance is `0.00001` dips off (not helped that 1/3 screen scale cannot be represented as decimal, even without FP error).

This adds a small tolerance beyond just the pixel boundary, matching the logic in Fabric, which seems to resolve the issue.

Changelog:
[iOS][Fixed] - FP Tolerance in iOS Paper SafeAreaView debouncing

Reviewed By: philIip

Differential Revision: D51539091

fbshipit-source-id: 88bddc38c7cd8d93feef5f12da64b124af22f46d

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41535

## Context

**Remote JS Debugging removal**

In React Native 0.73, we have deprecated Remote JS Debugging (execution of JavaScript in a separate V8 process) and also removed the Dev Menu launcher (https://github.com/facebook/react-native/pull/36754).

## This diff

Follows D46187942 — this option wasn't correctly removed for Android when running JSC. This is now consistent with iOS.

Changelog:
[Android][Changed] "Open Debugger" is no longer available for remote JS debugging from the Dev Menu (non-Hermes). Please use `NativeDevSettings.setIsDebuggingRemotely()`.

Reviewed By: blakef

Differential Revision: D50555095

fbshipit-source-id: 1aeb48ab1390dc12ce300d6f321c30de5343cf0a

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41573

Changelog: [iOS][Fixed] RNTester-ios / RCTAppDelegate > correctly check for USE_HERMES Flag

On iOS we check for ENV flags if Hermes should be used:
- https://github.com/facebook/react-native/blob/b4d4aef057ebf90176287f22d72b4b3b8b280c9a/packages/react-native/React-Core.podspec#L24
- https://github.com/facebook/react-native/blob/b4d4aef057ebf90176287f22d72b4b3b8b280c9a/packages/react-native/React/React-RCTFabric.podspec#L90

and add necessary C++ packages based on that flag.

In code we do check for those imports
https://github.com/facebook/react-native/blob/b4d4aef057ebf90176287f22d72b4b3b8b280c9a/packages/react-native/Libraries/AppDelegate/RCTAppSetupUtils.h#L16-L27

and decided if we should use Hermes or not.

However the .mm check is faulty and does not check for the `RCT_USE_HERMES` flag set in code.

Reviewed By: fkgozali

Differential Revision: D51483740

fbshipit-source-id: 428c27aae80fe6f9799cf6ae21a5d3801fe6ca11

#publish-packages-to-npm

#publish-packages-to-npm

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41036

Changelog:
[Added] - Shipping the new event dispatching pipeline that immediately moves events over to the C++ queue. This should unblock useDeferredValue + useTransition interruptibility on Android.

Reviewed By: javache

Differential Revision: D50365981

fbshipit-source-id: ecf60e5bc29fb4568463568a6ede4330e0294fd3

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39671

Since minsdk version was increased to 23, we are deleting code using Android APIs < 23 for class ReactEditText

changelog: [Android][Breaking] Remove support for Android API < 23 in ReactEditText

Reviewed By: NickGerleman

Differential Revision: D48545507

fbshipit-source-id: 98be52ba36248962864e99e80ff648bbb351ff61

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41499

After D48152876 we consume JSI from `ReactCommon/jsi`, and ignore JSI that is distributed with `hermes-engine`.
This diff removes `include/jsi` from `source_files` of `hermes-engine` so we don't get two sets of JSI headers - one from `ReactCommon`, and the other one from `hermes-engine`.
This diff also fixes accidental breakage of ODR violation. We will no longer compile JSI into `react-native` when linking against `hermes-engine`, which already has JSI in it.
Changelog: [iOS][Fixed] - Exclude JSI headers when using hermes-engine prebuilt.

Reviewed By: cipolleschi

Differential Revision: D51347562

fbshipit-source-id: 6e4b9940c43d74d227a05999926b8752d7685670

Summary:
Recently, both `metro-inspector-proxy`(https://github.com/facebook/react-native/pull/39045) and `react-native-community/cli-plugin-metro`(https://github.com/facebook/react-native/pull/38795) were moved to this repo and in the process of moving these packages, the `exports` field inside package.json was added, only exporting the `index.js` file.

The problem is that Expo CLI (and possibly other community packages) rely on functions and classes that are not exported in the `index.js` file, e.g. Importing the InspectorProxy class from `react-native/dev-middleware/dist/inspector-proxy/InspectorProxy`. Normally this wouldn't be a problem and we would just import from `dist/` but due to the `exports` field, attempting to import from any other file not specified on this field will result in a `ERR_PACKAGE_PATH_NOT_EXPORTED` error.

As a short-term fix, we should create `unstable_`-prefixed exports of individual features Expo currently depends on.

## Changelog:

[INTERNAL] [CHANGED] - Expose unstable_InspectorProxy and unstable_Device from `react-native/dev-middleware`

Pull Request resolved: https://github.com/facebook/react-native/pull/41370

Test Plan: N / A

Reviewed By: robhogan

Differential Revision: D51163134

Pulled By: blakef

fbshipit-source-id: e67adaedc4fc64131e4c9dd8383c9877b8202283

Summary:
Talking about Paper & iOS here.

In standard RN applications when a native component is removed permanently from view hierarchy [it is invalidated (if it implements `RCTInvalidating`)](https://github.com/facebook/react-native/blob/e64756ae5bb5c0607a4d97a134620fafcb132b3b/packages/react-native/React/Modules/RCTUIManager.m#L483-L495). Components that implement `RCTInvalidating` such as [`RNSScreenView`](https://github.com/software-mansion/react-native-screens/blob/9fb3bd00850bcdf29b46daa57e56eabda3ae30ea/ios/RNSScreen.mm#L35) of [`react-native-screens`](https://github.com/software-mansion/react-native-screens) library rely on `RCTInvalidating#invalidate` method being called in adequate moment to release retained resources (in my case the `RNSScreenView` holds a strong reference to it's view controller preventing it from being garbage collected).

However in case of brownfield applications (React Native is used only for a particular view & loaded on demand, see: https://github.com/software-mansion/react-native-screens/issues/1754 for discussion & app example) when view controller holding `RCTRootView` is dismissed and whole `React Native` managed view / controller tree gets deallocated, `RCTInvalidating#invalidate` method is not called on the dismissed components, thus in my particular use case, leading to memory leak.

Right now I've added call to `RCTUIManager#_purgeChildren:fromRegistry:` (which internally invalidates all components which implement `RCTInvalidating`) in `RCTUIManager#invalidate`.

## Changelog:

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

Pick one each for the category and type tags:

[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message

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

[IOS][FIXED] - Purge children from view registry on `RCTUIManager` invalidation.

Pull Request resolved: https://github.com/facebook/react-native/pull/38617

Test Plan:
You can run the [demo](https://github.com/mkondakov/RNSScreensMemoryLeak) provided in the [issue](https://github.com/software-mansion/react-native-screens/issues/1754).

Following screenshots show that memory leak in brownfield application is resolved.

Without the change (`invalidate` method is not being called on native components)

![image](https://github.com/facebook/react-native/assets/50801299/dac331c2-1e7c-4e66-a8c1-b88f7a007d9b)

With the change:

![image](https://github.com/facebook/react-native/assets/50801299/7a8afbe9-446c-47a2-a972-d7589b921677)

Reviewed By: NickGerleman

Differential Revision: D49952215

Pulled By: javache

fbshipit-source-id: 6336b86774615acc40279c97e6ae0bb777bda8ad

resolved: https://github.com/facebook/react-native/pull/41353
resolved: https://github.com/facebook/react-native/pull/41354
resolved: https://github.com/facebook/react-native/pull/41355
resolved: https://github.com/facebook/react-native/pull/41356
resolved: https://github.com/facebook/react-native/pull/41357
resolved: https://github.com/facebook/react-native/pull/41358
resolved: https://github.com/facebook/react-native/pull/41359

#publish-packages-to-npm

Summary:
There is a problem in the way that we check if Fabric is enabled inside `react_native_post_install`.

https://github.com/facebook/react-native/blob/899e7cdb55197fc17a96a93af4f8bcc7519553c2/packages/react-native/scripts/react_native_pods.rb#L239

We're determining if fabric is enabled by checking if the `React-Fabric pod `is present, but since we always call `setup_fabric!(:react_native_path => prefix)`  (https://github.com/facebook/react-native/pull/39057) inside `use_react_native` the `React-Fabric` pod is always present causing the `-DRN_FABRIC_ENABLED` flag to always be added to `project.pbxproj` even if the new arch is disabled.

[IOS] [FIXED] - Fix ios pod post_install logic for detecting if fabric is enabled

Pull Request resolved: https://github.com/facebook/react-native/pull/41284

Test Plan: Run `use_react_native!(fabric => false)` should not add the `-DRN_FABRIC_ENABLED` flag to `project.pbxproj`

Reviewed By: fkgozali

Differential Revision: D50896487

Pulled By: cipolleschi

fbshipit-source-id: 78154407ce52b09fd3a317b7dc64bd4bba56363e

Summary:
This should fix
https://github.com/facebook/react-native/issues/37905#issuecomment-1774851214

When working on react-native-fast-image, we realized that the interop layer does not work for components where the exported name is different from the iOS class.

To fix this, we can use the Bridge to retrieve the actual view manager, given the component name.

This solution should be much more robust than making assumptions on the ViewManager name, given the ComponentName.

On top of that, we realized tha the interop layer was not calling `didSetProps` after setting the props, so we are invoking that.

bypass-github-export-checks

[iOS][Fixed] - Add support for Components with custom names in the interop layer.

Pull Request resolved: https://github.com/facebook/react-native/pull/41207

Test Plan: Tested locally on an app created in 0.72 and 0.73 in Bridge and Bridgeless mode.

Reviewed By: cortinico

Differential Revision: D50698172

Pulled By: cipolleschi

fbshipit-source-id: 49aee905418515b0204febbbe6a67c0114f37029

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40869

Bumps DRNPT to v5 - the significant change is that this one depends on `react-native/normalize-color: ^0.73.0`, instead of `*`, so is protected from future breaking changes to that package.

NOTE: We can't safely include `react-native/normalize-color: ^0.74.0` in the dependency range of DRNPT because `0.74.0` isn't a semver-compliant release (0.74 isn't cut yet), so this will pull 0.73.2 from NPM, which is fine.  We may need to publish DRNPT@6 if 0.74 final turns out to contain breaking changes (eg, a Node 20 bump).

Changelog:
[General][Fixed] Update `deprecated-react-native-prop-types` to remove fragile transitive `*` dependencies.

Reviewed By: huntie

Differential Revision: D50228564

fbshipit-source-id: 01aafafad40d9a93d00de2b5f45d2796620b9b5d