Summary:
changelog: [internal]
Exposes a new flag on RuntimeScheduler: `unstable_getIsSynchronous`. Flag indicates if the current code is run synchronously and therefore commit phase should be synchronous.
Unit tests will be added later, to keep this diff short. This code path is not executed yet.
Reviewed By: mdvacca, ShikaSD
Differential Revision: D32677814
fbshipit-source-id: e01d4fff7e716d627ff99fe104965851138c3aef
Summary:
This class is not used and can be safely deleted
Changelog: [Internal] Delete unused Android event emitter
Reviewed By: mdvacca
Differential Revision: D32916706
fbshipit-source-id: 6dceb6b6ed9d201d96454bf0d646853c5c893d59
Summary:
Changelog: [internal] Fixes the output path for the fabric provider.
The old path wouldn't work when the pod installation path is not the same as the app dir.
Reviewed By: cortinico
Differential Revision: D32911493
fbshipit-source-id: 74a8481a2e8397024645d7daff2897e4b0b5454e
Summary: Changelog: [internal] We added generate-artifacts.js and generate-provider.js for codegen, and this diff adds that to the package.json so that it gets included.
Reviewed By: cortinico
Differential Revision: D32910033
fbshipit-source-id: 4982704fd3dac12b9cb64c4b3facb496abef4343
Summary:
This diff add custom prediction for fling distance support. This is needed for customize fling animator to calculate predicted fling distance, instead of using the overscroller that may not be used by the animator.
More context on this -- when fling happens, our code will first predict the final fling position `p`, apply the snapping logic to decide the expected snapping position `pSnapping` given `p`, scroll velocity and children layout, then trigger the overscroller (existing) or custom fling animator to finish the fling.
Currently, the prediction logic is done with overscroller, and custom fling animator has no control over how the predicted fling distance should be. Changes in this diff allow the animator to override `getExtrapolatedDistance` method and provide that information.
Changelog:
[Android][Added] - Add new API for custom fling animator to provide predicted travel distance for its fling animation.
Reviewed By: mdvacca
Differential Revision: D32571734
fbshipit-source-id: d34b969206f8b6cb5c68d2f50a18749bfebbc97e
Summary:
React-native Xcode build steps (such as "Build JS Bundle") rely on `find.node-sh` to find the correct node binary, using nvm if present. We do this because Xcode may run build steps in a fresh shell environment, presumably for repeatable builds.
This PR fixes `find-node.sh`, to respect any `.nvmrc` file that may be present in the build environment.
Today: `find-node.sh` will set the shell environment to the system node version, and ignores any `.nvmrc` the project may provide to pin node for repeatable builds. By ignoring `.nvmrc`, node versions may differ depending on system environment — between developer laptops, or between developer and CI environments. 😞
This problem has been been noticed before in https://github.com/facebook/react-native/issues/8887
### Should this fix happen upstream?
Unfortunately this nvm behavior [is intended](https://github.com/nvm-sh/nvm/issues/2053), for backwards compatibility
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Fixed] - find-node.sh now respects .nvmrc
Pull Request resolved: https://github.com/facebook/react-native/pull/32712
Test Plan:
Before:
```bash
# nvm isn't loaded
$ which nvm
# we're on default system node
$ which node && node --version
/usr/local/bin/node
v17.0.1
$ echo v16.13.0 > .nvmrc
$ source ./scripts/find-node.sh
# Expected: v16.13.0
$ node --version
v17.0.1
```
After:
```bash
# we're on default system node
$ which node && node --version
/usr/local/bin/node
v17.0.1
$ echo v16.13.0 > .nvmrc
$ source ./scripts/find-node.sh
# Expected: v16.13.0
$ node --version
v16.13.0
```
After (no .nvmrc, should preserve previous behavior):
```bash
# we're on default system node
$ which node && node --version
/usr/local/bin/node
v17.0.1
$ source ./scripts/find-node.sh
$ nvm ls|grep default
default -> v14.17.1
# Expected: v14.17.1
$ node --version
v14.17.1
```
Reviewed By: sota000
Differential Revision: D32889629
Pulled By: ShikaSD
fbshipit-source-id: 527384055e303a87bad43413fb66a7fd117d1a63
Summary:
Retrying D30015799 (https://github.com/facebook/react-native/commit/6e903b07fa8e8d9b78cae0e031bb8022f7a63195) with a fix where ScrollViewNativeComponent was missing the automaticallyAdjustKeyboardInsets prop.
----- Original Summary
Currently, ScrollViews provide the prop `keyboardDismissMode` which lets you choose `"interactive"`. However when the keyboard is shown, it will be rendered above the ScrollView, potentially blocking content.
With the `automaticallyAdjustKeyboardInsets` prop the ScrollView will automatically adjust it's `contentInset`, `scrollIndicatorInsets` and `contentOffset` (scroll Y) props to push the content up so nothing gets blocked.
* The animation curve and duration of the Keyboard is exactly matched.
* The absolute position of the ScrollView is respected, so if the Keyboard only overlaps 10 pixels of the ScrollView, it will only get inset by 10 pixels.
* By respecting the absolute position on screen, this automatically makes it fully compatible with phones with notches (custom safe areas)
* By using the keyboard frame, this also works for different sized keyboards and even `<InputAccessoryView>`s
* This also supports `maintainVisibleContentPosition` and `autoscrollToTopThreshold`.
* I also fixed an issue with the `maintainVisibleContentPosition` (`autoscrollToTopThreshold`) prop(s), so they behave more reliably when `contentInset`s are applied. (This makes automatically scrolling to new items fully compatible with `automaticallyAdjustKeyboardInsets`)
## Changelog
* [iOS] [Added] - ScrollView: `automaticallyAdjustKeyboardInsets` prop: Automatically animate `contentInset`, `scrollIndicatorInsets` and `contentOffset` (scroll Y) to avoid the Keyboard. (respecting absolute position on screen and safe-areas)
* [iOS] [Fixed] - ScrollView: Respect `contentInset` when animating new items with `autoscrollToTopThreshold`, make `automaticallyAdjustKeyboardInsets` work with `autoscrollToTopThreshold` (includes vertical, vertical-inverted, horizontal and horizontal-inverted ScrollViews)
Pull Request resolved: https://github.com/facebook/react-native/pull/31402
Test Plan:
<table>
<tr>
<th>Before</th>
<th>After</th>
</tr>
<tr>
<td>
https://user-images.githubusercontent.com/15199031/115708680-9700aa80-a370-11eb-8016-e75d81a92cd7.MP4
</td>
<td>
https://user-images.githubusercontent.com/15199031/115708699-9b2cc800-a370-11eb-976f-c4010cd96d55.MP4
</td>
</table>
### "Why not just use `<KeyboardAvoidingView>`?"
<table>
<tr>
<th>Before (with <code><KeyboardAvoidingView></code>)</th>
<th>After (with <code>automaticallyAdjustKeyboardInsets</code>)</th>
</tr>
<tr>
<td>
https://user-images.githubusercontent.com/15199031/115708749-abdd3e00-a370-11eb-8e09-a27ffaef12b8.MP4
</td>
<td>
https://user-images.githubusercontent.com/15199031/115708777-b3044c00-a370-11eb-9b7a-e040ccb3ef8c.MP4
</td>
</table>
> Also notice how the `<KeyboardAvoidingView>` does not match the animation curve of the Keyboard
### Usage
```jsx
export const ChatPage = ({
flatListProps,
textInputProps
}: Props): React.ReactElement => (
<>
<FlatList
{...flatListProps}
keyboardDismissMode="interactive"
automaticallyAdjustContentInsets={false}
contentInsetAdjustmentBehavior="never"
maintainVisibleContentPosition={{ minIndexForVisible: 0, autoscrollToTopThreshold: 100 }}
automaticallyAdjustKeyboardInsets={true}
/>
<InputAccessoryView backgroundColor={colors.white}>
<ChatInput {...textInputProps} />
</InputAccessoryView>
</>
);
```
## Related Issues
* Fixes https://github.com/facebook/react-native/issues/31394
* Fixes https://github.com/facebook/react-native/issues/13073
Reviewed By: yungsters
Differential Revision: D32578661
Pulled By: sota000
fbshipit-source-id: 45985e2844275fe96304eccfd1901907dc4f9279
Summary:
Changelog: [Internal] Adding an option to change the component name for react native codegen.
This will help some use cases where the target name and the actual component names are different.
Reviewed By: fkgozali
Differential Revision: D32852437
fbshipit-source-id: 054a62214cf8bcfea5662b8fba6582d9d7209f90
Summary:
This diff refactors method `predictFinalScrollPosition` in `ReactScrollView` and `ReactHorizontalScrollView` to the helper class. This will make future changes to the prediction logic easier.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D32571735
fbshipit-source-id: 7e7e21ac51f929a017cd43de094ed39478fe4032
Summary:
This diff fixes an edge case where scroll to the end of the list may trigger a bounce back effect.
This issue is a regression from D32487846 (https://github.com/facebook/react-native/commit/f70018b37532622f08f20b2c51cdbfca55d730ea) (See [this comment](https://www.internalfb.com/diff/D32487846 (https://github.com/facebook/react-native/commit/f70018b37532622f08f20b2c51cdbfca55d730ea)?dst_version_fbid=263960175698224&transaction_fbid=566201141113715)) that zero velocity fling at the end of the scroll view makes the next fling animator use previous post animation position. This is due to cached `postAnimationValue` is applied mistakenly.
- Pass velocity instead of velocity sign to the helper class
- Update helper class logic to decide if we need to use post animated value from last fling animation
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D32566010
fbshipit-source-id: 1c61659030151f8f2c7648ca901b8b4158835538
Summary:
This diff fixes an edge case where fling and snap failed to find the correct target position when children views not fill up all the scrollable space. In this case, the target position would be calculated as the end of the scrollable space, which case the snap logic to go to the end of the scrollable area, instead of stop at the expected snapping position.
Changelog:
[Android][Fixed] - Fix fling and snap with recycler viewgroup where fling to the end of scrollable distance when it goes over current rendered children views.
Reviewed By: mdvacca
Differential Revision: D32565459
fbshipit-source-id: 319ef6e2d4e1c4deb9e45ed02c1bff7d807575c3
Summary: Changelog: [Internal] Add a `isTaggedVersion` function to filter out commits from release automation.
Reviewed By: sota000
Differential Revision: D32842035
fbshipit-source-id: 14bb262a1d2a96ffda87c759a3202c4f9a356141
Summary:
Bump deprecated-react-native-prop-types dependency to ^2.3.0. This version contains a .windows.js fork of some deprecated props. Current version has missing information for Windows, breaking CI for react-native-windows repository.
## Changelog
[General] [Changed] - Upgrade deprecated-react-native-prop-types dependency
Pull Request resolved: https://github.com/facebook/react-native/pull/32700
Reviewed By: lyahdav, rozele
Differential Revision: D32816801
Pulled By: yungsters
fbshipit-source-id: f6a8507637075b1a936d91c264bbd8a462505f48
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32698
Changelog: [Internal] - Renaming the eslint-plugin-codegen to eslint-plugin-specs as a better descriptor for this package. Part of the plan is to publish as a public npm package
Reviewed By: RSNara
Differential Revision: D32777702
fbshipit-source-id: 7776c481871031dba1280d87fb76b777ecc23339
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32693
Changelog: [Internal] this diff adds dependecies to the buck files so that an internal app that referes RNtester will work as intended.
Reviewed By: cortinico
Differential Revision: D32778338
fbshipit-source-id: d4703903c2227283fe9c70f02bb7da420d936fbb
Summary:
changelog: [internal]
Background executor has been shipped on both platforms for a long time.
I've kept the flag around because I wanted to run tests and compare Concurrent Mode vs Background Executor. The intention was to see if we can get rid of Background Executor to simplify the threading model.
Since then, React team has moved away from Concurrent Mode towards more gradual rollout of concurrent rendering and it no longer makes sense to do this comparison. Right now, we don't have a concern with concurrent rendering and Background Executor. If we ever want to run the an experiment, this gating will need to be added again.
Reviewed By: javache
Differential Revision: D32674798
fbshipit-source-id: a1e51c9c5b8e48efa4cb0f25379d58e7eb80ccd9
Summary: Changelog: [Internal] Adding an option in RN Tester to enable the new codegen discovery option where it uses generate-artifacts.js to codegen native files. It also updates generate-artifacts.js to support the case where react-native is not within node_modules. It also updates the option name for rn-demo-app.
Reviewed By: cortinico
Differential Revision: D32777912
fbshipit-source-id: f2b76fa61573e3d4507a9f16f8243ac7ca006900
Summary:
I've noticed that the `performance.now()` implementations differ on iOS and Android.
iOS:
```objc
PerformanceNow iosPerformanceNowBinder = []() {
// CACurrentMediaTime() returns the current absolute time, in seconds
return CACurrentMediaTime() * 1000;
};
```
Android:
```c++
double reactAndroidNativePerformanceNowHook() {
auto time = std::chrono::steady_clock::now();
auto duration = std::chrono::duration_cast<std::chrono::nanoseconds>(
time.time_since_epoch())
.count();
constexpr double NANOSECONDS_IN_MILLISECOND = 1000000.0;
return duration / NANOSECONDS_IN_MILLISECOND;
}
```
For consistency, I thought why not just use the same implementation on both iOS and Android.
It also seems more logical to use Chrono on iOS, since it has nanosecond precision and we just multiply it to milliseconds, whereas `CACurrentMediaTime` multiplies to seconds, and we divide it down to milliseconds again.
## Changelog
(internal change only)
Pull Request resolved: https://github.com/facebook/react-native/pull/32695
Test Plan:
Run on iOS and Android:
```ts
const now = global.performance.now()
console.log(`${Platform.OS}: ${now}`)
```
Reviewed By: feedthejim
Differential Revision: D32793838
Pulled By: ShikaSD
fbshipit-source-id: e7967780be95956a75a3a3757311af0077976d23
Summary:
Changelog: [Internal] Remove warning about creating a pull request to a release branch
We want to support this use case as we want pick requesters to land the cherry-picks themselves and rely on CircleCI automation to test
Reviewed By: cortinico
Differential Revision: D32780819
fbshipit-source-id: 882625a016653dbf480da33fd499d3718b2b5524
Summary:
changelog: [internal]
UIManager::animationTick is thread safe. Let's make it obvious by marking the method const.
Reviewed By: javache
Differential Revision: D32669102
fbshipit-source-id: 49e35d0f0a5c5d1b03baa1cbf9cdece082909e85
Summary:
The current implementation of the prelive composer is setting the RN override preference to nil when live shopping ends. However, if the user had a previously set appearance override, this would clear it out.
To resolve this, I cache the user's override preference before we override it, and restore it when live shopping ends.
Additionally, I'm adding a missing callback to restore the override pref when live shopping is dismissed, but not cancelled.
Changelog:
[ReactiveNative][Appearance] - Add function to retrieve overridden RN appearance
Differential Revision: D32564739
fbshipit-source-id: d0b4e06d2bbadad68f172d951609cba3e4587e5d
Summary:
The current implementation of `AccessibilityInfo.announceForAccessibility` will immediately interrupt any existing in progress speech with the announcement. Sometimes this is desirable behaviour, but often you will want to wait until existing speech is finished before reading the new announcement. This change gives us that option.
My personal use case for this feature is a custom text input. When typing on iOS with voiceover enabled, each character is read out after being selected. I wanted to add some additional information after each character to help with the context of what has changed in the input, but I didn't want to override the reading of the character itself.
This feature is supported natively on iOS by constructing an `NSAttributedString` with the property [`accessibilitySpeechQueueAnnouncement`](https://developer.apple.com/documentation/foundation/nsattributedstring/key/2865770-accessibilityspeechqueueannounce), so this change just adds an extra parameter to `AccessibilityInfo.announceForAccessibility` which controls the value of that property on the native side. Adding this as an extra optional parameter with false as the default ensures that existing uses of the function won't be affected.
Unfortunately, this feature doesn't appear to be supported on Android, so the new second property will be iOS only.
## Changelog
[iOS] [Added] - add new argument to announceForAccessibility to allow queueing on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/32637
Test Plan:
I've updated the `announceForAccessibility` section in RNTester with multiple buttons to demonstrate the difference between `queue: false` (default) and `queue: true` and show they work as intended.
Here's the expectation for each button:
- "Announce for Accessibility Immediately": on press, should start reading the button label, then be interrupted by the announcement
- "Announce for Accessibility Queued": on press, should read the button label then read the announcement afterwards
- "Announce for Accessibility Queue Multiple": on press, should read the button label, then read three announcements sequentially, no interruptions
You can see the realisation of those expectations in the following video recorded on an iPhone 12 running iOS 15.0.2:
https://user-images.githubusercontent.com/14826539/142770536-d57bfd69-eba5-444d-9c89-4bf4851ea062.mov
I've also tested the same way on an iPhone 8 running iOS 13.4 and it works exactly the same.
Reviewed By: yungsters
Differential Revision: D32637989
Pulled By: philIip
fbshipit-source-id: 3e90add523f11eb0eb34ea623211249263f257e2
Summary:
I've been seeing a couple crashes related to missing hermes-executor-common.so, seems to happen on specific android versions, but can't repro. I investigated this so file more and noticed it is incorrectly linked as a static library here https://github.com/facebook/react-native/blob/b8f415eb6cdc0e0e7a7413b6f9defdcee304d9e8/ReactAndroid/src/main/java/com/facebook/hermes/reactexecutor/Android.mk#L20. There doesn't seem to be any reason for this to be a shared lib so I changed it to be compiled as a static lib.
## Changelog
[Android] [Fixed] - Make hermes-executor-common a static lib
Pull Request resolved: https://github.com/facebook/react-native/pull/32683
Test Plan:
- Verify there is no more hermes-executor-common-{release,debug}.so
- Test locally in an app to make sure it build and run properly.
- Verify that the crash happening on play store pre-launch report doesn't happen anymore.
Reviewed By: ShikaSD
Differential Revision: D32754968
Pulled By: cortinico
fbshipit-source-id: cb57e2d81edb4cbdb1f003dab45c53e594a5a62a
Summary:
Changelog: [Internal] Revert --sourcemap-output argument
Reverting on main from discussion from the 67 release:
https://github.com/reactwg/react-native-releases/discussions/1#discussioncomment-1705266
Original commit changeset: 0c2d98746b36
Reviewed By: GijsWeterings
Differential Revision: D32734743
fbshipit-source-id: cc3130581d01bdcdc9f5d483161ae9506fdbf7b8
Summary:
changelog: [internal]
Attempt at fixing a crash in `Scheduler::uiManagerDidCloneShadowNode` by setting delegate to nullptr explicitly.
I don't think this will make a difference because `scheduler_` is released at the end of `dealloc` but it is worth a shot. Maybe some complex interaction between Obj-C and C++ comes into play here.
In this diff I also removed `_animationDriver = nullptr` because dealloc will do that automatically.
Reviewed By: philIip
Differential Revision: D32720901
fbshipit-source-id: 227ced2331384c47e8d15a323ee8a621bbb3d179
Summary:
react-native-windows currently needs to maintain a fork of TextNativeComponent to wire through a native-only prop for `isPressable`.
The reason we do this on Windows is that we implement an optimization so we only attempt to hit test a virtual Text node if it is actually pressable, leading to significant perf improvement for pointer events (e.g., onMouseEnter / onMouseLeave) on Text.
Changelog:
[General][Added] - Native-only prop to optimize text hit testing on some RN platforms
Reviewed By: JoshuaGross
Differential Revision: D32564637
fbshipit-source-id: bf47c68d94a930d2c620cb3b1584355c5e412bd4
Summary:
Changelog: [Internal] Update CircleCI to auto-deploy release branch on push
This work is part of an effort to automate the release process by using a push to a release branch as a trigger to prepare, package and deploy react-native to npm from CircleCI
The following diagram describes the context (what kind of releases we do, relevant scripts and what they do), the pre-existing process for the different types of release and how I've modified the process.
{F683387103}
This diff updates the relevant CircleCI workflows
Reviewed By: sota000
Differential Revision: D32702420
fbshipit-source-id: e20cdeb53eb4a8ce7e54e083e3e14bd89e11b789
Summary:
Changelog: [Internal] - Extract logic from bump-oss-version specific to prod releases
This work is part of an effort to automate the release process by using a push to a release branch as a trigger to prepare, package and deploy react-native to npm from CircleCI
The following diagram describes the context (what kind of releases we do, relevant scripts and what they do), the pre-existing process for the different types of release and how I've modified the process.
{F683387103}
This diff creates the `prepare-package-for-release` script referenced by extracting it out of `bump-oss-version` and leveraging `set-rn-version`. It adds some helper functions to `version-utils` with tests
Reviewed By: sota000
Differential Revision: D32556610
fbshipit-source-id: eb4ddc787498744156f985ab6d205c5d160e279b
Summary:
Changelog: [Internal] Copy over universal (across dry-run, nightly, release) work in `bump-oss-version` script
This work is part of an effort to automate the release process by using a push to a release branch as a trigger to prepare, package and deploy react-native to npm from CircleCI
The following diagram describes the context (what kind of releases we do, relevant scripts and what they do), the pre-existing process for the different types of release and how I've modified the process.
{F683387103}
This diff creates the `set-rn-version` script referenced by extracting it out of `bump-oss-version`
Reviewed By: sota000
Differential Revision: D32556608
fbshipit-source-id: 6c2868c01ddd930375279a5105bcd0d447f65734
Summary:
Changelog: [Internal] - Add getNextVersionFromTags to determine next release version off a release branch
In more detail - this work is part of an effort to automate the release process by using a push to a release branch as a trigger to prepare, package and deploy react-native to npm from CircleCI
This function is later used in `prepare-package-for-release` script in D32556610 to bump the version
Reviewed By: cortinico, ShikaSD
Differential Revision: D32556609
fbshipit-source-id: 7d93ead0b34318a58ffeb876715fbd34d6041f4e
Summary:
The helper class for ScrollView should not need to detect the scroll direction. If it has to do so, that means the corresponding logic should live in the `ReactScrollView` or `ReactHorizontalScrollView` respectively.
This diff is to remove the scroll direction detection logic from the scroll view helper. Long term we should keep it this way as the shared code got moved to the helper class from the scroll view classes.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D32514429
fbshipit-source-id: 2165f2eba90cc25d14834c39148fe8ce8805bea6
Summary:
This diff fixes two edge case (similar to a race condition) that caused unexpected behaviors.
**Problem one**
{F680816408}
The previous fling animation is not canceled when user starts to scroll or drag. This is causing both the animation and scroll are setting the scroll position. Depends on the animation path and scroll speed, there may be cases where the [velocity calculation](https://fburl.com/code/010lsu72) ends up getting reversed values. See P467905091 as an example where you can see `mXFlingVelocity` goes back and forth from positive to negative.
It's hard to see if the wrong values are in the middle, but if that happens in the end of user gesture, the velocity for the next fling would be wrong. It shows a "bounce back" effect, and can be triggered when user makes small quick joystick scrolls in one direction.
**Problem two**
{F680821494}
There is a gap between animator's `onAnimationEnd` lifecycle method [finished](https://fburl.com/code/6baq04ne) and the `Animator#isRunning` API to return false. This is causing issues for `getPostAnimationScrollX` where we [decide to return](https://fburl.com/code/hzzugvch) the animated final value or the scroll value. User may see the `-1` value got used for the next fling start value, and the whole scroll view goes back to the beginning of scroll view and starts to fling.
This happens when the previous fling animation finishes and the animated final value is set to -1, but at the same time the next fling starts before `isRunning` returns false for the previous animation.
**Solution**
The problems are fixed by
- Do not reset animated final value to -1 in `onAnimationEnd` method
- Add `mIsFinished` states and use it to track animation finish signal, instead of using `isRunning` API
- Update logic where we decide to return the correct value for the next animation starts point. We will return previous animated final value when the animation got canceled, and user is going towards that value from the current scroll value.
Changelog:
[Android][Fixed] - Fixed edge case for quick small scrolls causing unexpected scrolling behaviors.
Reviewed By: javache
Differential Revision: D32487846
fbshipit-source-id: f1b0647656e021390e3a05de5846251a4a2647ff
Summary:
If `value` is of type `float`, it will still fall through to the `react_native_assert` below, exploding. The `map` type is handled correctly.
Changelog: [Internal][Fixed] Fix fromRawValue(EdgeInsets) from single float case falling through to float array and exploding
Reviewed By: javache
Differential Revision: D32648848
fbshipit-source-id: e70cddd291a8f52d6ee3de5fef11b0bb7aee92cd
Summary:
The `__apply_Xcode_12_5_M1_post_install_workaround` script changes the `IPHONEOS_DEPLOYMENT_TARGET` to `11.0` for all pods. This causes problems if the pods were targetting `12.0` or higher. Many expo modules are targetting `12.0`.
I fixed this issue by checking the existing version and only bumping the target if it is lower than `11.0`.
See also: this discussion post by mikehardy https://github.com/reactwg/react-native-releases/discussions/1#discussioncomment-1619523
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Fixed] - __apply_Xcode_12_5_M1_post_install_workaround causing pods targetting iOS 12 and above to fail
Pull Request resolved: https://github.com/facebook/react-native/pull/32633
Test Plan:
### Test (failing before this patch, passing after this patch)
1. pick an iOS Pod that has a minimum deployment target of iOS 12 or higher, I chose the Braintree package
2. `npx react-native init myrnapp`
3. Open `ios/Podfile` and add the pod as a dependency: `pod 'Braintree', '~> 5'` (and upgrade the Podfile target to 12 (`platform :ios, '12.0'`))
4. Compile the app.
Before applying this patch: ❌ Build fails because Braintree uses iOS 12 features and was downgraded to target 11.0
After applying this patch: ✅ Build succeeds
Reviewed By: fkgozali
Differential Revision: D32638171
Pulled By: philIip
fbshipit-source-id: 0487647583057f3cfefcf515820855c7d4b16d31
Summary:
The `add-version-label-issue` CI is failing if the version label is not found.
That is happening for previous versions of RN where the Labels are missing.
Changelog:
[Internal] [Changed] - Do not report a CI failure if add-version-label-issue is red
Reviewed By: sammy-SC
Differential Revision: D32723953
fbshipit-source-id: 878d2632b3a78311a01363b8f8a9181ae543a253
Summary:
As the title says. It's now safe to enable Fabric by default inside RNTester.
Changelog:
[Internal] [Changed] - Enable Fabric by default inside RN-Tester
Reviewed By: fkgozali
Differential Revision: D32723540
fbshipit-source-id: dab786694ba9ceb238570608713b5243a730aada
Summary:
Preallocation can take 10-20% of time when creating new nodes. (according to systrace measurements). At the moment, we are executing all preallocation calls in JS thread, potentially slowing down the progress there. Moving them to bg thread is a simple micro-optimization that ensures we return the node to JS as soon as possible.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D32677843
fbshipit-source-id: 3df47ae9aa365a8db720d71e2423c87659e9128c
Summary:
Removes extra .so files by merging built-in components into libfabricjni.so
These components shouldn't be referenced in outside modules, so merging them is trivial atm.
Changelog:
[Internal][Android] - Compile native components into static libraries
Reviewed By: cortinico
Differential Revision: D32677572
fbshipit-source-id: fc1a6c5a2832ee49e438c30856562f85677514ea
Samuel Susla
Andrei Shikov
Sota Ogo
Xin Chen
Ramanpreet Nara
Ian Grayson
Marc Rousavy
Juan Tejada
Luna Wei
Chiara Mooney
Liron Yahdav
zpd106
Yuan Dai
Tom Spencer
Marc Rousavy
David Ashinsky
Peter Carpenter
Janic Duplessis
Eric Rozell
Felipe Perez
Simon Farshid
Nicola Corti
