Summary:
Cocoapods 1.15 (https://github.com/facebook/react-native/issues/42698) current breaks the build, limit to version >= 1.13 & < 1.15
This is currently broken and affecting users, we'll remove this limit once Cocopods fixes the regression. It's currently blocking 0.73.3.
[iOS][Fixed] don't allow cocoapods 1.15.
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/42702
Test Plan:
```
bundle exec pod install
```
Reviewed By: cipolleschi
Differential Revision: D53180111
Pulled By: blakef
fbshipit-source-id: 4c5dd11db6d208e8d71249443a8f85e601913abd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42306
Internally, we have some computationally expensive checks in Debug mode when running Fabric.
However, these are not very useful in OSS and they were the cause of some issues which generated noise.
With this change, we are enabling those checks only in the Meta specific builds and making sure that the OSS won't incur in that cost.
## Changelog
[Internal] - Disable expensive Fabric checks when running Fabric in OSS
Reviewed By: cortinico, sammy-SC
Differential Revision: D52543696
fbshipit-source-id: 697f14fd21e884f293ea7cee8ee16fff73764996
Summary:
This PR removes the `apply_ats_config` function of ReactNativePodsUtils that was used inside `react_native_post_install` because it was preventing users from configuring `NSAllowsArbitraryLoads` to true in their projects, especially when building in CI as the plist file would be reset after running pod install.
[IOS] [CHANGED] - Remove ATS config patch from react_native_post_install
Pull Request resolved: https://github.com/facebook/react-native/pull/42637
Test Plan: Edit `Info.plist`, run `pod install` and check if changes have not been overwritten
Reviewed By: cortinico
Differential Revision: D53048299
Pulled By: cipolleschi
fbshipit-source-id: 8dc335fae2e05a62daf931a50fa3f7a314e76a2e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42396
Cmmunity reported [#42120](https://github.com/facebook/react-native/issues/42120) where React Native was crashing if RCTDeviceInfo native module was receiving a notification while the bridge is invalidating.
Upon investigation, I realized that:
1. The RCTDeviceInfo module is never invalidated
2. Observers are still observing even when the Bridge is in an invalidated state and it is not back up.
This change makes sure that we invalidate the `RCTDeviceInfo.mm` module and that we unregister the observers.
## Changelog:
[iOS][Fixed] - Make `RCTDeviceInfo` listen to invalidate events and unregister observers while invalidating the bridge
Reviewed By: RSNara
Differential Revision: D52912604
fbshipit-source-id: 1727bcdef5393b1bd5a272e2143bc65456c2a389
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40860
This diff adds support for the `AS` expression in TS sources. The following codegen declaration should work now:
```
export default codegenNativeComponent<NativeProps>(
'MyComponentView',
) as HostComponent<NativeProps>;
```
Changelog: [General][Added] - Handle TSAsExpression when looking for the codegen declaration
Reviewed By: shwanton
Differential Revision: D50225241
fbshipit-source-id: 247a3d341d742b548e82318d0fa21dff9884d2bd
Summary:
Dependency on `chalk` was introduced in https://github.com/facebook/react-native/pull/37510, but was never declared. In pnpm setups, the CLI fails to run because of this.
This needs to be picked to 0.73.
[GENERAL] [FIXED] - Declare missing dependency `chalk`
Pull Request resolved: https://github.com/facebook/react-native/pull/42235
Test Plan: n/a
Reviewed By: huntie
Differential Revision: D52660337
Pulled By: cortinico
fbshipit-source-id: 1cd45fcff72045c127773566a27103f1b38262b3
Summary:
In my mac, I use a case-sensitive volume and when I build a react-native 0.73 project it failed with an error that can't find the hermes release tarball to extract:
```
Node found at: /usr/local/bin/node
Preparing the final location
Extracting the tarball
tar: Error opening archive: Failed to open '/Volumes/Workspace/meet-art-link/ios/Pods/hermes-engine-artifacts/hermes-ios-0.73.1-Release.tar.gz'
```
Note the `...-Release.tar.gz` in the error. In the disk it's `...-release.tar.gz`.
The build fails in after download the release tarball in release mode because the hermes tarball name in the `replace_hermes_version.js` build script is capitalized, while the file is lowercase on disk.
The fix is to ensure the hermes tarball name's "build type" is lowercase just like the function that creates the tarballs in react-native release located in `hermes_utils.js` in `getHermesPrebuiltArtifactsTarballName()`.
Perhaps it's better to retrieve the tarball name from the same method it's generated? E.g.:
```js
const { getHermesPrebuiltArtifactsTarballName } = require('react-native/scripts/hermes/hermes-utils');
const tarballName = getHermesPrebuiltArtifactsTarballName(`${version}-${configuration}`);
const tarballURLPath = `${podsRoot}/hermes-engine-artifacts/${tarballName}`;
```
If yes, let me know to update the PR.
## 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
-->
[iOS][Fixed] - Fix release build error due to a casing issue in hermes tarball path after download prebuilt tarball
Pull Request resolved: https://github.com/facebook/react-native/pull/42160
Test Plan: Use a case sensitive volume or system and build react-native 0.73 in release mode, it will fail. Apply the patch in this PR and it will work fine.
Reviewed By: cortinico
Differential Revision: D52603439
Pulled By: cipolleschi
fbshipit-source-id: 41ed8d8202874f338e4aa3af88d9d28ec1b8b3d5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42133
## Changelog:
[General][Fixed] - TouchableBounce, TouchableHighlight and TouchableNativeFeedback dropping touches with React 18.
TouchableBounce, TouchableHighlight and TouchableNativeFeedback do not trigger onPress when used with React 18. This is because it resets its pressability configuration in `componentWillUnmount`. This is fine, we want to stop deliver events and restart all timers when component is unmounted.
```
componentWillUnmount(): void {
this.state.pressability.reset();
}
```
But TouchableBounce, TouchableHighlight and TouchableNativeFeedback were not restarting the pressability configuration when component was mounted again. It was restarting the configuration in `componentDidUpdate`, which is not called when component is unmounted and mounted again.
Reviewed By: fkgozali
Differential Revision: D52514643
fbshipit-source-id: 0d6ae4bb7c2a797cc443181459c5614da0ecfc7a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42121
## Changelog:
[General][Fixed] - TouchableWithoutFeedback and TouchableOpacity dropping touches with React 18.
TouchableWithoutFeedback and TouchableOpacity do not trigger onPress when used with React 18. This is because it resets its pressability configuration in `componentWillUnmount`. This is fine, we want to stop deliver events and restart all timers when component is unmounted.
```
componentWillUnmount(): void {
this.state.pressability.reset();
}
```
But TouchableWithoutFeedback and TouchableOpacity were not restarting the pressability configuration when component was mounted again. It was restarting the configuration in `componentDidUpdate`, which is not called when component is unmounted and mounted again.
Reviewed By: fkgozali
Differential Revision: D52388699
fbshipit-source-id: ef13194c6581c5d31d0f1cb465bfd0cf98d672ea
Summary:
When bridgeless is enabled, RN Tester New Architecture examples crashed with a StackOverflow Exception
The root cause of this issue is that MyLegacyViewManager is sending an event to JS during the execution of MyLegacyViewManager.createViewInstance() method.
This is a problem because the delivery of events depend on the "id" of the view, but the "id" of the view is set after MyLegacyViewManager.createViewInstance() finishes executing.
The documentations "implicitly" mentions to not set props during the execution of the ViewManager.createViewInstance() method:
https://reactnative.dev/docs/native-components-android#2-implement-method-createviewinstance
To fix this issue I'm removing the execution of the method that triggers the event.
bypass-github-export-checks
changelog: [Android][Fix] Fix rendering of 'RN Tester New Architecture examples' when bridgeless is enabled
Reviewed By: fkgozali
Differential Revision: D51047007
fbshipit-source-id: 17be493f79114fa402029063e79fabc1d90efc17
Summary:
This is a continuation of my [last PR](https://github.com/facebook/react-native/pull/40914) which improved the symbolication of unhandled promise rejections.
While I was developing another library I noticed I still got an error stack of the log adding and not of the error itself. The library I'm trying to debug does not throw a standard error object but rather a custom one, but it still contains the stack field. By passing this stack field to the logbox call I was able to get a better symbolicated stack trace. The exact line of the failure is not displayed but at least the correct file is.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[GENERAL] [ADDED] - Unhandled promise rejection - attach non-standard Error object stack info if possible
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/42079
Test Plan:
Test any unhandled promise rejection with a non-standard error (line 23, toString must not return `[object Error]`) and see if the correct (or at least a better) stack trace is shown.
Here is the one I got before and after this change:
<img src="https://github.com/facebook/react-native/assets/1634213/3d07faad-9535-42c9-8032-b4d8fe407e88" width="200" />
<img src="https://github.com/facebook/react-native/assets/1634213/2c39bd82-c7a1-4f58-8ac4-5c479bb96b6e" width="200" />
Reviewed By: huntie
Differential Revision: D52431711
Pulled By: cipolleschi
fbshipit-source-id: be2172d3b1e2fc3f72812faac372c83bc6dface2
Summary:
Follow up of https://github.com/facebook/react-native/pull/41284#issuecomment-1789516046
We should not rely on checking if the `React-hermes` pod is present to determine if hermes is enabled
## Changelog:
[IOS] [CHANGED] - Update ios pod post_install logic for detecting if hermes is enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/41286
Test Plan: Run `use_react_native!(hermes => false)` should not add `USE_HERMES = true;` to `project.pbxproj`
Reviewed By: blakef
Differential Revision: D50899654
Pulled By: cipolleschi
fbshipit-source-id: a5ab5b0117c61014e77b780c50bf349da92c6342
Summary:
I noticed this comment is still in Java in the Kotlin template. It also doesn't really work anymore since there is no packages variable.
To fix it I completed the comment with all code needed for it to work in kotlin. I think an older version of the template used to be more like:
```kotlin
val packages = PackageList(this).packages
// packages.add(MyReactNativePackage())
return packages
```
But then it requires adding a lint suppress annotation since packages variable can be simplified. I think this is simpler even if it makes the comment a few more lines.
## Changelog:
[GENERAL] [FIXED] - Fix comment about adding packages in android template
Pull Request resolved: https://github.com/facebook/react-native/pull/41856
Test Plan: Tested that uncommenting that code works
Reviewed By: cipolleschi
Differential Revision: D51987483
Pulled By: cortinico
fbshipit-source-id: d0135b5b536960017ccc7b25f92c75b3bd863cd9
Summary:
Since yesterday evening (why it is always friday evening???) CircleCI or Gem decided to update the default bundler version that is installed with `gem bundle install`.
Therefore, CI for iOS stopped working.
This change installs bundler's versions so that they are compatible with the Ruby version.
## Changelog:
[Internal] - Fix CI for iOS installing versions of bundler that are compatible with Ruby
Pull Request resolved: https://github.com/facebook/react-native/pull/41962
Test Plan: CircleCI is green
Reviewed By: GijsWeterings
Differential Revision: D52230544
Pulled By: cipolleschi
fbshipit-source-id: 2f96e16ecb94159953056e8de757ea4d249f80f0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41152
Building on byCedric's approach in https://github.com/facebook/metro/pull/991, and on D49954920, this diff passes stable, unique *logical device IDs* to the debugger connection infrastructure from Android and iOS.
See D49954920 for the precise stability and uniqueness requirements that these IDs meet.
Changelog:
[Changed][General] - Automatically reconnect to an existing debugger session on relaunching the app
Reviewed By: huntie
Differential Revision: D49954919
fbshipit-source-id: d4d918f0cbfd9df426e888845817e00410efb9d3
Riccardo Cipolleschi
Distiller
Blake Friedman
zhongwuzw
Gabriel Donadel
LIM Albert
Dmitry Rykun
Tommy Nguyen
Paul Schreiber
William Fernandes
Samuel Susla
Riccardo Cipolleschi
szymonrybczak
Distiller
Alex Hunt
Alex Hunt
Nick Gerleman
David Vacca
Oscar Franco
Luna
Luna Wei
Morritz
Janic Duplessis
Ivan Alexandrov
Moti Zilberman
Distiller