Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52033
This change fixes the download of the artefacts for the nightlies of Hermes and React Native Dependencies after we changed the publishing logic for Maven
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D76723289
fbshipit-source-id: 6b0ea6a6c35125e6fb03cecc6be893bd02abdad8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51946
This change simplified the setp disallowing to use JSC from core.
As a side effect, it simplified the setup by always falling back to hermes if the users decides not to use the third party JSC
## Changelog:
[iOS][Removed] - remove the option to use JSC from core
Reviewed By: cortinico
Differential Revision: D76342625
fbshipit-source-id: c925ab4fab1e171e289a1c5f75890c92da1b3f08
Summary:
I am not sure exactly why, but I've been getting this error when running RNTester on iOS, when it tries to build hermesc from source. We're clearing the env using `env -i` which seems to cause the issue. If I add PATH to the env we set then it builds fine.
```
++ hermesc_dir_path=/Users/janicduplessis/Developer/react-native/packages/rn-tester/Pods/hermes-engine/build_host_hermesc
++ shift
++ jsi_path=/Users/janicduplessis/Developer/react-native/packages/rn-tester/Pods/../../react-native/ReactCommon/jsi
+++ xcode-select -p
++ SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
++ env -i SDKROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk /opt/homebrew/bin/cmake -S /Users/janicduplessis/Developer/react-native/packages/rn-tester/Pods/hermes-engine -B /Users/janicduplessis/Developer/react-native/packages/rn-tester/Pods/hermes-engine/build_host_hermesc -DJSI_DIR=/Users/janicduplessis/Developer/react-native/packages/rn-tester/Pods/../../react-native/ReactCommon/jsi
CMake Error: CMake was unable to find a build program corresponding to "Unix Makefiles". CMAKE_MAKE_PROGRAM is not set. You probably need to select a different build tool.
CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!
Command PhaseScriptExecution failed with a nonzero exit code
```
## Changelog:
[INTERNAL] [FIXED] - Fix RNTester hermesc build issue on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/51989
Test Plan: Build RN tester locally
Reviewed By: cortinico
Differential Revision: D76606335
Pulled By: cipolleschi
fbshipit-source-id: f442b77aefb3afacd6d9fb1f3d515b8d63c526ba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52020
Aligns the type exports of `ReportFullyDrawnView` across platforms, so that they are resilient to any changes made to `View` itself.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D76638685
fbshipit-source-id: 612b2bcd76e70751aec691a24f31beca453cea35
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51425
# Problem
React native's new architecture will allow components to do sync render/events. That means they'll makes synchronous dispatches from main thread to the js thread, to capture the runtime so that they can execute js on the main thread.
But, the js thread already as a bunch of synchronous calls to the main thread. So, if any of those js -> ui sync calls happen concurrently with a synchronous render, the application will deadlock.
This diff is an attempt to mitigate all those deadlocks.
## Context
How js execution from the main thread works:
* Main thread puts a block on the js thread, to capture the js runtime. Main thread is put to sleep.
* Js thread executes "runtime capture block". The runtime is captured for the main thread. The js thread is put to sleep.
* Main thread wakes up, noticing that the runtime is captured. It executes its js code with the captured runtime. Then, it releases the runtime, which wakes up the js thread. Both the main and js thread move on to other tasks.
How synchronous js -> main thread calls work:
* Js thread puts a ui block on the main queue.
* Js thread goes to sleep until that ui block executes on the main thread.
## Deadlock #1
**Main thread**: execute js now:
* Main thread puts a block on the js queue, to capture the runtime.
* Main thread then then goes to sleep, waiting for runtime to be captured
**JS thread**: execute ui code synchronously:
* Js thread schedules a block on the ui thread
* Js thread then goes to sleep, waiting for that block to execute.
**Result:** The application deadlocks
| {F1978009555} | {F1978009612} |

## Deadlock #2
**JS thread**: execute ui code synchronously:
* Js thread schedules a block on the ui thread
* Js thread then goes to sleep waiting for that block to execute.
**Main thread**: execute js now:
* Main thread puts a block on the js queue, to capture the runtime.
* Main thread then then goes to sleep, waiting for runtime to be captured
**Result:** The application deadlocks
| {F1978009690} | {F1978009701} |

