Summary:
Changelog: [iOS][Added]
this creates the RN privacy manifest in the ios build step if user has not created one yet. the reasons have been added for the following APIs:
NSPrivacyAccessedAPICategoryFileTimestamp
- C617.1: We use fstat and stat in a few places in the C++ layer. We use these to read information about the JavaScript files in RN.
NSPrivacyAccessedAPICategoryUserDefaults
- CA92.1: We access NSUserDefaults in a few places.
1) To store RTL preferences
2) As part of caching server URLs for developer mode
3) A generic native module that wraps NSUserDefaults
NSPrivacyAccessedAPICategorySystemBootTime
- 35F9.1: Best guess reason from RR API pulled in by boost
Reviewed By: cipolleschi
Differential Revision: D53687232
fbshipit-source-id: 6dffb1a6013f8f29438a49752e47ed75c13f4a5c
# Conflicts:
# packages/rn-tester/RNTesterPods.xcodeproj/project.pbxproj
Summary:
After a [recent change](https://github.com/facebook/react-native/commit/90296be1d4fab09a52e02dd09f34f819136d0a07) we break part of the integration with the debug menu, which is was using the presence/absence of the bridge to decide whether we were in bridge or bridgeless.
For backward compatibility reasosn, the bridge ivar is now populated with the bridgeProxy, so just checking whether is nil or not is not enough to verify whether we are in bridge or in bridgeless mode anymore.
## Changelog:
[iOS][Fixed] - Make sure that the Open Debugger appears in bridgeless mode
Reviewed By: fkgozali
Differential Revision: D56067897
fbshipit-source-id: e2501ed730ff35bc755c24ef400130c551032e28
Summary:
We would set the value of _bridge ivar to bridgeProxy for turbo module in bridgeless mode in https://github.com/facebook/react-native/issues/43757 , so we need to change the way of bridgeless/bridge check.
## Changelog:
[IOS] [FIXED] - Change bridgeless check in dev menu
Pull Request resolved: https://github.com/facebook/react-native/pull/43976
Test Plan: Dev menu shows bridgeless/bridge mode correctly.
Reviewed By: christophpurrer
Differential Revision: D56056640
Pulled By: cipolleschi
fbshipit-source-id: 1358c3027c1d5f12c70dd4486cc1d5975c7a185a
* Support launchOptions in bridgeless mode (#43757)
Summary:
Support launchOptions in bridgeless mode
bypass-github-export-checks
[IOS] [FIXED] - Support launchOptions in bridgeless mode
Pull Request resolved: https://github.com/facebook/react-native/pull/43757
Test Plan:
```
useEffect(() => {
const processInitialURL = async () => {
const url = await Linking.getInitialURL();
if (url !== null) {
console.log(`Initial url is: ${url}`);
}
};
processInitialURL();
}, []);
```
Reviewed By: javache
Differential Revision: D55790758
Pulled By: cipolleschi
fbshipit-source-id: 0f6aa6bdcebfc5bc42d632bea9193f122c1eb84f
* Fix Connect to Metro after Reload in Bridgeless mode (#43994)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43994
We received [this issue](https://github.com/facebook/react-native/issues/43764) from OSS where an app can't connect to Metro on reloads in the following scenario:
* Start the App when metro does not run.
* Observe the error screen
* Start Metro
* Press Reload
* Observe the error message again
While the desired behavior should be to connect to Metro now that this is running.
The root cause of the problem is that the RCTHost is initialized with a value of the `bundleURL` that is `nil`. Upon reload, the RCTHost is **not** recreated: the instance is restarted, but with the previous `bundleURL`, which is still `nil`.
The solution is to initialize the `RCTHost` with a closure that re-evaluate the `bundleURL` whenever it is invoked and to evaluate it only on `start`, to keep the initialization path light.
This way, when the app is started with Metro not running, the `bundleURL` is `nil`. But when it is reloaded with Metro starting, the `bundleURL` is properly initialized.
Note that the changes in this diff are not breaking as I reimplemented (and deprecated) the old initializer so that they should work in the same way.
[iOS][Fixed] - Let RCTHost be initialized with a function to provide the `bundleURL` so that it can connect to metro on Reload when the url changes.
Reviewed By: dmytrorykun
Differential Revision: D55916135
fbshipit-source-id: 6927b2154870245f28f42d26bd0209b28c9518f2
* Fix badly resolved merge conflicts
---------
Co-authored-by: zhongwuzw <zhongwuzw@qq.com>
Summary:
Changelog: [iOS][Added]
this change will be included in the RN CLI. so all new apps running the RN CLI to get created will get this manifest. the reasons have been added for the following APIs:
NSPrivacyAccessedAPICategoryFileTimestamp
- C617.1: We use fstat and stat in a few places in the C++ layer. We use these to read information about the JavaScript files in RN.
NSPrivacyAccessedAPICategoryUserDefaults
- CA92.1: We access NSUserDefaults in a few places.
1) To store RTL preferences
2) As part of caching server URLs for developer mode
3) A generic native module that wraps NSUserDefaults
NSPrivacyAccessedAPICategorySystemBootTime
- 35F9.1: Best guess reason from RR API pulled in by boost
Reviewed By: cipolleschi
Differential Revision: D53682756
fbshipit-source-id: 0426fe0002a3bc8b45ef24053ac4228c9f61eb85
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43999
Currently NewArch-BridgeMode is partially broken when creating views via `ReactDelegate`.
That's because we're using the ctor that doesn't account for `Boolean: fabricEnabled`.
That means that the `RootView` that it will be created are all having setIsFabric(FALSE).
This is causing problems like whitescreens on several reload + multiple warnings such as:
```
E com.facebook.react.bridge.ReactNoCrashSoftException: Cannot get UIManager because the context doesn't contain an active CatalystInstance.
```
Fixes#43692
See for more context on this issues: https://github.com/facebook/react-native/issues/43692
Changelog:
[Android] [Fixed] - Fix bridge mode by constructing ReactDelegate correctly
Reviewed By: cipolleschi
Differential Revision: D55921078
fbshipit-source-id: 2c21d089a49538402d546177bcdb26c8d7d5fbc1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43971
It turns out that we forgot to add a listener for the orientation change event in Bridgeless.
We used to have `UIApplicationDidChangeStatusBarOrientationNotification` but this is slightly unreliable because there might be use cases where the status bar has been hidden and, therefore, the event is not triggered.
This should fix an issue reported by OSS.
## Changelog:
[iOS][Fixed] - Make sure that the New Architecture listens to orientation change events.
Reviewed By: cortinico
Differential Revision: D55871599
fbshipit-source-id: c9b0634ec2126aa7a6488c2c56c87a9610fa1adf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43967
Following up https://github.com/facebook/react-native/issues/43943, the metro loading banner is presented twice in Bridgeless mode.
This happens because both the RCTInstance and the RCTHost are listening to the Reload Command and issuing the instructions to refetch the JSBundle and to present the banner.
The RCTInstance should not concern itself with lifecycle events, owned by the RCTHost.
## Changelog:
[iOS][Fixed] - Avoid to show Metro Loading banner twice.
Reviewed By: cortinico
Differential Revision: D55870640
fbshipit-source-id: addb67d3226f7d7db20736309172a42fc15f3aa3
Summary:
Working with gabrieldonadel, we realized that static frameworks of the React-RendererRuntime are not following the proper folder structure.
When a user tries to import `ReactCommon/RCTHost` in the app delegate, for example, the user ends up with an error and they can't find the files.
These changes fixes this by establishing the right folder structure in the static frameworks
## Changelog:
[Internal] - Make sure that React-RuntimeCore and JSErrorHandler are created with the proper structure for static frameworks
Pull Request resolved: https://github.com/facebook/react-native/pull/43846
Test Plan:
Tested locally on an app with 0.74.
Before: it failed to build.
After: it build successfully.
Reviewed By: cortinico
Differential Revision: D55741581
Pulled By: cipolleschi
fbshipit-source-id: 11ac0882d3feea05ef8904d55856ba5704b7a3b8
Summary:
In the Old Architecture and for Swift Libraries, these two methods are used to initialize a new disctionary but their implementation was missing so some libraries like lottie were failig to build.
## Changelog:
[Internal] - Implement missing `count` and `keyEnumerator` methods for RCTComposedViewRegistry
Pull Request resolved: https://github.com/facebook/react-native/pull/43850
Test Plan: Tested locally with the repro provided by SWM
Reviewed By: javache
Differential Revision: D55743648
Pulled By: cipolleschi
fbshipit-source-id: 7bdb92625341cd704b8b09920ab3223a2ca61a54
Summary:
With 0.74.rc-5 one bug which related to errors was fixed (https://github.com/facebook/react-native/issues/41950). However, the fix introduced another one: the shape of Error objects that come from native modules has changed. This PR attempts to fix that, though it's not (yet) doing it in a way that would be 100% compatible with the old arch.
The problem was observed on iOS, not sure what the situation is on Android but believe it's okay there.
edit: on Android, there are no issues but the `message` field is enumerable, so that part is different from ios (see logs below).
Consider this code, where `error` is produced from a promise rejection inside of a native module.
```ts
console.log(
'own properties: ',
JSON.stringify(Object.getOwnPropertyNames(error), null, 2),
);
console.log(
'own enumerable properties: ',
JSON.stringify(Object.entries(error), null, 2),
);
```
These are the results for
<details>
<summary>Old architecture</summary>
```
LOG Running "google-one-tap-example" with {"rootTag":1,"initialProps":{}}
LOG own properties: [
"stack",
"code",
"message",
"domain",
"userInfo",
"nativeStackIOS"
]
LOG own enumerable properties: [
[
"code",
"-5"
],
[
"message",
"RNGoogleSignIn: The user canceled the sign in request., Error Domain=com.google.GIDSignIn Code=-5 \"The user canceled the sign-in flow.\" UserInfo={NSLocalizedDescription=The user canceled the sign-in flow.}"
],
[
"domain",
"com.google.GIDSignIn"
],
[
"userInfo",
{
"NSLocalizedDescription": "The user canceled the sign-in flow."
}
],
[
"nativeStackIOS",
[
"0 ReactTestApp 0x0000000102f4a6d8 RCTJSErrorFromCodeMessageAndNSError + 112",
"1 ReactTestApp 0x0000000102eeedd0 __41-[RCTModuleMethod processMethodSignature]_block_invoke_2.73 + 152",
"2 ReactTestApp 0x0000000102e2ae24 +[RNGoogleSignin rejectWithSigninError:withRejector:] + 548",
"3 ReactTestApp 0x0000000102e2aa8c -[RNGoogleSignin handleCompletion:serverAuthCode:withError:withResolver:withRejector:fromCallsite:] + 184",
"4 ReactTestApp 0x0000000102e2a8e0 -[RNGoogleSignin handleCompletion:withError:withResolver:withRejector:fromCallsite:] + 236",
"5 ReactTestApp 0x0000000102e28628 __40-[RNGoogleSignin signIn:resolve:reject:]_block_invoke_2 + 100",
"6 ReactTestApp 0x0000000102dc9d80 __35-[GIDSignIn addCompletionCallback:]_block_invoke_2 + 132",
...
]
]
]
```
</details>
<details>
<summary>RN 74 rc-5 (with bridgeless on)</summary>
```
(NOBRIDGE) LOG Bridgeless mode is enabled
(NOBRIDGE) LOG Running "google-one-tap-example" with {"rootTag":1,"initialProps":{"concurrentRoot":true},"fabric":true}
(NOBRIDGE) LOG own properties: [
"stack",
"message",
"cause"
]
(NOBRIDGE) LOG own enumerable properties: [
[
"cause",
{
"code": "-5",
"message": "RNGoogleSignIn: The user canceled the sign in request., Error Domain=com.google.GIDSignIn Code=-5 \"The user canceled the sign-in flow.\" UserInfo={NSLocalizedDescription=The user canceled the sign-in flow.}",
"nativeStackIOS": [
"0 ReactTestApp 0x00000001023a7b38 RCTJSErrorFromCodeMessageAndNSError + 112",
"1 ReactTestApp 0x00000001026cf774 ___ZZN8facebook5react15ObjCTurboModule13createPromiseERNS_3jsi7RuntimeENSt3__112basic_stringIcNS5_11char_traitsIcEENS5_9allocatorIcEEEEU13block_pointerFvU13block_pointerFvP11objc_objectEU13block_pointerFvP8NSStringSH_P7NSErrorEEENK3$_0clES4_RKNS2_5ValueEPSQ_m_block_invoke.57 + 332",
"2 ReactTestApp 0x0000000102270958 +[RNGoogleSignin rejectWithSigninError:withRejector:] + 548",
"3 ReactTestApp 0x00000001022705c0 -[RNGoogleSignin handleCompletion:serverAuthCode:withError:withResolver:withRejector:fromCallsite:] + 184",
"4 ReactTestApp 0x0000000102270414 -[RNGoogleSignin handleCompletion:withError:withResolver:withRejector:fromCallsite:] + 236",
"5 ReactTestApp 0x000000010226e15c __40-[RNGoogleSignin signIn:resolve:reject:]_block_invoke_2 + 100",
"6 ReactTestApp 0x000000010220f328 __35-[GIDSignIn addCompletionCallback:]_block_invoke_2 + 132",
...
],
"domain": "com.google.GIDSignIn",
"userInfo": {
"NSLocalizedDescription": "The user canceled the sign-in flow."
}
}
]
]
```
</details>
<details>
<summary>with the diff from this PR</summary>
```
(NOBRIDGE) LOG own properties: [
"stack",
"message",
"code",
"nativeStackIOS",
"domain",
"userInfo"
]
(NOBRIDGE) LOG own enumerable properties: [
[
"code",
"-5"
],
[
"nativeStackIOS",
[
"0 ReactTestApp 0x000000010083b8f8 RCTJSErrorFromCodeMessageAndNSError + 112",
"1 ReactTestApp 0x0000000100b63534 ___ZZN8facebook5react15ObjCTurboModule13createPromiseERNS_3jsi7RuntimeENSt3__112basic_stringIcNS5_11char_traitsIcEENS5_9allocatorIcEEEEU13block_pointerFvU13block_pointerFvP11objc_objectEU13block_pointerFvP8NSStringSH_P7NSErrorEEENK3$_0clES4_RKNS2_5ValueEPSQ_m_block_invoke.57 + 332",
"2 ReactTestApp 0x0000000100704718 +[RNGoogleSignin rejectWithSigninError:withRejector:] + 548",
"3 ReactTestApp 0x0000000100704380 -[RNGoogleSignin handleCompletion:serverAuthCode:withError:withResolver:withRejector:fromCallsite:] + 184",
"4 ReactTestApp 0x00000001007041d4 -[RNGoogleSignin handleCompletion:withError:withResolver:withRejector:fromCallsite:] + 236",
"5 ReactTestApp 0x0000000100701f1c __40-[RNGoogleSignin signIn:resolve:reject:]_block_invoke_2 + 100",
"6 ReactTestApp 0x00000001006a30e8 __35-[GIDSignIn addCompletionCallback:]_block_invoke_2 + 132",
...
]
],
[
"domain",
"com.google.GIDSignIn"
],
[
"userInfo",
{
"NSLocalizedDescription": "The user canceled the sign-in flow."
}
]
]
```
</details>
You see there is a change compared to old arch because `message` is no longer own enumerable property. If that needs to change (I guess it should), it'd be nice if someone more familiar with JSI pointed me in the right direction. Even with this inconsistency, the PR is an improvement and would be nice to have this fix included in the next RC.
This is output from Chrome's console for completeness, just to have something to compare to:
```
let err = new Error('hello')
undefined
Object.getOwnPropertyNames(err)
> ['stack', 'message']
Object.entries(err)
> []
```
bypass-github-export-checks
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [FIXED] - add missing fields to native errors in new arch
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/43649
Test Plan: Tested locally with an example app running RN 74-rc 5
Reviewed By: cortinico
Differential Revision: D55690184
Pulled By: cipolleschi
fbshipit-source-id: 60a857b9871af888dcd526782b5e6b73c07c051a
Summary:
This allows build configuration named like `StagingDebug` to match with settings applied to `Debug` This fixes https://github.com/facebook/react-native/issues/43185
Custom build setting were only applied to `Debug` build configurations, preventing configurations named `StagingDebug` or similar to access the new experimental debugger, as reported in https://github.com/facebook/react-native/issues/43185
This now applies the setting to every configuration ending with `Debug`
## Changelog:
[IOS] [CHANGED] - fix: build settings for custom build configuration
Pull Request resolved: https://github.com/facebook/react-native/pull/43780
Reviewed By: dmytrorykun
Differential Revision: D55688996
Pulled By: cipolleschi
fbshipit-source-id: 1f34cd722f6acfaa08d3377e19a04d08af97ed7c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43661
# Changelog: [Internal]
1. Remove `BridgelessDebugReactPackage.java`, this was added in D43407534. Technically, its the same as `DebugCorePackage.java`.
2. `ReactInstance` to add `DebugCorePackage`, so `DebuggingOverlay` view manager will be included in the bridgeless build.
3. Fix `RNTesterApplication.kt` to NOT create `MyLegacyViewManager` for every possible viewManagerName, apart from `"RNTMyNativeView"`, return null instead.
Reviewed By: cortinico
Differential Revision: D55375350
fbshipit-source-id: 1d3cb6b5ad3c0248df1def9f37c8c49b308f4473
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43690
# Changelog: [Internal]
Fixes https://github.com/facebook/react-native/issues/43678.
The issue is that once `getInspectorDataForViewAtPoint` is imported, it should throw if RDT global hook was not injected. ReactDevTools overlay imports `getInspectorDataForViewAtPoint`, this is why it did throw in testing environment.
ReactDevToolsOverlay JSX-element is already gated with RDT global hook check, adding a deferred import, same as it was already implemented for Inspector.
Still unclear to me how this didn't throw all this time while using the Catalyst / RNTester.
Reviewed By: cortinico
Differential Revision: D55474774
fbshipit-source-id: 759e5e8227cc7534193e5b95616b6099c15f5cb5
Summary:
Now that RN is providing TS type information, many of those .d.ts files depend on types from react. In modern packagemanagers (Ex: pnpm) types/react will not be available to RN since it does not declare it as a dependency.
I also noticed that the types for react-native-popup-menu-android appear to be pointing to the wrong location.
Add types/react as a peerDependency on the packages that have .d.ts files that import from React.
Add types/react to peerDependencyMeta with optional:true to prevent users not using TS from requiring types/react.
[GENERAL] [ADDED] Added types/react as an optional peerDependency
Pull Request resolved: https://github.com/facebook/react-native/pull/43509
Reviewed By: cortinico
Differential Revision: D55225940
Pulled By: NickGerleman
fbshipit-source-id: 4cbab071928cb925baec45f55461559acc9a54e6
Summary:
I found in 0.74.0-rc.x, `ccache_enabled` is introduced. However, it is not being delivered via npm.
fixes https://github.com/facebook/react-native/issues/43633
Changelog: [iOS] [Fixed] - Adding ccache_clang wrapper scripts to package.json for distribution
Pull Request resolved: https://github.com/facebook/react-native/pull/43634
Reviewed By: cortinico
Differential Revision: D55308743
Pulled By: blakef
fbshipit-source-id: e89a4bb3a1fbf8562d880b4c9d25dc9083717ba6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43699
This diff initializes `RELEASE_VERSION` with the value that is provided by the `get_react_native_version` job (it stores its output into `/tmp/react-native-version`).
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D55484988
fbshipit-source-id: f0b5bb473096f3691f50152beb3181a454916fdc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43538
The Hermes RuntimeConfig for bridgeless accidentally force-disabled ES6Proxy, resulting in https://github.com/facebook/react-native/issues/43523
Let's remove the incorrect override.
To test using RNTester, add the following change:
```
diff --git a/packages/rn-tester/js/RNTesterAppShared.js b/packages/rn-tester/js/RNTesterAppShared.js
index 87cb6b69dfe..f2512d09c5a 100644
--- a/packages/rn-tester/js/RNTesterAppShared.js
+++ b/packages/rn-tester/js/RNTesterAppShared.js
@@ -50,6 +50,8 @@ const RNTesterApp = ({
);
const colorScheme = useColorScheme();
+ new Proxy({}, {});
+
const {
activeModuleKey,
activeModuleTitle,
```
Before this change, RNTester will get an error at start-up. After, the app loads correctly.
Changelog: [General][Fixed] Correctly keep ES6Proxy for bridgeless mode
Reviewed By: cortinico
Differential Revision: D55045780
fbshipit-source-id: 666b99712d35622f87d42f22a4611851df67d905
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:
Pull Request resolved: https://github.com/facebook/react-native/pull/43398
Implement onWindowFocusChange in Bridgeless by adding it to the ReactHostImpl
Changelog:
[Android][Breaking] Implement onWindowFocusChange in Bridgeless
Reviewed By: javache
Differential Revision: D54670119
fbshipit-source-id: 71f560e5a3bf0e853ac06955e67b8035f1ec0468
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43594
I've been migrating `react-native-view-shot` to Fabric by using the `InteropUiBlockListener`
and I've realized that the interop layer doesn't work well.
1. FabricUIManager needs to implement `UIBlockViewResolver` in order for the interop layer to work correctly.
2. We need to hook `addUIBlock` to the `didDispatchMountItems` callback otherwise the UIBlocks won't be executed at all.
Changelog:
[Android] [Fixed] - Fix InteropUIBlockListener to support react-native-view-shot on Bridgeless
Reviewed By: javache
Differential Revision: D55187939
fbshipit-source-id: d048b4b5eed77fa856fdfac17c0df5f23fd44844
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43563
Fixes https://github.com/facebook/react-native/issues/42874
## Sumary
D9405703 added some custom logic for Flings, to support FlatList scenarios where content is being added on the fly, during Fling animation. This works by allowing start Fling to not have bounds, then correcting/cancelling Fling when overscroll happens over a bound that would normally be allowed.
This has some math to try to determine max content length, and will clamp to this when scrolling over it. This logic is incorrect when content length is less than scrollview length, and we end up snapping to a negative offset.
This change adds clamping, so that we don't snap to negative position in horizontal scroll view. This clamping was already indirectly present on vertical scroll view. https://www.internalfb.com/code/fbsource/[b43cdf9b2fec71f5341ec8ff2d47e28a066f052e]/xplat/js/react-native-github/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/views/scroll/ReactScrollView.java?lines=609
## Test Plan
Above issue no longer reproes. Flinging while content is being added to horizontal FlatList still works correctly.
Changelog:
[Android][Fixed] - Fix Android HorizontalScrollView fling when content length less than ScrollView length
Reviewed By: javache
Differential Revision: D55108818
fbshipit-source-id: 7cf0065f9f92832cc2606d1c7534fc150407b9c9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43583
Fail during `pod install` if user's version of XCode is too old to avoid cryptic errors (e.g. https://github.com/reactwg/react-native-releases/issues/163).
I reused existing mechanism for version detection, though it may not be reliable for future versions of XCode.
Changelog:
[iOS][Changed] - Warn users during "pod install" if XCode is too old
Reviewed By: dmytrorykun
Differential Revision: D55149636
fbshipit-source-id: 78387ff19a6eb10f3ca0d4aa78e6b934ae3b0711
Summary:
- `rrc_textinput` at the moment points to a wrong subdirectory and needlessly adds a prefix path
- `rrc_text` is missing headers for `attributedstring` which it depends on
## Changelog:
[ANDROID] [FIXED] - Fixed prefab header paths for `rrc_text` and `rrc_textinput`
Pull Request resolved: https://github.com/facebook/react-native/pull/43591
Reviewed By: fkgozali
Differential Revision: D55199580
Pulled By: cortinico
fbshipit-source-id: 85126c00943f82e908a52e05587661597761852e
* fix(android): fix `ndkVersion` is unset when building from source (#43131)
Summary:
`ndkVersion` is unset when building from source using this guide: https://reactnative.dev/contributing/how-to-build-from-source
## Changelog:
[ANDROID] [FIXED] - Fix `ndkVersion` is unset when building from source
Pull Request resolved: https://github.com/facebook/react-native/pull/43131
Test Plan:
```
git clone https://github.com/microsoft/react-native-test-app.git
cd react-native-test-app
npm run set-react-version nightly
yarn
# Manually apply the patch in node_modules/react-native/ReactAndroid/build.gradle.kts
# Enable building from source
sed -i '' 's/#react.buildFromSource/react.buildFromSource/' example/android/gradle.properties
# Build
cd example/android
./gradlew assembleDebug
```
Reviewed By: christophpurrer
Differential Revision: D54006425
Pulled By: cortinico
fbshipit-source-id: 9ede64bc14af4cf609b7a4c12c5a1082bbc31f09
* Fix build from source for hermes-engine (#43609)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43609
When users are building from source for React Native they don't have an ndkVersion variable specified. So we want to fallback to the global NDK version we set for the whole build here.
Changelog:
[Android] [Fixed] - Fix build from source for hermes-engine
Reviewed By: dmytrorykun
Differential Revision: D55240603
fbshipit-source-id: 3c725a164b40e176548af8ada9fcb13d391ef017
---------
Co-authored-by: Tommy Nguyen <4123478+tido64@users.noreply.github.com>
* fix(iOS): add missing forward blocks to RCTRootViewFactory (#43526)
Summary:
This PR adds missing forwarding blocks to RCTRootViewFactory, currently when a user tries to override `sourceURLForBridge` in AppDelegate it isn't overridden.
## Changelog:
[IOS] [FIXED] - add missing forward blocks to RCTRootViewFactory
Pull Request resolved: https://github.com/facebook/react-native/pull/43526
Test Plan: Override: `extraModulesForBridge`, `extraLazyModuleClassesForBridge`, `bridge didNotFindModule`, `sourceURLForBridge:` methods in AppDelegate and check if they are called on old architecture
Reviewed By: philIip
Differential Revision: D55186872
Pulled By: cortinico
fbshipit-source-id: 5988c7bab1439ccc4885b7337336c1e120ba9ea6
(cherry picked from commit 9d79f05e68)
* Follow-up with Review Feedback on RCTAppDelegate from #43526 (#43607)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43607
PR #43526 was accidentally merged with several changes excluded. I'm following up on those here.
Changelog:
[Internal] [Changed] - Follow-up with Review Feedback on RCTAppDelegate from #43526
Reviewed By: dmytrorykun
Differential Revision: D55240435
fbshipit-source-id: c296a1e14b7032b211551334ca7b5a6824e8d45c
(cherry picked from commit 84c1c6ea9b)
---------
Co-authored-by: Oskar Kwaśniewski <oskarkwasniewski@icloud.com>
Co-authored-by: Nicola Corti <ncor@meta.com>
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:
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
# Conflicts:
# scripts/releases-ci/prepare-package-for-release.js
Summary:
`registerCallableModule()` was added from 7f549ec7be but no typescript types there. this pr tries to add the corresponding types.
## Changelog:
[GENERAL] [FIXED] - Add missing `registerCallableModule` TypeScript definitions
Pull Request resolved: https://github.com/facebook/react-native/pull/43366
Test Plan: patch locally and try to `import { registerCallableModule } from 'react-native';` in a 0.74.0-rc.2 project
Reviewed By: fabriziocucci
Differential Revision: D54676151
Pulled By: cortinico
fbshipit-source-id: cd01f2ebe2d2516b458fae5b2e83cba3d3794455
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/43323
This fixes a seemingly pre-existent misconfiguration within our `test_ios_template` E2E test setup in CircleCI.
**Background**
We call `npx react-native-community/cli init` with the `--skip-install` flag, as part of the bootstrapping logic in `scripts/e2e/init-template-e2e.js`. This is necessary because we later want to explicitly call `npm install` with a custom `--registry` for our locally mirrored packages (via Verdaccio).
For some reason, we were observing unexpected differences when this was run under CircleCI:
1. Runs `yarn init`
2. Runs a `yarn add` (unknown pkg)
{F1464781818}
https://app.circleci.com/pipelines/github/facebook/react-native/42725/workflows/f648468b-e916-4501-887d-ad293aa6fccf/jobs/1398950
This is causing a Yarn-based install ahead of where we want — ignoring the `--skip-install` flag.
*I'm still unsure on the exact LOC cause in CLI* (but most likely, it's around the Yarn v3 move).
**Impact of this fix**
- The above meant that, when we were bootstrapping `test_ios_template` previously, packages weren't being read from Verdaccio, but **instead from npm** — using the `"0.74.0"` versions from the *previous branch cut* ❌.
- After D54006327, this behaviour became breaking 💀 — since for the 0.74 -> 0.75 cut, we no longer physically published `"0.75.0-main"` (new format) packages to npm.
**This change**
I'm passing `--pm npm` to `npx react-native-community/cli init` to skip around any Yarn behaviour. This appears to have removed the erroneous `yarn` invocations ✅.
Changelog: [Internal]
bypass-github-export-checks
Reviewed By: cortinico, cipolleschi
Differential Revision: D54536848
fbshipit-source-id: 473b11924955f5787c82a6c81d4527d77b810aa5
Summary:
Addresses a gap when using the `set-version` script to update all packages on `main` (i.e. post branch cut):
- Package versions were not being set consistently. It is safe to version all workspace packages, including `"private"`.
- Our publishing workflow is independent from this, and only considers public packages for submission to npm.
- We also need to update the root `package.json`, which includes `devDependencies` referencing workspace dependencies.
Unblocks https://github.com/facebook/react-native/pull/43132.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D54419456
fbshipit-source-id: 93eee669c5cf7c2f16b68a2bf41e9a8ace5521bf
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:
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/43314
Changelog: [Internal]
making call invoker a breaking change to runtime executor in 0.74 seems to be causing a lot of discourse. let's simplify things and first add the callinvoker to the backwards compat layer
Reviewed By: cipolleschi
Differential Revision: D54404845
fbshipit-source-id: 983e86829030557033b95625dab9068492739417
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43296
Fix CI by adding explicit visibility modifier to the newly added `BridgelessCatalystInstance` class. In Kotlin, in explicit API mode, which is usually the default mode for Kotlin, we must explicitly specify one of the modifiers for every declaration to make it clear and explicit.
Changelog:
[Internal] internal
Reviewed By: makovkastar
Differential Revision: D54442485
fbshipit-source-id: 4409ff810a09cc4fadcd2ccf21f7fbac3015f413
Summary:
In order to make the legacy APIs of Catalyst Instance backwards compatible, introducing a regular class that implements CatalystInstance so as to make these APIs available for folks in Bridgeless mode as well.
Changelog:
[Internal] internal
Reviewed By: RSNara
Differential Revision: D54093013
fbshipit-source-id: f494c05e79f570883f9b5374cd177862970304c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43195
Right now, the activity indicator is automatically hidden when the view is ready to be shown in bridgeless mode.
There is no way to prevent that the activity indicator is automatically removed.
In OSS, we have libraries (e.g.: `react-native-bootsplash`) that will allow the app to control when and how dismiss the splashscreen, but due to the current automatic behavior on Bridgeless, they stopped working.
***Note:** In the previous implementation, they were working because instead of using the `loadingView` property, they were adding the splashscreen view on top of the existing one. However, with the lazy behavior of the bridgeless mode, this is not working anymore because the RCTMountingManager [expect not to have any subview](https://www.internalfb.com/code/fbsource/[6962fa457dbc74ab3a760cf6090d9643c6748781]/xplat/js/react-native-github/packages/react-native/React/Fabric/Mounting/RCTMountingManager.mm?lines=176) when the first surface is mounted.*
## Changelog
[iOS][Added] - Allow the activityIndicator to be controlled from JS in bridgeless mode
Reviewed By: philIip
Differential Revision: D54191856
fbshipit-source-id: 14738032f04adf7eaf7d200d889acd752aed0ed3
Summary:
This is a proposal for the `react-native/dev-middleware` package, to allow implementers to extend the CDP capabilities of the `InspectorProxy`. It's unfortunately needed until we can move to the native Hermes CDP layer.
At Expo, we extend the CDP capabilities of this `InspectorProxy` by injecting functionality on the device level. This proposed API does the same, but without having to overwrite internal functions of both the `InspectorProxy` and `InspectorDevice`.
A good example of this is the network inspector's capabilities. This currently works through the inspection proxy, and roughly like:
- Handle any incoming `Expo(Network.receivedResponseBody)` from the _**device**_, store it, and stop event from propagating
- Handle the incoming `Network.getResponseBody` from the _**debugger**_, return the data, and stop event from propagating.
This API brings back that capability in a more structured way.
## API:
```ts
import { createDevMiddleware } from 'react-native/dev-middleware';
const { middleware, websocketEndpoints } = createDevMiddleware({
unstable_customInspectorMessageHandler: ({ page, deviceInfo, debuggerInfo }) => {
// Do not enable handler for page other than "SOMETHING", or for vscode debugging
// Can also include `page.capabilities` to determine if handler is required
if (page.title !== 'SOMETHING' || debuggerInfo.userAgent?.includes('vscode')) {
return null;
}
return {
handleDeviceMessage(message) {
if (message.type === 'CDP_MESSAGE') {
// Do something and stop message from propagating with return `true`
return true;
}
},
handleDebuggerMessage(message) {
if (message.type === 'CDP_MESSAGE') {
// Do something and stop message from propagating with return `true`
return true;
}
},
};
},
});
```
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[GENERAL] [ADDED] - Add inspector proxy device message middleware API
Pull Request resolved: https://github.com/facebook/react-native/pull/43291
Test Plan: See added tests and code above
Reviewed By: huntie
Differential Revision: D54804503
Pulled By: motiz88
fbshipit-source-id: ae918dcd5b7e76d3fb31db4c84717567ae60fa96
Summary:
At Expo, we use [Expo Tools](https://github.com/expo/vscode-expo/blob/main/src/expoDebuggers.ts) to connect the [built-in vscode-js-debug](https://github.com/microsoft/vscode-js-debug) to Hermes.
Since there are a few differences in vscode vs chrome devtools, we need to enable a couple of modifications through the [`customMessageHandler` API](https://github.com/facebook/react-native/pull/43291). Unfortunately, vscode itself doesn't set the `user-agent` header when connecting to the inspector proxy. Becuase of that, we'd need a fallback to "manually" mark the debugger as being vscode ([we use this query parameter here](https://github.com/expo/vscode-expo/blob/main/src/expoDebuggers.ts#L208)).
This PR supports setting the `user-agent` through `?userAgent=` when the header is not set.
## 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
-->
[GENERAL] [ADDED] - Fallback to query parameter based `user-agent` when header is unset
Pull Request resolved: https://github.com/facebook/react-native/pull/43364
Test Plan:
- Install [Expo Tools](https://marketplace.visualstudio.com/items?itemName=expo.vscode-expo-tools)
- Start Metro with this change.
- Connect a device.
- Run the vscode command `"Expo: Debug Expo app ..."`
- Debugger should connect, and have it's user-agent marked as:
`vscode/1.87.0 vscode-expo-tools/1.3.0`
Reviewed By: huntie
Differential Revision: D54804556
Pulled By: motiz88
fbshipit-source-id: 1ff558ba5350811ad042d08a713438e046759feb
Summary:
The inspector proxy is inlining source maps on `Debugger.scriptParsed` CDP events. The inlining prevents Chrome DevTools from downloading this remotely, as that's not supported in newer versions anymore.
The current implementation locks this inlining mechanism to just `localhost` and/or `127.0.0.1` addresses, making it incompatible with LAN or tunnel device connections.
This PR removes that limitation to allow source map inlining on these LAN and tunnel connections.
## 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
-->
[GENERAL][FIXED] Allow Inspector proxy to inline source maps on LAN connections
Pull Request resolved: https://github.com/facebook/react-native/pull/43307
Test Plan:
- See added test
- Start Metro and connect a device over LAN, open the chrome devtools
Reviewed By: huntie
Differential Revision: D54485247
Pulled By: robhogan
fbshipit-source-id: 6fcb0c6dd762d2f0a013497ba0a1126095b9130b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43460
Currently pressing the menu button (or CMD+M) is broken on Bridgeless mode.
Also pressing RR is not reloading the App.
That's because some Bridgeless API haven't been reimplemented correctly on Android. I'm fixing them here.
Fixes#43451
Changelog:
[Android] [Fixed] - Properly handle RR and CMD+M in Bridgeless Mode
Reviewed By: huntie
Differential Revision: D54852959
fbshipit-source-id: 8fbbdab6818da9177e6db40e45d35258c7f5e236
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43491
This diff brings back the `UNSET` constant to `TextAttributeProps`.
The removal of this constant was an unnecessary breaking change, that has broken several third-party libraries.
Changelog: [Android][Fixed] - Bring back the UNSET constant to TextAttributeProps.
Reviewed By: fabriziocucci
Differential Revision: D54899524
fbshipit-source-id: 368bde77d43f310fd458537d0191d09174fa5167
Summary:
X-link: https://github.com/facebook/yoga/pull/1593
Pull Request resolved: https://github.com/facebook/react-native/pull/43417
There was a bug where we did not position absolute nodes correctly if the static node had a different main/cross axis from the containing node. This fixes that. The change is somewhat complicated unfortunately but I tried to add sufficient comments to explain what is happening
Reviewed By: NickGerleman
Differential Revision: D54703955
fbshipit-source-id: 096c643f61d4f9bb3ee6278d675ebd69b57350d7
Summary:
This adds the `nativeNetworkInspection` target capability flag, to enable/disable the proxy-side network inspection handling.
## 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
-->
[GENERAL][ADDED] Add inspector proxy `nativeNetworkInspection` target capability flag
Pull Request resolved: https://github.com/facebook/react-native/pull/43310
Test Plan:
Once this lands, and is published through `react-native/dev-middleware`, we (Expo) can disable the proxy-side network inspection handling.
See https://github.com/expo/expo/pull/27425/commits/1a1b601a29fbc5766628238db7259121689f6cd6 on PR expo/expo#27425
Reviewed By: christophpurrer, motiz88
Differential Revision: D54486516
Pulled By: huntie
fbshipit-source-id: cc151349c816fb3866d3ec07af1a29a5f4ff9b00
Summary:
Commit https://github.com/facebook/react-native/commit/73664f576aaa472d5c8fb2a02e0ddd017bbb2ea4 broke two jobs in CircleCI that we run using Xcode 14.3.1 because the commit introduced some types that are available only to iOS 17.
The code was wrapped around if(available()) statement, but this does not compile out the code. It is a runtime check and the code needs to build anyway.
This takes effect at compile time as well. However, unlike with #available, the method must type check and compile. The code will always be emitted into your binary: however, it will only be used when the binary is executed on platforms that meet the availability requirements.
source: [forums.swift.org/t/if-vs-available-vs-if-available/40266/2](https://forums.swift.org/t/if-vs-available-vs-if-available/40266/2)
This change should fix it, introducing some compile time pragmas that removes the code if we build with older versions of Xcode
## Changelog:
[IOS] [ADDED] - Compiler conditionals for hover style (cursor: pointer)
Pull Request resolved: https://github.com/facebook/react-native/pull/43331
Test Plan: CI Green
Reviewed By: dmytrorykun
Differential Revision: D54540520
Pulled By: cipolleschi
fbshipit-source-id: 943ac479062e11969efa7645ec0ead26c6866374
Summary:
This PR implements `RCTRootViewFactory` a utility class (suggested by cipolleschi) that returns proper RCTRootView based on the current environment state (new arch/old arch/bridgeless). This class aims to preserve background compatibility by implementing a configuration class forwarding necessary class to RCTAppDelegate.
This PR leverages the `RCTRootViewFactory` in `RCTAppDelegate` for the default initialization of React Native (greenfield).
Here is an example of creating a Brownfield integration (without RCTAppDelegate) using this class (can be later added to docs):
1. Store reference to `rootViewFactory` and to `UIWindow`
`AppDelegate.h`:
```objc
interface AppDelegate : UIResponder <UIApplicationDelegate>
property(nonatomic, strong) UIWindow* window;
property(nonatomic, strong) RCTRootViewFactory* rootViewFactory;
end
```
2. Create an initial configuration using `RCTRootViewFactoryConfiguration` and initialize `RCTRootViewFactory` using it. Then you can use the factory to create a new `RCTRootView` without worrying about old arch/new arch/bridgeless.
`AppDelegate.mm`
```objc
implementation AppDelegate
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary<UIApplicationLaunchOptionsKey,id> *)launchOptions {
// Create configuration
RCTRootViewFactoryConfiguration *configuration = [[RCTRootViewFactoryConfiguration alloc] initWithBundleURL:self.bundleURL
newArchEnabled:self.fabricEnabled
turboModuleEnabled:self.turboModuleEnabled
bridgelessEnabled:self.bridgelessEnabled];
// Initialize RCTRootViewFactory
self.rootViewFactory = [[RCTRootViewFactory alloc] initWithConfiguration:configuration];
// Create main root view
UIView *rootView = [self.rootViewFactory viewWithModuleName:@"RNTesterApp" initialProperties:@{} launchOptions:launchOptions];
// Set main window as you prefer for your Brownfield integration.
self.window = [[UIWindow alloc] initWithFrame:[UIScreen mainScreen].bounds];
UIViewController *rootViewController = [UIViewController new];
rootViewController.view = rootView;
self.window.rootViewController = rootViewController;
[self.window makeKeyAndVisible];
// Later in the codebase you can initialize more rootView's using rootViewFactory.
return YES;
}
end
```
bypass-github-export-checks
[INTERNAL] [ADDED] - Implement RCTRootViewFactory
Pull Request resolved: https://github.com/facebook/react-native/pull/42263
Test Plan: Check if root view is properly created on app initialization
Reviewed By: dmytrorykun
Differential Revision: D53179625
Pulled By: cipolleschi
fbshipit-source-id: 9bc850965ba30d84ad3e67d91dd888f0547c2136
Summary:
The `react_render_textlayoutmanager` was not exposed via prefab. I'm adding it to make possible for react-native-live-markdown to integrate on top of React Native via prefab. Based on https://github.com/facebook/react-native/issues/36166.
## 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
-->
[ANDROID] [CHANGED] - Expose `react_render_textlayoutmanager` via prefab.
Pull Request resolved: https://github.com/facebook/react-native/pull/43381
Reviewed By: javache
Differential Revision: D54676207
Pulled By: cortinico
fbshipit-source-id: 90e3b90ff842250bf1e3abcc0c54f057b68a82fd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43370
Component stacks with files ending in .ts, .tsx, or .jsx were skipped in LogBox reporting. This diff fixes the regex.
Changelog:
[General][Fixed] - Support .tsx, .ts, and .jsx in component stacks
Reviewed By: yungsters
Differential Revision: D54638526
fbshipit-source-id: a5271daaa7b687e8e075be3f94ab9b9c03f79b66
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43334
cortinico flagged that bridge + fabric regressed in 0.74, likely due to D53406841.
Changelog: [Android][Fixed] Fix registration of ViewManagers in new renderer when not using lazyViewManagers.
Reviewed By: fkgozali
Differential Revision: D54551645
fbshipit-source-id: 0783030cd0d2900a3a254ae04c9ea4e51035272a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43293
Was debugging this, and found that this exception was being thrown due to `DefaultBindingsInstaller`, which was an invalid hybrid object. The ReactInstance initializer fully supports this being null, so let's use that as default.
Changelog: [Android][Fixed] NullPointerException is no longer ignored in MessageQueueThreadHandler
Reviewed By: sammy-SC
Differential Revision: D54434417
fbshipit-source-id: 52417b390061eface0f0578e32796d3a85303e03
Summary:
The `rrc_text` was not exposed via prefab. I'm adding it to make possible for react-native-live-markdown to integrate on top of React Native via prefab. Based on https://github.com/facebook/react-native/issues/36166.
## 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
-->
[ANDROID] [CHANGED] - Expose `rrc_text` via prefab.
Pull Request resolved: https://github.com/facebook/react-native/pull/43275
Reviewed By: cipolleschi
Differential Revision: D54536468
Pulled By: cortinico
fbshipit-source-id: 8c4ef983467bfc46930f10bf7bd95761c2d11788
Summary:
The `rrc_textinput` was not exposed via prefab. I'm adding it to make possible for react-native-live-markdown to integrate on top of React Native via prefab. Based on https://github.com/facebook/react-native/issues/36166.
## 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
-->
[ANDROID] [CHANGED] - Expose `rrc_textinput` via prefab.
Pull Request resolved: https://github.com/facebook/react-native/pull/43274
Reviewed By: cipolleschi
Differential Revision: D54482657
Pulled By: cortinico
fbshipit-source-id: ca7f4127f1808f841d88925238666e837de75bd0
Summary:
This change renames `PopupMenuAndroidNativeComponent.js` to `PopupMenuAndroidNativeComponent.android.js`.
The reason is that, without the suffix, Codegen was reading the NativeComponent spec also for iOS, generating some invalid specs and making RNTester fail.
## Changelog:
[Android][Changed] - Rename `PopupMenuAndroidNativeComponent.js` to `PopupMenuAndroidNativeComponent.android.js`
Reviewed By: cortinico, dmytrorykun
Differential Revision: D54199736
fbshipit-source-id: 7fd67c4d38a69fe3a84c800c8ee5dcbd8c4f9a6c
Summary:
**History:** This component was originally introduced into React Native core in D52712758, to replace UIManagerModule.showPopupMenu().
**Problem:** But, React Native core should be lean. Adding this component to React Native bloats the core.
**Changes:** So, this diff pulls PopupMenuAndroid out into its own package in the react-native GitHub repository.
In the future, this will be migrated to a community package!
Changelog: [Android][Removed] Move PopupMenu out of React Native core
Reviewed By: NickGerleman
Differential Revision: D53328110
fbshipit-source-id: 469d8dc3e756c06040c72e08fa004aafa1bd6e18
Summary:
After discussing with mdvacca, we prefer to undo the change of `TurboModule` package to `.internal` as this is a quite aggressive breaking change for the ecosystem.
Moreover: users should not invoke `TurboModule.class.isAssignableFrom` because `TurboModule` is `.internal`. Therefore I'm exposing another API to check if a class is a TurboModule as a static field of `ReactModuleInfo`.
## Changelog:
[INTERNAL] - Do not use TurboModule.class.isAssignableFrom
Pull Request resolved: https://github.com/facebook/react-native/pull/43219
Test Plan: Tests are attached
Reviewed By: mdvacca, cipolleschi
Differential Revision: D54280882
Pulled By: cortinico
fbshipit-source-id: 9443c8aa23cf70dd5cfe574fe573d83313134358
Summary:
This PR fixes an issue that `_logWarnIfCreateRootViewWithBridgeIsOverridden` was called in wrong place.
Assuming user overrides this method and call to `[super]`:
```objc
- (UIView *)createRootViewWithBridge:(RCTBridge *)bridge moduleName:(NSString *)moduleName initProps:(NSDictionary *)initProps {
UIView *view = [super createRootViewWithBridge:bridge moduleName:moduleName initProps:initProps];
view.backgroundColor = [UIColor redColor];
return view;
}
```
This method still wasn't called in bridgeless (and not showing the error).
Checking if user overrides this method in `appDidFinishWithLaunching` works every time
## Changelog:
[IOS] [FIXED] - Properly warn about `createRootViewWithBridge` being deprecated
Pull Request resolved: https://github.com/facebook/react-native/pull/43146
Test Plan: Check if warning is shown when message is overridden
Reviewed By: huntie
Differential Revision: D54303506
Pulled By: cipolleschi
fbshipit-source-id: cf30555c791493f28b3015a189cf93b60cace8f8
Summary:
This change align the `getSurfacePresenter` and `getModuleRegistry` to the iOS convention for which these should be computed properties with no `get` prefix in their name.
We want to land this change and to pick it in 0.74 so we can remove the `get` versions in 0.75.
## Changelog:
[iOS][Deprecated] - Deprecate `getSurfacePresenter` and `getModuleRegistry` for `surfacePresenter` and moduleRegistry` props.
Reviewed By: javache
Differential Revision: D54253805
fbshipit-source-id: e9ff7db744a73a3bd0f8ae1d87875e54ddd9a1a4
Summary:
This diff removes extra argument from the `extractLibrariesFromJSON` call inside `findLibrariesFromReactNativeConfig`.
This should fix the iOS failurte discribed in https://github.com/facebook/react-native/issues/43204
Changelog: [iOS][Fixed] - Codegen correctly handles react-native.config.js.
Reviewed By: cipolleschi
Differential Revision: D54248400
fbshipit-source-id: 2ae5d0d29f49725877559a5b0edd7d59f8bdefaa
Summary:
Changelog: [General][Fixed] Re-enable listing Hermes debugger targets in chrome://inspect, broken in 0.74 RC
Fixes https://github.com/facebook/react-native/issues/43259.
Reverts D52958725 and fixes the original `Content-Length` Unicode bug using a different approach.
Reviewed By: fabriziocucci
Differential Revision: D54409847
fbshipit-source-id: ed5bb464ab67f37535947646b124814d8bbf797c
Summary:
Those files should not stay in the root `/app` folder but inside the `/app/gradle/wrapper` folder.
I've noticed this in the Upgrade Helper UI hence I'm removing them.
Changelog:
[Internal] [Changed] - Remove accidental files included inside the template
Reviewed By: mdvacca
Differential Revision: D54122995
fbshipit-source-id: 8873a91ffbea20f609c7aabd428a815c77a38db5
Summary:
RN-Tester is currently instacrashing on fast-refresh (pressing r on Metro) as it ends up on `onJSBundleLoadedFromServer`
which throws an exception on Bridgeless mode. I'm fixing it by following the same logic as `onReloadWithJSDebugger`.
Changelog:
[Android] [Fixed] - Do not crash on onJSBundleLoadedFromServer when fast-refreshing on bridgeless mode
Reviewed By: huntie
Differential Revision: D54121838
fbshipit-source-id: 82d98ec0c5b2295f5751525368c956574dd7f3a0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43049
This connects the OnLoad.cpp file used by OSS apps with the `rncli_cxxModuleProvider`.
This method is created by the CLI and takes care of querying all the TM CXX Modules discovered and returning them.
This PR is currently waiting on https://github.com/react-native-community/cli/pull/2296
Changelog:
[Internal] [Changed] - Hook the default-app-setup OnLoad.cpp file with the cxxModuleProvider from RNCLI
Reviewed By: cipolleschi
Differential Revision: D53812109
fbshipit-source-id: 47bc0ea699516993070cfa0127de97853acf8890
@@ -1020,6 +1020,54 @@ Please follow the instructions at: fburl.com/rn-remote-assets`,
});
});
it('detects a component stack for ts, tsx, jsx, and js files',()=>{
expect(
parseLogBoxLog([
'Some kind of message\n in MyTSComponent (at MyTSXComponent.ts:1)\n in MyTSXComponent (at MyTSCComponent.tsx:1)\n in MyJSXComponent (at MyJSXComponent.jsx:1)\n in MyJSComponent (at MyJSComponent.js:1)',
]),
).toEqual({
componentStack:[
{
content:'MyTSComponent',
fileName:'MyTSXComponent.ts',
location:{
column:-1,
row:1,
},
},
{
content:'MyTSXComponent',
fileName:'MyTSCComponent.tsx',
location:{
column:-1,
row:1,
},
},
{
content:'MyJSXComponent',
fileName:'MyJSXComponent.jsx',
location:{
column:-1,
row:1,
},
},
{
content:'MyJSComponent',
fileName:'MyJSComponent.js',
location:{
column:-1,
row:1,
},
},
],
category:'Some kind of message',
message:{
content:'Some kind of message',
substitutions:[],
},
});
});
it('detects a component stack in the first argument (JSC)',()=>{
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Distiller
Alex Hunt
Distiller
Riccardo Cipolleschi
Phillip PanandAlex Hunt
Riccardo CipolleschiandAlex Hunt
zhongwuzwandAlex Hunt
Arushi KesarwaniandAlex Hunt
Nicola Corti
Distiller
Evert EtiandNicola Corti
Distiller
Vojtech NovakandNicola Corti
Jean-Baptiste LARRIVIEREandNicola Corti
Dmitry RykunandNicola Corti
Distiller
Szymon RybczakandGitHub
phillipandGitHub
Ruslan LesiutinandAlex Hunt
Andrew CoatesandAlex Hunt
CatStudioAppandAlex Hunt
Kevin GozaliandAlex Hunt
Distiller
Nick GerlemanandAlex Hunt
Gabriel DonadelandAlex Hunt
Jakub PiaseckiandAlex Hunt
Cedric van PuttenandAlex Hunt
Alex HuntandAlex Hunt
Distiller
Cedric van PuttenandAlex Hunt
Joe VilchesandAlex Hunt
Distiller
Saad NajmiandAlex Hunt
Tomek ZawadzkiandAlex Hunt
Rick HanlonandAlex Hunt
Pieter De BaetsandAlex Hunt
Luna Wei
Distiller
Ramanpreet NaraandAlex Hunt
Moti ZilbermanandAlex Hunt
Distiller
Diego SeguraandNicola Corti
Distiller