Summary:
When aligning Jest versions recently I have spotted that some old Jest (v24) dependencies are still fetched. After looking at lock the traces lead to outdated `jest-junit` dependency.
This PR updates the `jest-junit` package to get rid of those old Jest dependencies. I have went through [the release changelogs](https://github.com/jest-community/jest-junit/releases) to make sure there are no breaking changes with the current setup.
## Changelog:
[INTERNAL][CHANGED] - upgrade `jest-junit` to remove old Jest dependencies from the workspace
Pull Request resolved: https://github.com/facebook/react-native/pull/53444
Test Plan: I have made sure that `test-ci` tests are passing, and correct `junit.xml` is generated locally after the run.
Reviewed By: cortinico, christophpurrer
Differential Revision: D80904710
Pulled By: robhogan
fbshipit-source-id: 9b4c65e2fd370bbdb429fb628f79f94698e9c4c2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52672
This was used internally to work around some limitations of the bridge lifecycle. Given that we now have C++ TurboModules which are much more versatile, let's remove unnecessary concepts externally, as we move towards deprecating legacy C++ modules entirely.
Changelog: [General][Breaking] Removed CxxSharedModuleWrapper
Reviewed By: rshest
Differential Revision: D78484221
fbshipit-source-id: 95ed46b597dac55d823b70abe196264ce5b326ab
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53488
Creates a new feature flag to experiment with `Activity` in `VirtualView`.
The feature flag enables the following treatments:
- `no-activity` is the same as what we currently do — no `Activity` and we render `null` for hidden elements.
- `activity-without-mode` wraps the children in `Activity` but does not set `mode` and still renders `null` for hidden elements.
- `activity-with-hidden-mode` wraps the children in `Activity` and sets `mode="hidden"` and continues providing `children` (not `null`) for hidden elements.
Changelog:
[Internal]
Reviewed By: rickhanlonii
Differential Revision: D81149561
fbshipit-source-id: ea2c319139962de30836d80a2492d8147cbe82ba
Summary:
On iOS, if the default locale is not supported in the app, it will fall back to the first available locale to decide if RTL layout should be enabled or not; however on Android, we use the default locale. So if the first locale is a RTL locale and not supported by the app on Android, the app will fall back to the first available locale which might not be RTL, but the layout would be decided as RTL according to the default locale.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID] [FIXED] - use the first available locale instead of the default one to decide `isDevicePreferredLanguageRTL`
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[ANDROID] [FIXED] - use the first available locale instead of the default one to decide `isDevicePreferredLanguageRTL`
Pull Request resolved: https://github.com/facebook/react-native/pull/53417
Test Plan:
I set my phone's locale to this order: Hebrew, English and enabled RTL layout:
```
import { I18nManager } from 'react-native';
I18nManager.allowRTL(true);
I18nManager.swapLeftAndRightInRTL(true);
```
Prior to my PR, the app would use RTL layout with English on Android which doesn't make much sense (iOS is LTR + English). With my PR Android app will behave exactly the same as the iOS app.
Reviewed By: rshest
Differential Revision: D80821903
Pulled By: zeyap
fbshipit-source-id: c1bd9b45341c344833a8fdfacc2c786ee8437415
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53480
Changelog: [Internal]
Improves the way `--version` and the User-Agent header work in `debugger-shell`.
* The same app name and version string format will be used across the `dev` and `prebuilt` flavours. Previously, `dev` would report itself as being `Electron v37.2.6` while `prebuilt` would report `react-native/debugger-shell v0.82.0-main`.
* `prebuilt` now also reports the original Meta-internal commit hash as a suffix `-rFBS..........` added to the semver string taken from `package.json`, while `dev` will have a `-dev` suffix in the same place.
* We do **not** modify the version in `package.json` during the build, nor do we pass the commit hash to `electron/packager`, because this would impose inconvenient platform-specific restrictions on the version string's format.
Reviewed By: huntie
Differential Revision: D81120181
fbshipit-source-id: e730dd35da78dfbb8de326f9a3ab76b747fdb0b3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53481
Small fix to this RNTester example to clean up hanging `setInterval` side effect making repeat network fetches.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D81127809
fbshipit-source-id: 6036dd254888eb6160d2b1e116bbce63e5fd9328
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53368
This change introduces deprecation messages for several APIs used by the legacy arch in the RCTAppDelegate Library
## Changelog:
[iOS][Added] - Add deprecation message for RCTAppdelegate APIs
Reviewed By: cortinico
Differential Revision: D80618102
fbshipit-source-id: db77f8602a521557ed26822f27d54c6fc70c49bf
Summary:
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.
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.
- Added method that handles this in a generic way
- Replaced logic for resolving header mappings and module name using the new method `resolve_use_frameworks` in all podspecs.
- Add 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.
## Changelog:
[IOS] [FIXED] - Fixed using USE_FRAMEWORKS (static/dynamic) with precompiled binaries
Pull Request resolved: https://github.com/facebook/react-native/pull/53432
Test Plan:
Build RN-Tester with USE_FRAMEWORKS static and dynamic
### Tests ran:
✅ Build with source and no USE_FRAMEWORKS
✅ Build with source and USE_FRAMEWORKS = static
🔴 Build with source and USE_FRAMEWORKS = dynamic
Undefined symbols for architecture arm64:
"facebook::react::oscompat::getCurrentProcessId()", referenced from:
Reviewed By: motiz88
Differential Revision: D81127796
Pulled By: cipolleschi
fbshipit-source-id: 1f55bf31240ac93cb8b93751b3e37ff6d517f49b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53476
## Changelog:
[General] [Added] - allow calling createAnimatedNode without batching
Enable setting `nativeCreateUnbatched` config on an AnimatedNode, when it's true, the call to Animated nativeModule's createAnimatedNode will skip signal batching (will call over JSI before React rendering is finished) and batching in c++, and the creation will be executed at next UI thread render.
This will only make AnimatedNodes creation happen early, but node/view connections, node deletion or event drivers will still be batched like before
Reviewed By: yungsters
Differential Revision: D80968512
fbshipit-source-id: afb607410a174fb85107ef270b9d6f3d61617daf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53472
changelog: [internal]
I am looking into stalls when View Culling is turned on together with immediate state updates. This is one of the places where stalls are concentrated and this seems like a possible culprit:
When view is moved outside of the viewport, it is immediately reused. Therefore, we must check view's identity to make sure it is the same view before and after transaction.
Reviewed By: lenaic
Differential Revision: D81044328
fbshipit-source-id: 796b71219e5fc94c1f98319b73f4655b9c13000f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53464
Changelog: [Internal]
Minor followup from D78351937 - the Fusebox console notice still mentions that RNDT requires Chrome or Edge. Let's remove this mention for users opted into the standalone shell experiment.
Reviewed By: huntie
Differential Revision: D81040965
fbshipit-source-id: a290d3164261f8a1087229edfe3f69a2a9b49960
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53435
Changelog: [Internal] Support setting `enableStandaloneFuseboxShell: true` in OSS with no custom `BrowserLauncher`
Makes it possible for frameworks to enable the React Native DevTools standalone shell in open source by passing `unstable_experiments: {enableStandaloneFuseboxShell: true}` to `createDevMiddleware()`.
When this experiment is enabled:
* The RNDT shell binary will be prefetched in the background as soon as the dev server starts (into a local cache managed by [DotSlash](https://dotslash-cli.com/)).
* If prefetching is successful, then "Open DevTools" actions will be handled by launching the RNDT frontend in the standalone shell, instead of in Chrome/Edge.
* If prefetching is not successful, then we'll notify the user about the error, and "Open DevTools" will continue to be handled by Chrome/Edge, as before.
* If the user attempts to open DevTools more than once for the same app, the standalone shell will reuse the existing window (as opposed to the current behaviour of always creating a new Chrome/Edge window).
* The appropriate DevTools window will automatically foreground itself upon pausing on a breakpoint.
Reviewed By: huntie
Differential Revision: D78351937
fbshipit-source-id: 6d5baa8fa866760f1d527108cd3c42bcab68cf57
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53438
Changelog: [Internal]
Makes `flavor: 'prebuilt'` the default mode of launching the RNDT standalone shell, and the *only* mode supported in the published version of the package. See D78351931 for more context.
With this, we can demote `electron` from `dependencies` to `devDependencies`. This makes it possible to make `debugger-shell` a dependency of `dev-middleware` (and thus of all major frameworks) without significantly impacting `npm install` times. We'll add this dependency on `debugger-shell` in an upcoming diff (D78351937).
We also stop publishing the `dist/electron` subdirectory (and `src/electron` for good measure) since the corresponding code will always be bundled into the prebuilt binary instead.
Reviewed By: huntie
Differential Revision: D78351934
fbshipit-source-id: 2a4b03e852c4d0330250567c41dca09d1c4f3abd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53437
Changelog: [Internal]
The React Native DevTools standalone shell is distributed as a DotSlash file that downloads the required binaries lazily. This diff adds support in dev-middleware for a new `BrowserLauncher.unstable_prepareFuseboxShell` method that integrations can use to kick off the download early. Integrations are expected to implement this by calling the `unstable_prepareDebuggerShell` function (added to the `debugger-shell` package in D78413091).
If `BrowserLauncher.unstable_prepareFuseboxShell` returns an error, dev-middleware will fall back to the browser-based launch flow, even for users opted into the `enableStandaloneFuseboxShell` experiment.
Reviewed By: huntie
Differential Revision: D78413092
fbshipit-source-id: 6868bf07e16353fcd83337ae54c87c5a641a0f99
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53434
Changelog: [Internal]
The React Native DevTools standalone shell is distributed as a DotSlash file that downloads the required binaries lazily. This diff gives integrations a mechanism for kicking off the download early (but without slowing down `npm install react-native`). This will be integrated into dev-middleware in an upcoming diff.
Reviewed By: huntie
Differential Revision: D78413091
fbshipit-source-id: caf2010edd1bcdd139d37d7849212cd1cbb64f46
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53436
Changelog: [Internal]
Adds a `flavor` option to `unstable_spawnDebuggerShellWithArgs` to select between two modes:
1. `flavor: 'dev'` (current behaviour) - launching a stock Electron binary (from the `electron` package) and pointing it directly at the shell code from the `src/electron` directory.
2. `flavor: 'prebuilt'` (new in this diff) - launching the prebuilt React Native DevTools binary included in the package (built continuously at Meta and committed as a DotSlash file in automated diffs e.g. D79836825). Note that this binary includes Electron *and* a frozen version of the shell code from `src/electron`.
Going forward, `'dev'` will only be used when developing the package (e.g. in D78351934 we will move `electron` to `devDependencies`). The published version of the package is only intended to work with `flavor: 'prebuilt'`.
Reviewed By: huntie
Differential Revision: D78351931
fbshipit-source-id: d0e66b54c142dc2910619ba3d6d149d88324c872
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53468
# Changelog: [Internal]
I've just discovered today that Chrome DevTools has a native support for `panel` query parameter, we don't need a custom one.
Reviewed By: alanleedev
Differential Revision: D81052828
fbshipit-source-id: 6f8ef5b576dbff70cabd6ab792bc0f6e615928e7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53465
changelog: [internal]
I am debugging an issue with Fabric View Culling + immediate state update.
The problem appears to be in logic handling `maintainVisibleContentPosition`. I want to try to disable the prop to see if the problem goes away.
Reviewed By: rshest
Differential Revision: D81030436
fbshipit-source-id: 8efeb1151ad3e12b812cafd073348502510ef01d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53466
This is a follow-up on D80631997. When enabling View Culling on Android, wrapped Text components would lead to event handlers set by the inner Text component not being set on the attributed string.
```
<Paragraph>
<Text onPress={myHandler}> <- This handler is not set
<RawText/>
</Text>
</Paragraph>
```
This was due to the inner Text component having no size and hence being culled by the View Culling algorithm.
This diff disables view culling for views having no size, since no layout means no valid decision can be made as to the visibility of the component within the viewport.
It also removes the change made by D80631997. This means Text views with a layout size set can be culled again.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D81044841
fbshipit-source-id: e9b01dcb8030b271876329b9b2c5bda36ba2b87a
Summary:
XCode 26 introduces building explicit swift modules turned on (SWIFT_ENABLE_EXPLICIT_MODULES). This breaks building with precompiled binaries.
This commit fixes this by adding a step when not building from source where we explicitly set the `SWIFT_ENABLE_EXPLICIT_MODULES` flag to `NO`.
## Changelog:
[IOS] [FIXED] - Added setting SWIFT_ENABLE_EXPLICIT_MODULES=NO when using precompiled to support Xcode 26
Pull Request resolved: https://github.com/facebook/react-native/pull/53457
Test Plan:
```bash
npx react-native-community/cli init MyApp --version nightly --skip-install
cd MyApp
yarn
cd ios
bundle install
RCT_USE_RN_DEP=1 RCT_USE_PREBUILT_RNCORE=1 bundle exec pod install
```
Build above app with Xcode 26 and verify that it no longer fails
Reviewed By: motiz88
Differential Revision: D81025367
Pulled By: cipolleschi
fbshipit-source-id: 1db7c4d7de07d62f43b355aa784d7d9de478023c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53345
Changelog: [Internal] - Introduce hysteresis window that is nested between the prerender and hidden window sizes. Currently set to enlargening the prerender window by hysteresis ratio
When a VirtualView intersects with the hysteresis window, it mode remains unchanged.
This prevents us dispatch mode changes for things like overscroll.
I put the hysteresis between prerender and hidden because we already avoid dispatching mode changes from visible -> prerender. For prerender -> visible, we use renderState
Reviewed By: yungsters
Differential Revision: D80511627
fbshipit-source-id: cd14256abc898e7120705e277147d52a06c865a9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53424
Use the namespaced version of these macros to avoid symbol conflicts when multiple instances of `PERFETTO_DEFINE_CATEGORIES` are in the same binary.
The current macro is effectively deprecated: https://github.com/a6f/perfetto_protos/blob/master/CHANGELOG#L691-L696
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D80697205
fbshipit-source-id: 713fec4d41137ddd2f025c7e7130dc44c5a3a656
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53426
Experiment review for this was completed internally, and we can now change the default behaviour to no longer allocate an intermediate folly::dynamic when parsing props.
RawValue will continue supporting a folly::dynamic constructor as some paths go through code path (eg animations)
There should be no user-visible difference in parsing behaviour.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D80799833
fbshipit-source-id: 8eeae656157757eb38f69a2af14409da23b510c8
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
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53395
# Changelog
[Internal] -
This enables view recycling for both ScrollView and HorizontalScrollView on Android.
The feature is gated by the corresponding RN feature flag, `enableViewRecyclingForScrollView` (which is false by default for now, will be enabled in an experiment).
Reviewed By: lenaic
Differential Revision: D80611087
fbshipit-source-id: b3026affc0ea61bc7739126d6529c83f2a653183
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/53403
This code is Legacy and totally unused. It should be safe to remove it altogether.
This class is public but no one is using it in OSS + no one should be using it, so I don't think we'll need the full deprecation cycle for it.
Changelog:
[Android] [Removed] - Removed unused `Inspector` public class from React Android
Reviewed By: cipolleschi
Differential Revision: D80711515
fbshipit-source-id: 83134851877fcbccd50f7a5b75b2ab8906b3416a
Devmate Bot
Simek
generatedunixname1395667395051502
Pieter De Baets
Tim Yung
Sam Zhou
Kaining Zhong
Moti Zilberman
Alex Hunt
Riccardo Cipolleschi
Christian Falch
Christian Kruse
Zeya Peng
Samuel Susla
Ruslan Lesiutin
Nick Lefever
Christoph Purrer
Vitali Zaidman
Luna Wei
Andrew Datsenko
Phil Pluckthun
Ruslan Shestopalyuk
Nicola Corti
generatedunixname89002005287564