Summary:
This adds `react-native/metro-config` to the monorepo build tool and emits the missing typescript declarations.
Right now, we do have typescript declarations on `metro-config`, but not `react-native/metro-config`. Which makes everything a bit harder extend from "[the default React Native metro config](https://github.com/facebook/react-native/pull/36502)" in Expo.
> Note, I also added the same `exports` block from `react-native/dev-middleware` for conformity.
One open question here is, why aren't we exporting _all_ helper functions from `metro-config`? To me, its a bit weird that we need both `metro-config` _and_ `react-native/metro-config` as `loadConfig` isn't exported.
## Changelog:
[INTERNAL] [FIXED] - Emit typescript declaration files for `react-native/metro-config`
Pull Request resolved: https://github.com/facebook/react-native/pull/41836
Test Plan:
Run the build tool, and check if the typescript declarations are emitted for `react-native/metro-config`.
```
yarn build metro-config
```
Reviewed By: hoxyq
Differential Revision: D51943453
Pulled By: huntie
fbshipit-source-id: cfaffe5660053fc9a9fcbe3dacf7f6ccc2bde01b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42948
Changelog: [Internal]
Refactor URL construction for DevTools.
Next diffs in the stack will add additional URL query params.
Support for both absolute and relative `devServerUrl`s maintained.
Reviewed By: hoxyq
Differential Revision: D53620915
fbshipit-source-id: 4a64c49c3479ede2add9f39a24448787d8609172
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42858
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: cortinico, rshest
Differential Revision: D53393471
fbshipit-source-id: 3f896f7d7c51f276a3f743d39dc851cb47ca538a
Summary:
In setups with `pnpm` `react-native/virtualized-lists` gets bundled incorrectly because of the following error:
`Module not found: Error: Can't resolve 'react'`
As 'react' is used inside of the package, it should declared explicitly, instead of being a phantom dependency.
## Changelog:
[GENERAL] [FIXED] - Declare missing peer dependency `react`
Pull Request resolved: https://github.com/facebook/react-native/pull/42947
Test Plan: not needed
Reviewed By: NickGerleman
Differential Revision: D53617462
Pulled By: cortinico
fbshipit-source-id: 19a8fed94263646b0af93339d5c014e629dfa6b1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42956
In the component codegen system, when the header prefix is an empty string, we generate includes using angle brackets, like this:
```
#include <EventEmitter.h>
```
This fails to compile in buck.
If we instead generate includes using quotations, buck compiles again.
```
#include "EventEmitter.h"
```
So, changes: if the headerPrefix is an empty string, generate includes using quotes.
This is a followup to D51811596.
Changelog: [Internal]
Reviewed By: fkgozali, dmytrorykun
Differential Revision: D53487111
fbshipit-source-id: e90a8b9fd4f8a2a93a0f4ad0ed989af26ad122c5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42927
This bumps Kotlin to 1.9.22 which is the latest in OSS and closer to the version we use inside fbsource.
Turns out that Explicit API mode was not enabled correctly, so I had to go over all the Kotlin classes
and correctly set them to `public` if they were intended to be for public consumption.
I updated some of them to `private` or `internal` but otherwise I've defaulted to `public` which is the default
we have right now.
Changelog:
[Android] [Changed] - Kotlin to 1.9.22
Reviewed By: cipolleschi
Differential Revision: D53576844
fbshipit-source-id: dd8b08ce9bf87f738159f60fd850e3e3bc490ebc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42942
Instance derives from jsinspector_modern::InstanceTargetDelegate, which defines a virtual destructor, but Instance does not mark its destructor with override.
## Changelog [Internal]
Reviewed By: cipolleschi
Differential Revision: D53609922
fbshipit-source-id: b30df7d59478fa72b53ddc2eeb04c291a6f5f9eb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42940
We might have some libraries that goes through the interop layer that are using [RCTBridge currentBridge]. Although this is an API that we would like them not to use, that's the sad reality and if we don't want to force a migration on those libraries, we need to be backward compatible.
This diff sets the `RCTBridgeProxy` as the `currentBridge` in case the app is running in BridgelessMode. This should make Bridgeless backward compatible.
## Changelog
[iOS][Fixed] - Make [RCTBridge currentBridge] work in bridgeless mode
Reviewed By: RSNara
Differential Revision: D53575361
fbshipit-source-id: 179e440662b577954a577e8400e0ce0dc5b4d3ff
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42922
changelog: [fix][ios] prevent unwanted border animation
The problem: CALayer and its properties are animatable. If RN applies mutations inside an animation block, it will animate. In this particular example, it was animated because of a transition applied by the library and because we were not creating new views, but recycling views from previous screen.
This caused size of _borderLayer to change from value A to value B inside of animation block. To resolve this, call removeAllAnimations on borderLayer.
Reviewed By: cipolleschi
Differential Revision: D53566886
fbshipit-source-id: 98e0b01a9185046e1ee500665c1832060ecc8884
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42882
Changelog: [Android][Added] - introduce native api to access RuntimeExecutor
This is the android equivalent of [PR#42758](https://github.com/facebook/react-native/pull/42758).
From [PR#42758](https://github.com/facebook/react-native/pull/42758)
> The goal of this API is to provide a safe way to access the jsi::runtime in bridgeless mode. The decision to limit access to the runtime in bridgeless was a conscious one - the runtime pointer is not thread-safe and its lifecycle must be managed correctly by owners.
> However, interacting with the runtime is an advanced use case we would want to support. Our recommended ways to access the runtime in bridgeless mode is either 1) via the RuntimeExecutor, or 2) via a C++ TurboModule.
This diff introduces the API that would allow for 1). because react context can be non-null before react instance is ready, this can still return null. however, the callsite should be cognizant of when this will happen. in the case of expomodules, the runtime should be ready when the module is init, unless it is a eager initialized module
Reviewed By: RSNara
Differential Revision: D53461821
fbshipit-source-id: 69555d0593a59f8655e4dcd2f0ef1f78f4cfff7d
Summary:
Opening the VisionOS fork crashes `tsserver.js` inside VSCode because of some Pods files. This stops `tsserver` from looking at any files inside Pods
[Link to issue](https://github.com/callstack/react-native-visionos/issues/97)
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[GENERAL] [ADDED] - Added a folder inside the `exclude` array inside `tsconfig`
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/42909
Reviewed By: lunaleaps
Differential Revision: D53518533
Pulled By: cipolleschi
fbshipit-source-id: 8d7819ec3ae8f0b413389157a34f49961434037f
Summary: blocks don't capture C++ objects so this will would crash
Reviewed By: sammy-SC, cipolleschi
Differential Revision: D53572123
fbshipit-source-id: 323f29c30d99616080aef6b0a895df4599788395
Summary:
This PR adds check if there are any supported platforms to log.
For built-in modules this was logging empty line (as some of them doesn't contain podspecs):
## Changelog:
[GENERAL] [FIXED] - Log Codegen supported platforms if any are available
Pull Request resolved: https://github.com/facebook/react-native/pull/42819
Test Plan: Run Codegen and check if it prints empty `Supported Apple platforms`
Reviewed By: cortinico
Differential Revision: D53566301
Pulled By: cipolleschi
fbshipit-source-id: 3f6b6d3b44da1ab7174432a5fac7f7d3fde11103
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42921
I realized that we were missing a bit to properly link app modules on Android.
The `_ModuleProvider` was never linked correctly so the TM won't be loaded at all.
With this change I'm getting the App Target (say `AppModule`) and passing it down to the
default-app-setup with a couple of macros.
This makes sure that if there is a codegen local module, we import the correct header and query the `AppModule_ModuleProvider` correctly.
Changelog:
[Android] [Fixed] - Fix linking of local app modules turbomodules
Reviewed By: cipolleschi
Differential Revision: D53567201
fbshipit-source-id: d14e61b7f2d86f15363600cd9dd1ed1ca27bd1fc
Summary:
This PR adds nullable annotations to `RCTBundleURLProvider` also allowing to return optional (the default that will be returned when metro is not running). Not having this may lead to crashes because Swift will try to unwrap optional with nil when metro is not running.
## Changelog:
[iOS] [Added] - add nullable annotations to RCTBundleURLProvider
Pull Request resolved: https://github.com/facebook/react-native/pull/42293
Test Plan: CI Green
Reviewed By: sammy-SC
Differential Revision: D52797676
Pulled By: cipolleschi
fbshipit-source-id: 98b4f99aa71828f5397276d22f35d24e48657dc8
Summary:
This PR migrates from the deprecated way of retrieving the status bar info. It introduces a helper method `RCTUIStatusBarManager` which gets the `UIStatusBarManager` from the KeyWindow.
It also removes the unused `getHeight` method.
## Changelog:
[IOS] [ADDED] - Add `RCTUIStatusBarManager` and properly retrieve StatusBar style and height
[IOS] [REMOVED] - Remove unused getHeight method from StatusBar
Pull Request resolved: https://github.com/facebook/react-native/pull/42241
Test Plan: CI Green, Ensure that preferredStatusBarStyle and preferredStatusBarHidden is properly retrieved for Modals
Reviewed By: philIip
Differential Revision: D52729974
Pulled By: cipolleschi
fbshipit-source-id: 40adef810c1d419900fb7ba706af6fb095941e10
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42601
After S390064, the OnDismiss event for Modal from D52445670 was reverted.
The diff was too big and caused the SEV, so we are trying to reimplement it gradually to make sure we don't brake anything.
The most important thing for our short term goal is to make the `OnDismiss` work only for iOS (following the official docs, Android never supported it) for Fabric (Bridge and Bridgeless).
We also want to minimize the changes t the JS infrastructure, so we are trying not to alter the JS APIs.
## The Problem:
The reason why the onDismiss event does not work is because, as soon as the `visible` property is turned to `false`, the component is removed by the React tree.
When this happens, Fabric deallocate the ShadowNode and the EventEmitter. Therefore, the event is not fired.
## The Solution:
We made this work by "delaying" when the component need to be removed from the reacat Tree.
Rather then rendering or node or not based on the `visible` props, we are introducing a `State` object that keeps track when the Modal is rendered or not.
The `state.isRendering` property is set to `true` when the `visible` prop is set to `true`.
For iOS, when `visible` prop is set to `false`, instead, we wait for the Native side to actually dismiss the View and to invoke the event. When the event is fired, we manually set the `state.isRendering` property to false and the Modal can be considered dismissed.
Notice that this makes also useless to have the Modal Native's snapshot to simulate that the modal is still presented.
## Changelog:
[iOS][Fixed] - `onDismiss` now work on iOS with Fabric, in both Bridge and Bridgeless mode.
Reviewed By: sammy-SC
Differential Revision: D52959996
fbshipit-source-id: 365ca1d0234e3742df9db87007523d1a4a86079f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42859
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D53393475
fbshipit-source-id: 442439c03e251d018f289ba4bb45dde9e6a0ab7f
Summary:
Currently if the virtualized list content is small `onStartReached` won't be called initially when the list is mounted. This is because when the content is small `onEndReached` will be called initially preventing `onStartReached` from being called. In `_maybeCallOnEdgeReached` calling `onEndReached` and `onStartReached` are in the same conditional so they cannot both be triggered at once. To improve the consistency of `onStartReached` we should call both `onEndReached` and `onStartReached` if needed.
## Changelog:
[GENERAL] [FIXED] - Call onStartReached initially when list is small and `onEndReached` is called
Pull Request resolved: https://github.com/facebook/react-native/pull/42902
Test Plan:
I used this code to test in RN Tester (replace content of RNTesterAppShared.js)
```ts
import React, { useState, useEffect } from "react";
import { StyleSheet, FlatList, View, Text, TouchableOpacity } from "react-native";
function App() {
const [data, setData] = useState(generatePosts(4));
const [idCount, setIdCount] = useState(1);
const renderItem = ({ item }) => <Item data={item} />;
const keyExtractor = (item) => item.id.toString();
console.log("-------")
return (
<View style={{ flex: 1, marginVertical: 20 }}>
<FlatList
key={idCount}
data={data}
renderItem={renderItem}
keyExtractor={keyExtractor}
onEndReachedThreshold={0.05}
onEndReached={() => console.log("onEndReached")}
onStartReachedThreshold={0.05}
onStartReached={() => console.log("onStartReached")}
inverted
/>
<TouchableOpacity style={{height: 50, width: '100%', backgroundColor: 'purple'}} onPress={()=>{
setIdCount(state => state + 1)
setData(generatePosts(2))
}}><Text> Press</Text></TouchableOpacity>
</View>
);
}
function Item({ data }) {
return (
<View style={styles.item}>
<Text style={styles.title}>
{data.id} - {data.title}
</Text>
</View>
);
}
const styles = StyleSheet.create({
item: {
backgroundColor: "#f9c2ff",
padding: 20,
marginVertical: 8,
marginHorizontal: 16,
},
title: {
fontSize: 24,
},
});
const generatePosts = (count, start = 0) => {
return Array.from({ length: count }, (_, i) => ({
title: `Title ${start + i + 1}`,
vote: 10,
id: start + i,
}));
};
export default App;
```
Before the change only onEndReached is called, after the change both onStartReached and onEndReached is called.
Reviewed By: sammy-SC
Differential Revision: D53518434
Pulled By: cipolleschi
fbshipit-source-id: bc34e0d4758df6d5833be7290e5a66efaf252ffd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42908
Changelog: [internal]
Just a small ergonomic improvement to do `ReactNativeFeatureFlags.override` instead of `ReactNativeFeatureFlags.INSTANCE.override` in Java.
We already did this for the methods to access the feature flags in the same class.
Reviewed By: rshest
Differential Revision: D53516254
fbshipit-source-id: cdaa90b3baae4f780a42a96ebb07de78bd968019
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42917
If the app is not connected to Metro, the behavior of the refresh is different between bridgeless and bridge. This is because the `handleReloadJS` is implemented differently between the two support managers. I'm fixing it.
Changelog:
[Android] [Fixed] - Fix Reload behavior being different on Bridgeless
Reviewed By: cipolleschi
Differential Revision: D53526369
fbshipit-source-id: 63509b5595c3738a1d6d9eb4352036c174643770
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42906
Makes way to relocate repo E2E testing + Verdaccio logic under `scripts/e2e/`. The contents of this script are minimal and are better located with `rn-tester-e2e`.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D53516117
fbshipit-source-id: e7e50af0383788f2219da190bf921ea93a6455eb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42733
When we fixed the race condition between A11yManager and RCTUIManager, we did it by moving the A11yManager on a background queue.
In the old architecture, this was raising a warning which our users might find confusing. Plus, that change was not aligned with what the A11yManager declared in its configuration because we are actually initializing it starting from a BG queue.
{F1405693310}
With this change we anticipate the initialization of the module in a place where:
1. We know we are in the main queue
2. We know we are going to need it (so it is not violating the lazy load principle)
3. We know it is safe.
This should allow us to also remove the feature flag of `RCTUIManagerDispatchAccessibilityManagerInitOntoMain` because now it is safe to use the main_queue as requested by the module.
## Changelog:
[iOS][Fixed] - Initialize the A11yManager in the main queue and when we need it.
Reviewed By: philIip
Differential Revision: D53225120
fbshipit-source-id: fa6ef7fac380e17684cc02de0b4a46504b26bb3d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42896
Changelog:
[General][Fixed] Fix order of Metro hotkey console messages
# Existing
Key handler is printing messages to the console _after_ it has been processed, this causes error messages to appear before the `info` message.
# In this PR
The `info` messages are logged before the event is processed.
Reviewed By: GijsWeterings
Differential Revision: D53479732
fbshipit-source-id: 25af47450662de4eb03d0dfd52af5af014ef3e49
Summary:
For Bridgeless mode we set `fabric` and `concurrentRoot` property for newly initialized views. This example overwrites those properties. I think we should Instead copy previous dictionary and only overwrite `color` key.
This issue results in a warning: "Using Fabric without concurrent root is deprecated. Please enable concurrent root for this application."
Note: This Example crashes on Bridgeless but my other PR https://github.com/facebook/react-native/issues/42263 fixes it.
## Changelog:
[INTERNAL] [FIXED] - UpdatePropertiesExampleView to mutate existing `appProperties` instead of overwriting
Pull Request resolved: https://github.com/facebook/react-native/pull/42634
Test Plan:
1. Wait for this example to get fixed for Bridgeless
2. Click the button to update props
3. Check if there is no warning
Reviewed By: cortinico
Differential Revision: D53126953
Pulled By: cipolleschi
fbshipit-source-id: fa0e8bda50a47696467d279845616c2ba51fe310
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42821
As the title says, we want `concurrentRoot iif fabric`.
This makes sure we invoke renderApplication correctly.
Changelog:
[Internal] [Changed] - Set concurrentRoot to true whenever Fabric is used in renderApplication
Reviewed By: sammy-SC
Differential Revision: D53353017
fbshipit-source-id: 8de88adf528eb71f233233bd85c2c6ef9430fb16
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42892
## Changelog:
[Internal]-
This adds an ability to have multiple custom source transformers when resolving asset sources, which is beneficial in some scenarios.
The transformers are chained, being executed in order they are registered, until one of them returns a non-null value.
If none does, then the default one is returned.
Reviewed By: GijsWeterings
Differential Revision: D53472320
fbshipit-source-id: ed9baf8789b8bd41c8ce78eed71ebb65868cf178
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42829
This is the base query method that we can wrap to use specific matchers like `findByTestID` or `findByRole`
Changelog: [internal]
Reviewed By: noahlemen
Differential Revision: D53359005
fbshipit-source-id: d1ac9c503b05d479567b6ced71d4517d5bc55b0b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42873
Changelog:
[iOS][Fixed] Disable the "Open Debugger" item from dev menu if packager is disconnected
# Existing
In our dev menu, the "Open Debugger" menu item is shown even if the packager isn't connected.
{F1434746954}
# In this PR
The "Open Debugger" menu item is disabled when the packager is disconnected.
{F1451344668}
# Reference
* Also on Android: D53428914
Reviewed By: robhogan
Differential Revision: D53354110
fbshipit-source-id: 6eb4e826fe9317798c704a5441b5e462edab1c4b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42885
## Context
We're introducing the concept of **capability flags** to provide granular control of behaviours in the Inspector Proxy, to replace the recently added `type: 'Legacy' | 'Modern'` target switch.
A capability flag disables a specific feature/hack in the Inspector Proxy layer by indicating that the target supports one or more modern CDP features.
## This diff
Following D53355413, we're now able to remove the previous `type: 'Legacy' | 'Modern'` page concept, implemented in this diff.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D53358480
fbshipit-source-id: 62e53a1bd60760291ada3479121dfca9e1f6edbc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42884
## Context
We're introducing the concept of **capability flags** to provide granular control of behaviours in the Inspector Proxy, to replace the recently added `type: 'Legacy' | 'Modern'` target switch.
A capability flag disables a specific feature/hack in the Inspector Proxy layer by indicating that the target supports one or more modern CDP features.
## This diff
This updates the pages response in `jsinspector-modern` to send a capability flags configuration, replacing `InspectorPageType`/`"type"`.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D53355413
fbshipit-source-id: 710f9eb11fcc61ab06bfc3051517dd4dd204c68a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42818
## Context
We're introducing the concept of **capability flags** to provide granular control of behaviours in the Inspector Proxy, to replace the recently added `type: 'Legacy' | 'Modern'` target switch.
A capability flag disables a specific feature/hack in the Inspector Proxy layer by indicating that the target supports one or more modern CDP features.
## This diff
Implements a second granular flag, `nativeSourceCodeFetching`, and adds tests for this.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D53352242
fbshipit-source-id: 94b62d84c731c903c5f99f8206d5c91bc501d030
David Vacca
Alex Hunt
Edmond Chui
Nicola Corti
Jakub Romanczyk
Ramanpreet Nara
Joe Vilches
Eric Rozell
Riccardo Cipolleschi
Samuel Susla
Phillip Pan
Bart Tyrpien
Oskar Kwaśniewski
Janic Duplessis
Alex Taylor (alta)
Rubén Norte
Alex Hunt
Jakub Piasecki
Tommy Nguyen
Fabrizio Cucci
Ruslan Shestopalyuk
Jack Pope
