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
CatStudioApp
Dmitry Rykun
Kevin Gozali
Alex Hunt
Distiller
Nicola Corti
Arushi Kesarwani
Nick Gerleman
Gabriel Donadel
Jakub Piasecki
Cedric van Putten
Alex Hunt
Distiller
Phillip Pan
Riccardo Cipolleschi
Cedric van Putten