# Changes
This diff attempts to fix those deadlocks. How:
* In "execute ui code synchronously" (js thread):
* Before going to sleep, the js thread schedules the ui work on the main queue, **and** it posts the ui work to "execute js now".
* In "execute js now" (main thread):
* This diff makes "execute js now" stateful: it keeps a "pending ui block."
* Before capturing the runtime, the "execute js now" executes "pending ui work", if it exists.
* While sleeping waiting for runtime capture, "execute js now" can wake up, and execute "pending ui work." It goes back to sleep afterwards, waiting for runtime capture.
## Mitigation: Deadlock #1
**Main thread**: execute js now:
* Main thread puts a block on the js queue, to capture the runtime.
* Main thread then then goes to sleep, waiting for runtime capture
**JS Thread**: execute ui code synchronously:
* Js thread puts its ui block on the ui queue.
* ***New***: Js thread also posts that ui block to "execute js now". Main thread was sleeping waiting for runtime to be captured. It now wakes up.
* Js thread goes to sleep.
The main thread wakes up in "execute js now":
* Main thread sees that a "pending ui block" is posted. It executes the "pending ui block." The block, also scheduled on the main thread, noops henceforth.
* Main thread goes back to sleep, waiting for runtime capture.
* The js thread wakes up, moves on to the next task.
**Result:** The runtime is captured by the main thread.
| {F1978010383} | {F1978010363} | {F1978010371} | {F1978010379} |

## Mitigation: Deadlock #2
**JS Thread**: execute ui code synchronously:
* Js thread puts its ui block on the ui queue.
* ***New***: Js thread also posts that ui block to "execute js now". Main thread was sleeping waiting for runtime to be captured. It now wakes up.
* Js thread goes to sleep.
**Main thread**: execute js now
* Main thread sees that a "pending ui block" is posted. It executes the "pending ui block" immediately. The block, also scheduled on the main thread, noops henceforth.
* Js thread wakes up and moves onto the next task.
**Result:** Main thread captures the runtime.
| {F1978010525} | {F1978010533} | {F1978010542} |

