Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43568
Fixes to restore passing CI checks on main after D55027120.
- Widen validation checks in version utils to accept `0.x.x` (as opposed to `0.[not-'0'].x`).
- Use `tag: test` instead of `tag: latest` for dry run job params.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D55123739
fbshipit-source-id: 9f76dced4e7aa3ce87d6680cd7687ae443305331
Summary:
Changelog: [Internal] Remove console logs from Metro when native Fusebox debugger console is available
React Native currently sends all `console.log` messages to Metro, which prints them to the terminal. This feature has been in place since 2019 (D15559151) but is pretty limited when compared to what's available in modern browsers. Most of the limitations can't really be fixed within the constraints of Metro's relatively simple terminal infrastructure.
With the new React Native debugger (codenamed "Fusebox") we aim to fundamentally elevate the debugging experience by shipping a well-tested version of Chrome DevTools with React Native. Chrome DevTools has a rich, interactive console, as well as a host of other debugging features we want developers to notice and use.
To that end, we plan to **strongly nudge users towards the Fusebox console from day 1**. Specifically, if we detect that Fusebox is available and is using an engine which implements CDP `console` support ( = Hermes only for now), we'll no longer send logs to Metro, and will instead display an explanatory message directing users to Fusebox.
Reviewed By: huntie
Differential Revision: D54829811
fbshipit-source-id: 2b1cdb666094f901ff4e7f42b123271be4ce7d10
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43565
Changelog: [Internal]
Uses https://github.com/facebookexperimental/rn-chrome-devtools-frontend/pull/24 to identify the Fusebox frontend and show a corresponding message in the logs.
Also tweaks the wording and formatting of other messages logged by the Fusebox backend - including removing the "you are using the modern CDP backend" one.
Reviewed By: huntie
Differential Revision: D55075645
fbshipit-source-id: c82670570c79b61efd399f26684139ce97f017ef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43537
This file always had a bunch of errors and made it so that actual errors do not show up (too many emitted). It was just because we are not including RawProps.h. I am not sure how it ever got compiled but I guess some header included something that included something etc. Maybe its a vs code issue but this seems like an obvious fix
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D55041883
fbshipit-source-id: 3445770dd25dbe294024649f96f9e3af7777b2b2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43554
changelog: [internal]
The prop endDraggingSensitivityVelocityMultiplier makes the API more complicated and provides only limited benefit. Let's remove it for the sake of simplicity.
Reviewed By: christophpurrer
Differential Revision: D53853298
fbshipit-source-id: d2663f2f6eef1dde3136debe8965ee871f4e043d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43534
This is no longer used after switching to the new release workflow, which uses the newer and less error-prone `set-version` script.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D55027122
fbshipit-source-id: faa8cfd2af9b54fab611b108df162793c5768695
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43533
Switch to the new unified release workflow by default, now that this has been validated on the `0.74-stable` branch.
- Remove `--use-new-workflow` flag and remove legacy logic.
- Remove legacy `prepare_package_for_release` CI job, and use `run_new_release_workflow` -> `run_release_workflow` as new workflow condition match.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D55027120
fbshipit-source-id: 7c05cdff95ac369ce6cd1201ccfc5718798c4da6
Summary:
Updated linters, include typings in `package.json` and removed bun from the clean commands.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D54493859
fbshipit-source-id: eb28d208de722c90916b14f56d5a8e847bb3d859
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43530
Fixes and changes following D54956345, encountered during the release process for 0.74 RC4 today.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D55017872
fbshipit-source-id: 616b387088db00c6f076f4571b4ab1541467361c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43520
Refactor ReactDelegate to have a private `getDevSupportManager()` that can also be re-used by `reload()`
This method conditionally provides the correct DevSupportManager in cases of Bridge & Bridgeless
Changelog:
[Internal] internal
Reviewed By: cortinico
Differential Revision: D54967130
fbshipit-source-id: 37d585de33a50b98d01803d3080c5693a8c494b9
Summary:
The [Windows fix](https://github.com/cezaraugusto/chromium-edge-launcher/pull/1) was merged and published. We no longer need to use the fork.
## Changelog:
[INTERNAL] [FIXED] - Fix experimental debugger launch flow with Edge on Windows
Pull Request resolved: https://github.com/facebook/react-native/pull/43524
Test Plan: n/a
Reviewed By: robhogan
Differential Revision: D55013623
Pulled By: motiz88
fbshipit-source-id: bff2aa2801dd0dcdd6975dca0a2ec2aa9864ff6f
Summary:
Minor fix to package.json which newer version of npm warn about when publishing, after running `npm pkg fix -ws` on the workspace.
{F1470070110}
## Changelog: [Internal] npm pkg fix -ws
Pull Request resolved: https://github.com/facebook/react-native/pull/43519
Test Plan: eyescloseddog
Reviewed By: cortinico
Differential Revision: D55012872
Pulled By: blakef
fbshipit-source-id: ff3c63a3eefaf56d369219a3d4b32d44d6d842c9
Summary:
This PR updates `typescript-eslint/eslint-plugin` and `typescript-eslint/parser` to `v7` and `eslint-plugin-jest` to `v27`, removing any dependencies on `typescript-eslint` `v6`, allowing projects using `react-native/eslint-config` to safely update to `typescript-eslint` `v7` without having to worry about duplicate major versions installed
## Changelog:
- [General] [Changed]: Updated `eslint-plugin-jest` to `v27`
- [General] [Changed]: Updated `typescript-eslint` monorepo to `v7`
Pull Request resolved: https://github.com/facebook/react-native/pull/43406
Test Plan: `yarn run lint` executed locally successfully
Reviewed By: robhogan
Differential Revision: D54749676
Pulled By: tdn120
fbshipit-source-id: f6fae92fc95333e28b36a3d2bd8470c8869d38bc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43385
`rncore` and `FBReactNativeComponentSpec` contain the same symbols, which leads to conflicts when we try to merge them into a single shared library. Cleanup the duplication and standardize on `FBReactNativeComponentSpec` everywhere. I've left the Android OSS targets as is, to avoid breaking deps.
Changelog: [Internal]
Reviewed By: cortinico, dmytrorykun
Differential Revision: D54630694
fbshipit-source-id: 75cb961ded9fd75508755c0530e29409fef801cf
Summary:
### Context
- Since RN 0.73, in the jest.setup file, methods of the Image module (Image.getSize, Image.resolveAssetSource...) are mocked on the **JS side** (introduced in https://github.com/facebook/react-native/pull/36996)
- It causes issues like https://github.com/facebook/react-native/issues/41907 : `Image.resolveAssetSource` returns nothing in test env with the new JS mock, when some test relies on it.
- On my project, it broke the snapshots : the URL of images disappeared. I use `react-native-fast-image` which uses `Image.resolveAssetSource` to compute URLs.
- I first opened a PR to fix exclusively Image.resolveAssetSource: https://github.com/facebook/react-native/pull/41957. I will close it to focus on this new one.
- As suggested by ryancat and idrissakhi, it should be better to return to the previous mock, where no method is mocked on the JS side, and we can trust the actual JS to work in test.
This is what this PR intends to do.
### Content
Along fixing the Image module mock in jest.setup, this PR :
- adds unit test on each one of the methods, ensuring they have a consistent behavior even when the module is mocked.
- adds 3 missing native mocks for `NativeImageLoader`: `prefetchImageWithMetadata`, `getSizeWithHeaders` & `queryCache`. After this PR, no method from NativeImageLoader remains unmocked.
## Changelog:
[GENERAL][FIXED] - fix jest setup for Image methods (resolveAssetSource, getSize, prefetch, queryCache)
Pull Request resolved: https://github.com/facebook/react-native/pull/43497
Test Plan:
See exhaustive unit tests in PR.
You can re-use the mock with all the methods mocked and see how the new unit tests fail.
I also patched those changes on my project: my snapshot did have their URL back (see demonstrative screenshots in my original PR: https://github.com/facebook/react-native/pull/41957 - NB; fixed mock was different but result was the same -> those screenshots cover only two cases, but anyway they illustrate well the case!)
Reviewed By: ryancat
Differential Revision: D54959063
Pulled By: tdn120
fbshipit-source-id: 837266bd6991eb8292d9f6af1774e897ac7a8890
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43504
Changelog: [internal]
We identified the issue in the experiments already, so we can remove this flag.
Reviewed By: sammy-SC
Differential Revision: D54945099
fbshipit-source-id: 4d547569eb3bbfd011f5d6894d87bfa542cac07b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43503
Changelog: [internal]
## Context
In the experiments to enable mount hooks on Android we saw some crashes that we couldn't reproduce or pinpoint accurately.
We ran another experiment excluding part of the code in one of the variants, and we found that the problem was in this block (only crashes when `skipMountHookNotifications` is false):
https://github.com/facebook/react-native/blob/121b26184acbb77ff4f2360647cb322ff560b145/packages/react-native/ReactCommon/react/renderer/uimanager/UIManager.cpp#L726-L734
Looking more closely at the mounting coordinator code, I realized that some of the methods are not thread-safe, which is likely causing these issues.
~~We're probably only seeing these issues on Android because we have a push model there (we call `pullTransaction` from whatever thread we're committing to, JS thread or Fabric background thread) whereas in the rest of platforms we have a pull model and we always access call `pullTransaction` from the main thread, as we do to report mounts.~~
This is probably fine because both cases are protected by a mutex when accessing through `ShadowTreeRegistry::visit`. But there's a case that doesn't go through it that could be causing the issues: prerendering:
https://github.com/facebook/react-native/blob/121b26184acbb77ff4f2360647cb322ff560b145/packages/react-native/ReactCommon/react/renderer/scheduler/SurfaceHandler.cpp#L289
## Changes
1) Make `getBaseRevision` return a copy of the revision rather than a reference.
2) Make all methods that access `baseRevision_` and `lastRevision_` thread-safe.
Reviewed By: javache
Differential Revision: D54945100
fbshipit-source-id: d8b211137d0eac02a5814cc6c376c22733290eab
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43507
Changelog: [General][Changed] - sync React renderers to 18.3.0-canary-9372c6311-20240315
Syncs React renderers to https://github.com/facebook/react/commit/9372c63116fc1e855c51d93d83f5150661371ec3 which is canary for 18.3.0-canary-9372c6311-20240315.
This includes the necessary changes to enable the use of microtasks for scheduling in Fabric.
Reviewed By: yungsters
Differential Revision: D54947212
fbshipit-source-id: 8fd5def5107d77e6a248f653a9d0260b392fab6b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43518
This is a minimum approach to achieve a **single-command publish flow** for React Native, unifying the previous `yarn bump-all-updated-packages` and `yarn trigger-react-native-release` workflow entry points.
This diff aims to change as little as possible to achieve the above — introducing a new job that merges operations to create the versioning commit. The triggered publish jobs are unchanged. In future, we may follow this change with further simplifications down the workflow tree.
**Key changes**
- Adds a new CircleCI workflow, `prepare_release_new`, which versions **all packages** and writes a single release commit.
- This replaces `yarn bump-all-updated-packages`, now implemented with the newer `set-version` script.
- Wires this up as an experiment within `trigger-react-native-release.js`, conditionally running the new workflow when `--use-new-workflow` is passed.
**Not changed**
- The single release commit written will continue to trigger both of the existing CI workflows on push (`publish_release` and `publish_bumped_packages`), which are unchanged.
- The commit summary now includes the `#publish-packages-to-npm` marker, in order to trigger `publish_bumped_packages`.
- Usage: Release Crew members will continue to use the existing local script entry point (as [documented in the releases repo](https://github.com/reactwg/react-native-releases/blob/main/docs/guide-release-process.md#step-7-publish-react-native)), with the opt in flag.
```
yarn trigger-react-native-release --use-new-workflow [...args]
```
After we're happy with the E2E behaviour of this workflow in the next 0.74 RC, I will follow up by dropping the `--use-new-workflow` flag and removing the old scripts (T182533699).
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D54956345
fbshipit-source-id: 35fd7af8f3e60a39507b5d978ccd97472bf03ddb
Summary:
This is causing Twilight Android app to hang and crash on start
Original commit changeset: 3f24271405f6
Original Phabricator Diff: D54905564
Reviewed By: sammy-SC
Differential Revision: D54960053
fbshipit-source-id: 5c1063f11ae1314e71288905eb6d8da32ddbfadd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43516
As titled. This seems dangerous — removing with the motivation that we'd prefer this script to fail during execution than to succeed in publishing `9999`.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D54956661
fbshipit-source-id: 23f8d49abd300385dde74871b6d2492ef63f058e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43513
The previous `update_podfile_lock.sh` script would fail as executed from the repo root (could not locate RNTester dir). Delete this and replace with direct calls in `prepare-package-for-release.js`, which will fail script on error.
{F1469216632}
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D54949214
fbshipit-source-id: 4f032069e803e84f835c279d01332d16787dfafc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43511
Changelog: [Internal]
This is an attempt to fix [#39783](https://github.com/facebook/react-native/issues/39783).
It seems that when `configureBuildForHermes` runs (as part of `yarn android` in `rn-tester`) cmake may not be available and is not installed automatically:
* for 3p, even after installing the latest Android Studio, cmake 3.22.1 is not available by default but needs to be installed manually
* for Meta employees, same story when looking at the `ANDROID_HOME` set by the `setup_fb4a.sh` in the `.zshrc` file:
```
# added by setup_fb4a.sh
export ANDROID_SDK=/opt/android_sdk
export ANDROID_NDK_REPOSITORY=/opt/android_ndk
export ANDROID_HOME=${ANDROID_SDK}
export PATH=${PATH}:${ANDROID_SDK}/emulator:${ANDROID_SDK}/tools:${ANDROID_SDK}/tools/bin:${ANDROID_SDK}/platform-tools
```
This diff introduces an explicit task to install cmake.
### ALTERNATIVE 1
See D54897379.
### ALTERNATIVE 2
Suggested by cortinico:
> Create a mini module called :packages:react-native:ReactAndroid:hermes-engine:cmake-downloader which just triggers an empty cmake build via Android SDK
Reviewed By: cortinico
Differential Revision: D54859484
fbshipit-source-id: f9ecdf78ff408947b1e85e7da4f112c89d3a8c89
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43506
Changelog: [internal]
We've been making all the built-in C++ TurboModules in RN extend `enable_shared_from_this` because we copied from the same template that needed it, but none of them do. This removes that unnecessary extension.
Reviewed By: sammy-SC
Differential Revision: D54901332
fbshipit-source-id: 795c7696e70041d640399e3b9f177999e22fd90b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43470
Changelog: [internal]
This moves the native code for the Web Performance API to `ReactCommon`, to align with the other default C++ native modules we've defined there.
Reviewed By: sammy-SC
Differential Revision: D54860194
fbshipit-source-id: 32dccb080fb8ebd1e2acbdd59fa2dfe47e372c17
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43482
## Context
We are migrating to the new Hermes `CDPAgent` and `CDPDebugAPI` APIs in the modern CDP server (previously `HermesCDPHandler`).
## This diff
Now that we are confident that `CDPAgent` is stable, switch to it by default and remove the previous integration.
- Drop `inspectorEnableHermesCDPAgent` feature flag.
- Rename and replace `HermesRuntimeAgentDelegateNew` as `HermesRuntimeAgentDelegate`.
- Drop "Hermes integration: CDPAgent" log message.
- Update tests.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D54897841
fbshipit-source-id: 8a5212d27f21c54112c0820a2a3611e05d606880
Cedric van Putten
Alex Hunt
Moti Zilberman
Edmond Chui
Arushi Kesarwani
Samuel Susla
Joe Vilches
Blake Friedman
Bruce Mitchener
Wendi Du
Tommy Nguyen
Pieter De Baets
Blake Friedman
Lluís
Pieter De Baets
Delphine Bugner
Rubén Norte
Jane Li
Fabrizio Cucci
Rob Hogan
zhongwuzw
Wojciech Dróżdż