Summary:
`#include <ReactCommon/RuntimeExecutor.h>` stopped working in react-native 0.81 when using frameworks because it is not part of ReactCommon anymore when the split happened for iOS.
to fix this I am including RuntimeExecutor in search headers same way we include ReactCommon.
## Changelog:
[IOS] [FIXED] - Fix import RuntimeExecutor.h with USE_FRAMEWORKS
Pull Request resolved: https://github.com/facebook/react-native/pull/53099
Test Plan:
You can enable USE_FRAMEWORKS and do `#include <react/renderer/uimanager/UIManager.h>` (which react-native-reanimated is doing).
Build will fail complaining that it can't find ReactCommon/RuntimeExecutor.h which is included in UIManager.h
Add my patch, it will work and build successfully
Reviewed By: cortinico
Differential Revision: D79796637
Pulled By: cipolleschi
fbshipit-source-id: f8bb669cfb9f4414653655ed98d2cc6bb431a3e5
Summary:
The `react-native/metro-config` peer was added in https://github.com/facebook/react-native/commit/fe2bcbf4ba7ce983fac0cd09727c165517b6337f / https://github.com/facebook/react-native/issues/51836 by robhogan
Side-note: It's pulled in via `react-native/community-cli-plugin` which is a direct dependency of `react-native` for the `scripts/bundle.js` script. While, for expo, we'd love to find a way to make this an optional dependency (to avoid excessive deps that `expo` replaces otherwise), for now, it's a direct dependency.
The problem here is that this isn't optional, which means:
- with auto-installing peer dependencies it is directly fulfilled (while `react-native-community/cli` is already marked as optional and skipped)
- with legacy/non-auto peer-dependencies it is flagged as missing, but in an Expo project it wouldn't make sense to install directly
This causes a **package manager regression in the form of either a peer dependency warning**, that shouldn't be fulfilled in an Expo project, or (in the best case scenario) pulls in dependencies [that a user does not need](https://npmgraph.js.org/?q=%40react-native%2Fmetro-config#zoom=w&select=exact%3A%40react-native%2Fmetro-config%400.81.0).
An error message is already in place to inform the user of this being missing when it's not installed, so marking it as optional seems appropriate.
## Changelog:
[INTERNAL] [FIXED] Mark added `react-native/metro-config` peer dependency as optional
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/53314
Test Plan:
Warnings like the following won't occur in fresh Expo (54/preview/`next`) projects
```
warning "workspace-aggregator-484d9ec3-587b-43cb-97de-4dcce3876578 > microfoam-mobile > react-native > react-native/community-cli-plugin@0.81.0" has unmet peer dependency "react-native/metro-config@*".
```
Reviewed By: cortinico
Differential Revision: D80450287
Pulled By: robhogan
fbshipit-source-id: c622fd4c24025676c0ec74de826f863f1e291669
* [ios][precompile] Add use_frameworks resolve method
To be able to handle cocoapods USE_FRAMEWORKS with both dynamic/static linkage and precompiled we needed a common way to resolve this.
The issue was that when using precompiled and USE_FRAMEWORKS our precompiled framework caused the resulting Pods project to only include header files - hence there where no need to change the header_mappings_dir which a lot of the podspecs did.
A method was added that handles this in a common way.
* [ios][precompile] added resolve_use_frameworks to podspecs
Replaced logic for resolving header mappings and module name using the new method `resolve_use_frameworks` in all podspecs.
Also added `React-oscompat` dependency on `React-jsiinspector_modern` which failed when linkage was "dynamic".
* [ios][precompile] added explicit handling of ReactCoden
When using precompiled and building with frameworks (USE_FRAMEWORKS) we need to explicitly add the correct path to ReactCodegen when calling `create_header_search_path_for_frameworks` to ensure libraries can access their codegen files.
This commit adds an explicit check to make sure we add the correct path when using frameworks and the pod is ReactCodegen.
Added includes in the NativeCXXModuleExample.cpp file to test this.
* Update packages/react-native/scripts/cocoapods/utils.rb
Co-authored-by: Riccardo Cipolleschi <cipolleschi@meta.com>
* codereview: removed test include files
* codereview: fixed issue in ruby.rb
After a github `suggestion` we had a superfluous `end`. Sorry for that.
---------
Co-authored-by: Christian Falch <christian.falch@gmail.com>
Co-authored-by: Christian Falch <875252+chrfalch@users.noreply.github.com>
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53013
Quick fix to restore CI on `main`. `actions/setup-node` is now pulling Node.js `24.5.0`, which introduces a bug affecting `packages/dev-middleware/src/__tests__/` Jest tests.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D79551277
fbshipit-source-id: 51951ad8ffe376a478da268b50aa54ac2d9bba03
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52803
I've just realized that our build suffer from a race condition. Specifically
libraries codegen needs to be executed before the app starts the evaluating CMake files.
Otherwise this could lead to a lot of missing files or folders.
Changelog:
[Android] [Fixed] - **rngp:** Fix a race condition with codegen libraries missing sources
Reviewed By: huntie
Differential Revision: D78886347
fbshipit-source-id: f59c201d2eab651bc4a08cf5a795acd379d18186
Summary:
bypass-github-export-checks
Pull Request resolved: https://github.com/facebook/react-native/pull/52783
This change reverts D78158734 which was a patch to make the dynamic frameworks work properly because we were not exporting the FBReactNativeSpec headers in prebuilds correctly.
This change fixes this, by exposritng those headers correctly.
[Internal] -
bypass-github-export-checks
Reviewed By: cortinico
Differential Revision: D78803425
fbshipit-source-id: 5613ed0c790455ea86668eeb436f7b78a0c80918
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52878
Now that Metro is bumped to also support node >= 20.19.4
we should be able to run test_js on `main` against 20.19.4
Changelog:
[Internal] [Changed] -
Reviewed By: robhogan, motiz88
Differential Revision: D79087608
fbshipit-source-id: 2161a893ab2fd88dc7eb1b35aa385704962018e8
Summary:
Hello, I work on [Radon IDE](ide.swmansion.com) I encountered an issue while adding support for react native 81, this PR solves it:
In https://github.com/facebook/react-native/issues/51023 EvanBacon removed `displayName` filed from `View` component adding the following comment:
>Remove displayName in favor of component name. I'm not 100% sure this is a full fallback but it is valid according to react/display-name eslint rule—https://github.com/jsx-eslint/eslint-plugin-react/blob/master/docs/rules/display-name.md
Unfortunately the Fabric renderer uses the `displayName` property to generate the name of the component for the inspector functionality and in absence of it generates a name that might be confusing to the end user:
<img width="351" height="283" alt="Screenshot 2025-07-17 at 21 27 37" src="https://github.com/user-attachments/assets/852246aa-6586-4684-b80e-5d70b9678c6e" />
Problem is not specific to Radon and happens in chrome devtools as well:
<img width="501" height="130" alt="Screenshot 2025-07-17 at 22 16 52" src="https://github.com/user-attachments/assets/3514dd02-59f7-473a-87b1-6ed325d2034c" />
This PR brings back the `displayName` property to fix that.
[INTERNAL] [FIXED] - Bring back the displayName property to the View component
Pull Request resolved: https://github.com/facebook/react-native/pull/52688
Test Plan:
- Run the application
- open chrome devtools and navigate to "components" tab
- before changes the View components would show up as `View_withRef` after they are named `View`
Rollback Plan:
Reviewed By: lunaleaps, cortinico
Differential Revision: D78512254
Pulled By: alanleedev
fbshipit-source-id: 46e4a224b09fe3fb938c055a675f687c86d7ddcb
Co-authored-by: filip131311 <159789821+filip131311@users.noreply.github.com>
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52660
The documentation for those methods mention that users should override them to
provide their own implementation.
However those vals are not `open` so users cannot really override them.
This fixes it.
See more context on https://github.com/facebook/react-native/pull/48800#issuecomment-3082665024
So this was practically a breaking change, that I'm attempting to mitigate.
Changelog:
[Android] [Fixed] - Make accessors inside HeadlessJsTaskService open again
Reviewed By: cipolleschi
Differential Revision: D78479162
fbshipit-source-id: eefc7332e2004198cd6bd64b60a66215f137ad4a
* Clean up feature flag preventShadowTreeCommitExhaustionWithLocking (#52791)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52791
Changelog: [internal]
This cleans up this feature flag as it doesn't work as intended. We'll try another approach with a different flag instead.
Reviewed By: sammy-SC
Differential Revision: D78815892
fbshipit-source-id: 4c651a3a225de9cfb54d00346343c7f2e3bea1d5
* Implement solution for ShadowTree commmit exhaustion using recursive locks (behind a flag) (#52795)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52795
Changelog: [internal]
This is another attempt to fix https://github.com/facebook/react-native/issues/51870, inspired by https://github.com/facebook/react-native/pull/52314 but gated behind a feature flag until we've tested it carefully.
Reviewed By: sammy-SC
Differential Revision: D78817100
fbshipit-source-id: 45e6cae019b212528f2b2e74b9f52fe43d07f537
* [LOCAL] Correctly sort preventShadowTreeCommitExhaustion after merge conflict
---------
Co-authored-by: Rubén Norte <rubennorte@meta.com>
* Lower minimum Node.js version to 20.19.4 (#52678)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52678
From partner feedback, there's still appetite to support Node 20.x for the next <1y of life. Lower min version to `20.19.4` (Jul 2025) and widen test matrix in CI.
Changelog:
[General][Breaking] - Our new minimum Node version is Node.js 20 (Overrides #51840)
Reviewed By: cortinico
Differential Revision: D78494491
fbshipit-source-id: c8d9dc6250cb11f8a12ca7e761b65f4a8dae9265
* Bump Metro to ^0.83.1, lower minimum Node.js version to 20.19
Summary:
Metro release notes: https://github.com/facebook/metro/releases/tag/v0.83.1
The only public-facing change is a lowering of the minimum Node.js version from 22.14 to 20.19.
This will need picking to RN `0.81-stable`
Changelog: [General][Changed] Metro to ^0.83.1
Reviewed By: huntie
Differential Revision: D78895160
fbshipit-source-id: b9ccffe972249b73897f51c14873861e57a97161
* Do not setup-node twice in test_js (#52737)
Summary:
I've noticed that test_js (20) and test_js (24) are actually running on Node 22.
That's because the `yarn-install` action is invoking setup-node again with the default value (22).
This changes it. Also I'm cleaning up the workflows so that every `yarn-install` invocation is happening just after the `setup-node` invocation.
## Changelog:
[INTERNAL] -
Pull Request resolved: https://github.com/facebook/react-native/pull/52737
Test Plan: CI which will most likely be red for test_js (20) so will need a follow-up
Reviewed By: cipolleschi
Differential Revision: D78664671
Pulled By: cortinico
fbshipit-source-id: c73390930d1511d1bf0f2d4ea92e83f50b10247f
---------
Co-authored-by: Alex Hunt <huntie@meta.com>
Co-authored-by: Rob Hogan <robhogan@meta.com>
Co-authored-by: Nicola Corti <ncor@meta.com>
* Implement mechanism to prevent ShadowTree commit exhaustion (#52645)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52645
Changelog: [internal]
This add a new feature flag to test a fix for https://github.com/facebook/react-native/issues/51870
Reviewed By: cortinico, sammy-SC
Differential Revision: D78418504
fbshipit-source-id: 2792026b6936393d196fd1e3162f8b2c61a38ed6
* Fix incorrect locking and attempts check in ShadowTree experiment (#52681)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52681
Changelog: [internal]
In the original change I made in D78418504 / https://github.com/facebook/react-native/pull/52645 I made 2 mistakes:
1. Used a lock that would try to re-lock on itself without it being recursive (which would cause a deadlock). I didn't see that because when testing I didn't hit the case where we'd exhaust the options.
2. The `attemps` variable wasn't incremented, so we never left the loop in case of exhaustion.
This propagates a flag to `tryCommit` to indicate we've already locked on the commitMutex_ so we don't need to lock again in that case and increases the counter, fixing the issue.
Reviewed By: cortinico
Differential Revision: D78497509
fbshipit-source-id: 546ccd0c84aed5416ce1aef47d79419b4fe06f66
* Rollout `preventShadowTreeCommitExhaustionWithLocking` in experimental (#52709)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52709
We want to make user for folks in OSS to try
`preventShadowTreeCommitExhaustionWithLocking`. Therefore I'm updating the OSS
release channel for this flag to experimental.
Changelog:
[Internal] [Changed] - Rollout `preventShadowTreeCommitExhaustionWithLocking` in experimental
Reviewed By: rubennorte
Differential Revision: D78558655
fbshipit-source-id: 02a9d216c7b2f8f7bdc1340213f82b70c5692dc7
---------
Co-authored-by: Rubén Norte <rubennorte@meta.com>
Summary:
When switching between debug/release we run a small script to make sure to copy the correct version of the RNDeps xcframework.
This script was missing a resolve function that fixed up some path issues that we do when installing in the podspec.
## Changelog:
[IOS] [FIXED] - Fixed issue with RNDeps release/debug switch failing
Pull Request resolved: https://github.com/facebook/react-native/pull/52664
Test Plan:
- Create new RN App
- Install pod with prebuilt deps
- Build (success)
- Switch to release
- Build (success)
Reviewed By: cortinico
Differential Revision: D78481590
Pulled By: cipolleschi
fbshipit-source-id: 2d02b0bc55e8aef6f3fafb4f7aa193c4cf00414e
Summary:
When switching between release/debug we're running a script to copy the correct xcframework. This script for the React-Core prebuilts was not part of the package.json file.
This caused the build to fail after trying to switch from debug -> release.
## Changelog:
[IOS] [FIXED] - Fixed missing script for resolving prebuilt xcframework when switching between release/debug
Pull Request resolved: https://github.com/facebook/react-native/pull/52663
Test Plan:
- Create new RN App
- Install pod with prebuilt deps and core
- Build (success)
- Switch to release
- Build (success)
Reviewed By: cortinico
Differential Revision: D78481302
Pulled By: cipolleschi
fbshipit-source-id: 1c7181e63219098ae140d77ff1cb2c0c9b9642e5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52625
Changes `react-native/babel-preset` so that by default, `hermes-parser` is configured with `reactRuntimeTarget: "19"`. This changes the compiled output of Component Syntax to not use `forwardRef` when a `ref` prop is present.
Additionally, this adds a new preset option property, `hermesParserOptions`. This object allows users of `react-native/babel-preset` to supply overrides for any `hermes-parser` options.
Changelog:
[General][Changed] - Configures `react-native/babel-preset` to target React 19 by default, meaning Component Syntax will not compile to `forwardRef` calls when a `ref` prop is present.
[General][Added] - Added support to `react-native/babel-preset` for a `hermesParserOptions` option, that expects an object that enables overriding `hermes-parser` options.
Reviewed By: SamChou19815
Differential Revision: D78383269
fbshipit-source-id: 1e6b66b9bfbeaf8a06fdc39031cb6de7e921765f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52530
This PR fixes two issues with `display: contents` implementation:
1. When a node with `display: contents` set is a leaf, it won't be cloned after the initial tree is built. The added test case covers this scenario.
2. It was possible for the subtree of `display: contents` nodes not to be cloned during layout. I don't have a minimal reproduction for this one, unfortunately. It was discovered in the Expensify app: https://github.com/Expensify/App/issues/65268, along with a consistent reproduction. In that specific case, it seems to be heavily tied to `react-native-onyx`, which is a state management library.
Changelog: [GENERAL][FIXED] - Fixed nodes with `display: contents` set being cloned with the wrong owner
X-link: https://github.com/facebook/yoga/pull/1826
Reviewed By: adityasharat, NickGerleman
Differential Revision: D78084270
Pulled By: j-piasecki
fbshipit-source-id: eb81f6d7dcd1665974d07261ba693e2abea239bb
Summary:
Instead of returning when creating the list of header files from our podspecs, we now call `continue`. This is a bug that causes all subsequent globs in the header file list to be omitted after the first omitted glob.
bypass-github-export-checks
## Changelog:
[IOS] [FIXED] - Fixed premature return in header file generation from podspec globs
Pull Request resolved: https://github.com/facebook/react-native/pull/52490
Test Plan: Run prebuild scripts and verify that React-Fabric podspec headers are included in the resulting xcframework.
Reviewed By: mdvacca
Differential Revision: D78012399
Pulled By: cipolleschi
fbshipit-source-id: 2d334f4f7ff966ea4c778786a7056e13a255a708
Summary:
This PR (initially created for edge-to-edge opt-in support, rebased multiple times) fixes the `Dimensions` API `window` values on Android < 15, when edge-to-edge is enabled.
Currently the window height doesn't include the status and navigation bar heights (but it does on Android >= 15):
<img width="300" alt="Screenshot 2025-06-27 at 16 23 02" src="https://github.com/user-attachments/assets/c7d11334-9298-4f7f-a75c-590df8cc2d8a" />
Using `WindowMetricsCalculator` from AndroidX:
<img width="300" alt="Screenshot 2025-06-27 at 16 34 01" src="https://github.com/user-attachments/assets/7a4e3dc7-a83b-421b-8f6d-fd1344f5fe81" />
Fixes https://github.com/facebook/react-native/issues/47080
## Changelog:
[Android] [Fixed] Fix `Dimensions` `window` values on Android < 15 when edge-to-edge is enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/47554
Test Plan:
Run the example app on an Android < 15 device.
Rollback Plan:
Reviewed By: cortinico
Differential Revision: D77547628
Pulled By: alanleedev
fbshipit-source-id: 9d841f642d5b7ef3294dfbf3868137087a672ad6
Summary:
This change tries to use the prebuilds we build in CI i other iOS jobs to speed-up the iOS CI
bypass-github-export-checks
## Changelog:
[Internal] -
Pull Request resolved: https://github.com/facebook/react-native/pull/52531
Test Plan:
Build rntester using prebuilds:
```
# after downloading the prebuilds from CI and unzipping them
export HERMES_ENGINE_TARBALL_PATH=~/Downloads/hermes-ios-Debug.tar.gz
export RCT_USE_LOCAL_RN_DEP=~/Downloads/reactnative-dependencies-debug.tar.gz
export RCT_TESTONLY_RNCORE_TARBALL_PATH=~/Downloads/React.xcframework.tar.gz
USE_FRAMEWORKS=dynamic bundle exec pod install
open RNTesterPods.xcworkspace
```
And then build from Xcode.
Reviewed By: rshest
Differential Revision: D78158734
Pulled By: cipolleschi
fbshipit-source-id: 43cbb66bd44fa621292b69de0dadde5ed20c4574
Summary:
This PR fixes the following build error while trying to build `react-native@0.81.0-rc.0` app with `react-native-screens@4.10.0` installed using react-native prebuilds (AAR) due to a missing `react/renderer/bridging/bridging.h` file in `prefab/modules/` inside `react-android-0.81.0-rc.0-debug.aar`.
```
In file included from /Users/tomekzaw/RNOS/react-native-reanimated/node_modules/react-native-screens/android/src/main/cpp/NativeProxy.cpp:2:
In file included from /Users/tomekzaw/.gradle/caches/8.14.1/transforms/75e7f8f7b5ef763e687a16737daf01b6/transformed/react-android-0.81.0-rc.0-debug/prefab/modules/reactnative/include/react/fabric/Binding.h:12:
In file included from /Users/tomekzaw/.gradle/caches/8.14.1/transforms/75e7f8f7b5ef763e687a16737daf01b6/transformed/react-android-0.81.0-rc.0-debug/prefab/modules/reactnative/include/react/fabric/FabricUIManagerBinding.h:22:
/Users/tomekzaw/.gradle/caches/8.14.1/transforms/75e7f8f7b5ef763e687a16737daf01b6/transformed/react-android-0.81.0-rc.0-debug/prefab/modules/reactnative/include/react/renderer/uimanager/primitives.h:14:10: fatal error: 'react/renderer/bridging/bridging.h' file not found
14 | #include <react/renderer/bridging/bridging.h>
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
ninja: build stopped: subcommand failed.
```
## Changelog:
[ANDROID] [CHANGED] - Expose `react_renderer_bridging` headers via prefab
Pull Request resolved: https://github.com/facebook/react-native/pull/52529
Reviewed By: cipolleschi
Differential Revision: D78092428
Pulled By: cortinico
fbshipit-source-id: de8208ae7545201f600c277a0c8907575c310c58
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52528
This was a breaking change that is currently breaking `react-native-safe-area-context` so we can't ship it as it is, especially because all the apps in OSS will be affected by this.
Changelog:
[General] [Changed] - Revert breaking change due to the removal of `ShadowNodeTraits::Trait::DirtyYogaNode`
Original commit changeset: 869e81f0ae00
Original Phabricator Diff: D75324251
Reviewed By: huntie
Differential Revision: D78085848
fbshipit-source-id: f7fcc5e33d59cc966a4ee88dfdbedca4f4c580e0
Summary:
Fixes #T228219721
This commit adds the debug/release switch script like we have for rn deps and hermes for react-core prebuilt:
- Added script: replace-rncore-version-js
- Inserted script into React-Core-prebuilt podspec
- Updated rncore.rb with correct filenames
bypass-github-export-checks
## Changelog:
[IOS] [ADDED] - add release/debug switch script for React-Core-prebuilt
Pull Request resolved: https://github.com/facebook/react-native/pull/52498
Test Plan: Run in RNTester and switch between release/debug
Reviewed By: rshest
Differential Revision: D78012917
Pulled By: cipolleschi
fbshipit-source-id: 71cad23cd41484a8253fc89d5dce8653649657a0
Summary:
When using prebuilts the USE_FRAMEWORKS setting is not really relevant for the React Native code, since there will not be any source code to build frameworks for - and because we already have a framework for the code in React.XCFramework.
This commit adds a new command to the React Native podspecs like we did with the ReactNativeDependencies framework. The method is called `add_rncore_dependency` and it does nothing when building from source - but when linking with the React.XCFramework it explicitly adds linking with the framework.
In addition there are a few places in the ruby code where we check for the USE_FRAMEWORK value and changes some settings - where needed this commit will add a separate check to ensure we're building from source when making these changes.
bypass-github-export-checks
## Changelog:
[IOS] [ADDED] - Added support for using USE_FRAMEWORKS with prebuilt React Native Core
Pull Request resolved: https://github.com/facebook/react-native/pull/52489
Test Plan:
RNTester:
- Builds without USE_FRAMEWORKS as before with/without prebuilt
- Builds with USE_FRAMEWORKS=dynamic as before with source - and now also with prebuilt code.
- Same goes for the static variant.
Reviewed By: mdvacca
Differential Revision: D78012332
Pulled By: cipolleschi
fbshipit-source-id: ea942738ae52b9dceae48fb78a5026f04b7545b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52513
We bumped the requirement for cocoapods to use Xcode 16.1 or greater.
This job was not update and therefore it failed when releasing 0.81.0-rc.0.
This change should fix it and it should be cherry picked in the release branch too.
By default, the macos executor in github actions are using Xcode 15.2
## Changelog
[Internal] -
Reviewed By: cortinico, fabriziocucci
Differential Revision: D78008316
fbshipit-source-id: 4d05233ca3b936cf128400030328124c453963ea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52512
The way Maven works is that the artifacts are uploaded and available way before the browsing UI will allow us to browse them.
By trying to download the `.pom` file instead of checking for the browsing website to be visible, we can shave some minutes during the release
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D78008635
fbshipit-source-id: 96516163628d6d25db385d996a11b4af78db764a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52514
As per title, this change add the `ENTERPRISE_REPOSITORY` env variable so that users can use their owm maven mirror to consume artifacts rather than the official url.
This is helpful as:
- we can reduce the traffic toward maven central
- companies can speed up their builds by relying on local/closer replicas
## Changelog:
[iOS][Added] - Add the `ENTERPRISE_REPOSITORY` env variable to cocopaods infra
Reviewed By: cortinico
Differential Revision: D78011424
fbshipit-source-id: 24b83b4866095d7fe3318362afc5075b99b146e7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52399
I'm raising the deprecation warnings for those methods that are using legacy arch.
Previously the `DeprecatedInNewArchitecture` was not generating warnings for user in their builds, while now the Kotlin's/Java's `DeprecatedInNewArchitecture` it will.
Changelog:
[Android] [Changed] - Introduce more deprecation warnings for Legacy Arch classes
Reviewed By: mdvacca
Differential Revision: D77736713
fbshipit-source-id: bc21729ed8253d3ec6b6a40577bcd76622c3f8a6
Sharif Mahmoud
Phil Pluckthun
React Native Bot
Vitali Zaidman
lukmccall
Alex Hunt
Nicola Corti
Moti Zilbermanandfilip131311
Nick Gerleman
Tim Yung
Jakub Piasecki
Mathieu Acthernoene
Tomasz Zawadzki
Rob Hogan