Changelog: [Internal]
Reviewed By: javache
Differential Revision: D74769326
fbshipit-source-id: 854b83ce4e482a4030dc711834ea6c5613091537
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52000
Fixes https://github.com/facebook/react-native/issues/50338
The current JS FPS value is incorrect because the frame skipping logic hasn't been reimplemented in Fabric.
As we're looking into moving this into the performance panel, I've discussed with huntie
and agreed we'll just remove the value for now to don't show inaccurate informations.
Changelog:
[Android] [Changed] - Hide JS FPS on performance overlay as not accurate
Reviewed By: huntie
Differential Revision: D76590909
fbshipit-source-id: 90b0d9c84f9aefa9197243ebb57f4e86107d6c01
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51982
This class should not be accessed externally. I'm making it internal.
On top of this, it was not fully reimplemented on NewArch so is not working consistently.
This is gonna break one library which is unmaintained and not properly udpated to work with NewArch
https://github.com/hannojg/react-native-performance-stats
Changelog:
[Android] [Breaking] - Cleanup and internalize FpsDebugFrameCallback
Reviewed By: huntie
Differential Revision: D76531175
fbshipit-source-id: 25598eb7c1ecf476b69bb6a2f2f8088a57b9fbc2
Summary:
This PR fixes RNTester system bars background color to match the app one (not solid black).
## Changelog:
- [Internal] [Changed] - Fix RNTester app system bars color when edge-to-edge is enforced
Pull Request resolved: https://github.com/facebook/react-native/pull/51929
Test Plan:
https://github.com/user-attachments/assets/8be0b721-6514-408f-81cd-2106ae7a17c4
Rollback Plan:
Reviewed By: javache
Differential Revision: D76352950
Pulled By: alanleedev
fbshipit-source-id: 474a81564570764a597aa995a0677617263338be
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51941
Changelog:
[Android][Fixed] - Extract out FBReactNativeSpec's core components including Unimplemented from auto-generated registry
Extracting out `FBReactNativeSpec`'s core components including `UnimplementedNativeView` from auto-generated registry. Using this `libraryName` to skip merging those modules
Reviewed By: RSNara
Differential Revision: D76371796
fbshipit-source-id: 4cfee0fe80a661f159a5f17e0d4abc60f601ea74
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52004
This is necessary because the snapshots are now going to be published on a different repository:
central.sonatype.com.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D76596802
fbshipit-source-id: 424fb1134e41502d53b76209fba325c895c79ba8
Summary:
Static code analysis shows that there are several redundant visibility modifiers across the codebase. These are most likely remnants after making different classes internal.
## Changelog:
[INTERNAL] - Kotlin: clean up redundant visibility modifiers
Pull Request resolved: https://github.com/facebook/react-native/pull/51960
Test Plan:
```sh
yarn android
yarn test-android
```
Reviewed By: javache
Differential Revision: D76503015
Pulled By: cortinico
fbshipit-source-id: e60e7aa141fc35ca2fd76335fbee791c86589e4e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51991
This diff introduces a new parameter to customize libraryGenerators used in the codegen, since I'm adding a default object, this diff shoulnd't change any behavior
changelog: [internal] internal
Reviewed By: christophpurrer
Differential Revision: D76472495
fbshipit-source-id: 50b9095c7c554e368f65e4c0b5539be0cca51a51
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51990
In this diff I'm limiting visibility of internal objects of codegen, these objects are being exported but they are unused, let's avoid exporting them
changelog: [internal] internal
Reviewed By: christophpurrer
Differential Revision: D76470809
fbshipit-source-id: 0e168558d2d3211ab5a3a3de05e2495d7c1ae4f5
Summary:
FIXED Add index.js.flow to npm package files for Flow support
Currently, the distributed npm package for react-native does not include the index.js.flow file, which causes all exports to be typed as any when using Flow. This commit adds index.js.flow to the "files" array in package.json, ensuring Flow users receive proper type definitions out of the box. This addresses issues where type checking with Flow fails in React Native projects.
## Changelog:
[General][Added] Publish top-level Flow types for `react-native`
Pull Request resolved: https://github.com/facebook/react-native/pull/51908
Reviewed By: huntie, necolas
Differential Revision: D76292301
Pulled By: robhogan
fbshipit-source-id: e56360d3f35af30ef160470181349aac1812e7c1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51966
This starts off mechanically, but needed a couple changes:
1. Some null handling changes to `TextTransform` internals
2. We type MapBuffer keys as `Int` instead of `Short`, because Kotlin does not allow the implicit widening cast that Java does. I also made these internal
3. Some shifts around casting
4. Mark TextLayoutManager internal, and remove usages of `UnstableReactNativeAPI`
I verified that there were no usages of the Java side of TextLayoutManager throughout `react-native-libraries`, so marking TextLayoutManager internal is unlikely to break 3p libraries.
Changelog:
[Android][Breaking] - Make Java Side TextLayoutManager Internal
Reviewed By: javache
Differential Revision: D76444163
fbshipit-source-id: aabb1c498c731598559f0df5c12e0ecdc266339f
Summary:
This diff adds macros around the legacy architecture core.
To compile out the legacy architecture, simply set: -DRCT_FIT_RM_OLD_RUNTIME=1.
* RCTBridge: interface kept around
* RCTRootView: interface kept around
* RCTSurface: interface kept around
* RCTModuleData: interface kept around (used by RCTProfile)
* RCTProfile: Kept around (doesn't work in bridgeless...)
* RCTCxxBridge: interface kept around
* c++ bridge: removed
* legacy components in core: kept around (for now)
## Details
I added comments to each of the #else, and #endif directives. That way, we can more easily codemod this code in the future.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D72582307
fbshipit-source-id: 018d11cc488e97e60040bebf647f24f2437a57ce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51977
This will help the Kotlin migration of ReactDelegate.
Changelog:
[Internal] [Changed] -
Reviewed By: mdvacca
Differential Revision: D76518840
fbshipit-source-id: 8a24c20705aa6b04af693a6229235b11f30e0bc8
Summary:
Static code analysis shows that there are a lot of unresolved KDoc references. Also, there are a lot of functions incorrectly linked in the comments that were using `[.yourFunction]` instead of `[yourFunction]` – this diff addresses many of them.
## Changelog:
[INTERNAL] - Kotlin: fix up several KDoc annotations
Pull Request resolved: https://github.com/facebook/react-native/pull/51961
Test Plan:
```sh
yarn android
yarn test-android
```
Reviewed By: fabriziocucci
Differential Revision: D76481171
Pulled By: Abbondanzo
fbshipit-source-id: dd55e8fc3abfeaefc9c3762632a05fb7baf63530
Summary:
This parameter can be null and is causing failures on some tests. This fixes
it.
Changelog:
[Internal] [Changed] -
bypass-github-export-checks
Reviewed By: lenaic
Differential Revision: D76505211
fbshipit-source-id: a23fca21daf5292bc7375e7d025d1202cc591b86
Summary:
This is to enable consuming RCTImage pod in mixed ObjC/Swift codebase. W/o this option set I get following error when building the library:
```
Installing RNScreens 4.11.1
[!] The following Swift pods cannot yet be integrated as static libraries:
The Swift pod `RNScreens` depends upon `React-RCTImage`, which does not define modules. To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries), you may set `use_modular_headers!` globally in your Podfile, or specify `:modular_headers => true` for particular dependencies.
```
I've noticed that there is also a precedent in the form of https://github.com/facebook/react-native/commit/c8fcac2765e0f79f0e7bb3a422a65698aec62536, which handled very simlar case but for `React-jsc` pod.
## 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] - Allow for consuming RCTImage in Swift codebase by enabling "Defines Module" option
Pull Request resolved: https://github.com/facebook/react-native/pull/51974
Test Plan: RNTester should build & run correctly
Reviewed By: cortinico
Differential Revision: D76505478
Pulled By: cipolleschi
fbshipit-source-id: bcce93ffc7e1c917da7f07db83a710575c659f45
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51965
Changes the error handling in `cli.js` scripts for `rn-tester` and `helloworld` so that the original error stack traces are preserved.
Changelog:
[Internal]
Reviewed By: huntie
Differential Revision: D76458284
fbshipit-source-id: 491b2bacc4becb8676a2ed4f1181192632bd808f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51962
Changelog: [Internal] - Migrate debug feature flag to be accessed in both native and JS
Reviewed By: yungsters, mdvacca
Differential Revision: D76381273
fbshipit-source-id: d4071abeb9769821e236c444f89044165cf83d92
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51944
Ahead of more refactoring, this cleans up a couple feature flags, already on by default, the newest of which added on 5/1, since these should all be validated by significant production usage at this point, so it is unlikely we would want to turn off.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D76412970
fbshipit-source-id: a2612583c060ed3f6fc559864e481d5b5a33fef2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51939
ReactRootView already reliably assigns itself a fresh root tag from its constructor. Assuming this `FabricUIManager.startSurface` method is called with a valid `ReactRoot` instance, we can just re-use the existing tag without minting a new one. This makes some native initialization that depends on root tag assumptions easier to setup.
## Changelog
[Internal]
Reviewed By: javache
Differential Revision: D76370069
fbshipit-source-id: ad9bb91eee374c911f65ebcdd395716c77881e96
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51958
There is a copy and paste mistake, from dependencies to core, when uploading artefacts to maven.
This change fixes it.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D76435336
fbshipit-source-id: a829b90ba3d4cbfc5528fc9f21dcee7be6a358ff
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51948
TSAN is showing a data race in RuntimeScheduler_Modern::updateRendering.
# Changelog:
[Internal] - Use atomic to unblock broken tests. eventTimingDelegate_ is only set once during startup, so the real fix here would be to delay runEventLoop until setEventTimingDelegate has been set.
Reviewed By: javache
Differential Revision: D76415742
fbshipit-source-id: 995d2a68d671c555f990b4f8d85ac9419ae2734c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51923
This diff publishes the Reactcore prebuilds to Maven central so that apps can use it when integrating with React Native
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D76338793
fbshipit-source-id: 777c91805573b90ef15209e196cd66801908a5ce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51919
Implement signing for the React Native core XCFramework
The implementation follows the same approach we used for the ReactNativedependencies archive
## Changelog
[Internal] -
Reviewed By: cortinico
Differential Revision: D76337972
fbshipit-source-id: 74f61c087b31e4087752cd60bea59db15f00321b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51920
Introduce the BuildFlavor typeand refactor the build scripts to use 'Debug' and 'Release'.
For iOS we always use capitalized Debug and Release and it will make it easier to work with CI too.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D76338034
fbshipit-source-id: ae1acc740b47692ec5eee94c897b49a0e1673b93
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51931
This cleans up the whole `JSEngineResolutionAlgorithm` and all the API related to it.
As now we offer support only for Hermes and JSC is provided via a community package.
This is breaking as it affects Expo, but I'll reach out to Kudo to make sure this is integrated properly.
No other breakages other than this.
Changelog:
[Android] [Removed] - Remove and cleanup JSEngineResolutionAlgorithm
Reviewed By: mdvacca
Differential Revision: D76337620
fbshipit-source-id: e43d5d1164f368f5fa395971bca9c05821492dfe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/51940
We are seeing some reports of badf00d fads (stalls), meaning we are likely doing too much work here. `accessibilityElements` gets called a lot, and is often cached so lets add that in.
Changelog: [Internal]
Reviewed By: jorge-cab
Differential Revision: D76371136
fbshipit-source-id: f9e3423e8135a47a24291b04150c4dc54afbda82