Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RN v0.63.2] Fix Xcode bundler in staging and release #29477

Closed
wants to merge 1 commit into from

Conversation

makarkotlov
Copy link

@makarkotlov makarkotlov commented Jul 23, 2020

Revert "feat: improve monorepo support by removing redundant PROJECT_ROOT (#28354)"

This reverts commit a8e8502.

Summary

This commit a8e8502 somehow broke the bundler when making a staging or release build in Xcode that results in unresolved files and main.jsbundle nonexistance issue. I figured this out by replacing react-native-xcode.sh from RN v0.63.2 by the one from v0.62.2 where everything works just fine and then reverting the changes line by line. It seems like this pr will fix similar issues stated here https://stackoverflow.com/questions/62806319/main-jsbundle-does-not-exist-this-must-be-a-bug-with-main-jsbundle-issue-afte/62829256#62829256 and here #29205

Changelog

[iOS] [Fixed] - fix "main.jsbundle does not exist" issue

Test Plan

With react-native-xcode.sh from RN v0.63.2
image

With my changes
image

@facebook-github-bot
Copy link
Contributor

Hi @makarkotlov!

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file.

In order for us to review and merge your code, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

If you have received this in error or have any questions, please contact us at cla@fb.com. Thanks!

@react-native-bot react-native-bot added Bug Platform: iOS iOS applications. labels Jul 23, 2020
@analysis-bot
Copy link

Platform Engine Arch Size (bytes) Diff
android hermes arm64-v8a 6,764,925 0
android hermes armeabi-v7a 6,432,589 0
android hermes x86 7,152,759 0
android hermes x86_64 7,042,662 0
android jsc arm64-v8a 8,936,186 0
android jsc armeabi-v7a 8,596,224 0
android jsc x86 8,767,157 0
android jsc x86_64 9,342,688 0

Base commit: c9f869f

@analysis-bot
Copy link

Platform Engine Arch Size (bytes) Diff
ios - universal n/a --

Base commit: c9f869f

@facebook-github-bot facebook-github-bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Jul 23, 2020
@facebook-github-bot
Copy link
Contributor

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

@sandfox
Copy link

sandfox commented Jul 24, 2020

We experienced something similar after upgrading from 62 -> 63.
For context, we have separate index.android.js and index.ios.js entry files in the root of our project.

What we discovered was when building using 62 the CWD would be the actual root of the project. When using 63 the CWD would be the ios subfolder. This meant that when using 63 the elif [[ -s "index.ios.js" ]]; then check would be executed in the ios subfolder, not find anything, default the entry file to being index.js and the metro bundler would fail because it couldn't find the entry file when checked the project root. I'm pretty sure thats whats happening here for you. We "fixed" this by specifying the ENTRY_FILE=index.ios.js env var in the xcode "Bundle React Native code and images" script.

That all said, I'm not sure if this breaking behaviour was intended with the original patch. I also don't know if this problem is also solvable by setting the PROJECT_ROOT env var in the "Bundle React Native code and images" script, and/or if that was the intended way to handle it.

@makarkotlov
Copy link
Author

makarkotlov commented Jul 24, 2020

@sandfox thanks for shedding more light on the problem! I have only one index.js in the root and I think the change in react-native-xcode.sh in 63 wasn't meant to be a breaking change so maybe it should be reverted. It would be even better if @grabbou can improve his commit making it really non-breaking and there will be no need in reverting it

@todorone
Copy link

These are also probably related issues - #29351 and #29356
It would be great to have at least docs on how to fix issue with 3rd party tools that were dependent on previous behaviour like Sentry, babel-plugin-module-resolver...

@schonfeld
Copy link

FWIW, adding PROJECT_ROOT to the xcode bundler script build phase fixed the issue for me. Updated script looks like this:

export PROJECT_ROOT=../
export NODE_BINARY=node
../node_modules/react-native/scripts/react-native-xcode.sh

@oleksandr-dziuban
Copy link

oleksandr-dziuban commented Aug 6, 2020

Hello, when this PR can be merged? It's really critical bug fix for all react-native projects

@ozgursoy
Copy link

ozgursoy commented Aug 12, 2020

@makarkotlov Thank you so much, please merge this pull request.

@oleksandr-dziuban
Copy link

Yes, I can confirm, this PR fixes the issue!

I have assembled release iOS build locally with this change and it works!

@safaiyeh safaiyeh requested a review from grabbou August 16, 2020 00:11
@safaiyeh
Copy link
Contributor

Spoke with @grabbou he will be taking a look

@oleksandr-dziuban
Copy link

Spoke with @grabbou he will be taking a look

Thanks a lot

@gaodeng
Copy link
Contributor

gaodeng commented Aug 20, 2020

any news?

@stigi
Copy link
Contributor

stigi commented Aug 21, 2020

We ran into the same issue today, upgrading from 0.62.2 to 0.63.2. Here are some notes from our investigation.

We got the main.jsbundle not found issue, which was caused by this internal error:

error SyntaxError: [redacted]/ios/node_modules/react-native/index.js: Unexpected token, expected "{" (13:7)

  11 | 'use strict';
  12 |
> 13 | import typeof AccessibilityInfo from './Libraries/Components/AccessibilityInfo/AccessibilityInfo';
...

The ios/node_modules part looked fishy, so I tried running node node_modules/react-native/cli.js bundle ... in both, the ios and the project root folder. It succeeded in the project root, but failed with the same message in the ios folder.

I had a hunch that this might be caused by a change to react-native-xcode.sh so I looked at the history, and sure enough found #28354

I believe a better fix than reverting the entire PR would be to forward fix it by setting PROJECT_ROOT=${PROJECT_ROOT:-$PWD/..}. $PWD will be set to the ios folder when run from Xcode. The project root is one level up.
I left a comment on the PR but decided to cross reference it from this PR.

UPDATE: It's not just PROJECT_ROOT that's broken, but also REACT_NATIVE_DIR. I didn't notice, because I was doing my tests by directly calling node clj.js. A workaround of setting PROJECT_ROOT wasn't enough in our case.

So my 👍 for proceeding with the revert, suggested in this PR.

@oleksandr-dziuban
Copy link

We ran into the same issue today, upgrading from 0.62.2 to 0.63.2. Here are some notes from our investigation.

We got the main.jsbundle not found issue, which was caused by this internal error:

error SyntaxError: [redacted]/ios/node_modules/react-native/index.js: Unexpected token, expected "{" (13:7)

  11 | 'use strict';
  12 |
> 13 | import typeof AccessibilityInfo from './Libraries/Components/AccessibilityInfo/AccessibilityInfo';
...

The ios/node_modules part looked fishy, so I tried running node node_modules/react-native/cli.js bundle ... in both, the ios and the project root folder. It succeeded in the project root, but failed with the same message in the ios folder.

I had a hunch that this might be caused by a change to react-native-xcode.sh so I looked at the history, and sure enough found #28354

I believe a better fix than reverting the entire PR would be to forward fix it by setting PROJECT_ROOT=${PROJECT_ROOT:-$PWD/..}. $PWD will be set to the ios folder when run from Xcode. The project root is one level up.
I left a comment on the PR but decided to cross reference it from this PR.

UPDATE: It's not just PROJECT_ROOT that's broken, but also REACT_NATIVE_DIR. I didn't notice, because I was doing my tests by directly calling node clj.js. A workaround of setting PROJECT_ROOT wasn't enough in our case.

So my 👍 for proceeding with the revert, suggested in this PR.

Yep, PROJECT_ROOT only doesn't work, better to merge this revert PR. Thanks for the research!

@WGoinz
Copy link

WGoinz commented Aug 24, 2020

Any ETA on this being merged?

@a-eid
Copy link

a-eid commented Sep 10, 2020

this error happens when applying any babel plugins, when removed it works fine.
I hope this gets fixed soon, please note that this PR didn't help fix the issue.

@srfaytkn
Copy link

+1

Copy link
Contributor

@facebook-github-bot facebook-github-bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hramos has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

@hramos
Copy link
Contributor

hramos commented Sep 21, 2020

Ideally, we'd fix the issue that affects staging and release builds. In order to unblock folks, however, I'm OK with moving forward with this revert.

If you are interested in getting this change back into a release, please refer back to this thread and make sure the issues around staging and release are addressed. If you think this type of issue can be caught earlier by CI, I would also like to see that type of contribution.

@react-native-bot
Copy link
Collaborator

This pull request was successfully merged by Makar Kotlov in 83777cb.

When will my fix make it into a release? | Upcoming Releases

@react-native-bot react-native-bot added the Merged This PR has been merged. label Sep 22, 2020
@RnbWd
Copy link

RnbWd commented Sep 24, 2020

I'm running into this after upgrading from 62.2 - 63.2, hopefully this PR fixes it

@ajp8164
Copy link

ajp8164 commented Sep 24, 2020

I commented on this issue at react-native-community/cli#1271.

I think the original intent of the change is good, the implementation was broken though. Simply moving cd $PROJECT_ROOT to be immediately before the call to cli.js solves the problem. Changing the directory earlier clobbers REACT_NATIVE_DIR because it depends on BASH_SOURCE.

@stanica
Copy link

stanica commented Sep 28, 2020

I fixed this by adding a build script in package.json:

"build:ios": "react-native bundle --entry-file='index.js' --bundle-output='./ios/main.jsbundle' --dev=false --platform='ios'"

that I run using:

npm run build:ios

kelset pushed a commit that referenced this pull request Sep 29, 2020
Summary:
Revert "feat: improve monorepo support by removing redundant PROJECT_ROOT (#28354)"

This reverts commit a8e8502.

This commit a8e8502 somehow broke the bundler when making a staging or release build in Xcode that results in unresolved files and main.jsbundle nonexistance issue. I figured this out by replacing react-native-xcode.sh from RN v0.63.2 by the one from v0.62.2 where everything works just fine and then reverting the changes line by line. It seems like this pr will fix similar issues stated here https://stackoverflow.com/questions/62806319/main-jsbundle-does-not-exist-this-must-be-a-bug-with-main-jsbundle-issue-afte/62829256#62829256 and here #29205

## Changelog

[iOS] [Fixed] - fix "main.jsbundle does not exist" issue

Pull Request resolved: #29477

Test Plan:
With react-native-xcode.sh from RN v0.63.2
![image](https://user-images.githubusercontent.com/32848434/88342113-7ce55d80-cd47-11ea-9dab-bf41ec6d6ab5.png)

With my changes
![image](https://user-images.githubusercontent.com/32848434/88342376-f0876a80-cd47-11ea-9c08-96b892784da1.png)

Reviewed By: sammy-SC

Differential Revision: D23817847

Pulled By: hramos

fbshipit-source-id: 4b729c1231d30e89073b2520aeadee944c84421c
@pacchio
Copy link

pacchio commented Oct 4, 2020

Upgrade to v0.63.3. It's now fixed

Changelog of v0.63.3 :

Fix "main.jsbundle does not exist" issue (83777cb)

@oaosman84
Copy link

Thanks to everyone who fixed this. If anyone stumbles on this, for us it had manifested itself in a different error than main.jsbundle does not exist, instead we were seeing Unable to resolve module ... errors on absolute imports, even though our babel.config.js had the proper config. It was broken on 0.63.2, but worked on RN 0.61.5 and again after jumping to 0.63.3.

@iansamz
Copy link

iansamz commented Oct 19, 2020

I fixed this by adding a build script in package.json:

"build:ios": "react-native bundle --entry-file='index.js' --bundle-output='./ios/main.jsbundle' --dev=false --platform='ios'"

that I run using:

npm run build:ios

@stanica answer worked for me cause I was already on v0.63.3

@mununki
Copy link

mununki commented Oct 22, 2020

@stanica answer worked for me. Thanks!

grabbou pushed a commit to callstack/react-native that referenced this pull request Oct 23, 2020
Summary:
Revert "feat: improve monorepo support by removing redundant PROJECT_ROOT (facebook#28354)"

This reverts commit a8e8502.

This commit a8e8502 somehow broke the bundler when making a staging or release build in Xcode that results in unresolved files and main.jsbundle nonexistance issue. I figured this out by replacing react-native-xcode.sh from RN v0.63.2 by the one from v0.62.2 where everything works just fine and then reverting the changes line by line. It seems like this pr will fix similar issues stated here https://stackoverflow.com/questions/62806319/main-jsbundle-does-not-exist-this-must-be-a-bug-with-main-jsbundle-issue-afte/62829256#62829256 and here facebook#29205

## Changelog

[iOS] [Fixed] - fix "main.jsbundle does not exist" issue

Pull Request resolved: facebook#29477

Test Plan:
With react-native-xcode.sh from RN v0.63.2
![image](https://user-images.githubusercontent.com/32848434/88342113-7ce55d80-cd47-11ea-9dab-bf41ec6d6ab5.png)

With my changes
![image](https://user-images.githubusercontent.com/32848434/88342376-f0876a80-cd47-11ea-9c08-96b892784da1.png)

Reviewed By: sammy-SC

Differential Revision: D23817847

Pulled By: hramos

fbshipit-source-id: 4b729c1231d30e89073b2520aeadee944c84421c
@luk3skyw4lker
Copy link

I'm having this problem in 0.63.4, how is this back after one version it was fixed? My development build works fine, but the production one breaks with this error.

HeyImChris pushed a commit to microsoft/react-native-macos that referenced this pull request Sep 28, 2021
* Fix initial padding value for TextInput

Summary:
Changelog: [internal]

# Problem

Default padding for TextEdit is top: 26, bottom: 29, left: 10, right: 10 however the default values for LayoutMetrics.contentInsets is {0, 0, 0, 0}.

If you try to construct TextEdit with padding 0, Fabric will drop padding update because padding is already 0, 0, 0, 0.

# Fix
To fix this, I added a special case to `Binding::createUpdatePaddingMountItem`, if the mutation is insert, proceed with updating padding.

Reviewed By: JoshuaGross

Differential Revision: D23731498

fbshipit-source-id: 294ab053e562c05aadf6e743fb6bf12285d50307

* Fabric: Simplifying ShadowTreeRevision implementation

Summary:
The implementation of this class is too complex for the purpose it serves. Making it simpler will make the code simpler and faster.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: sammy-SC

Differential Revision: D23725688

fbshipit-source-id: 5e1ecddb0dd3c4c4f94786e2ba0af9b67e7426ce

* Fabric: Using ShadowTreeRevision inside ShadowTree to store current commited tree

Summary:
Instead of storing tree separate instance variables, we now store a single object that contains them. We will need it to be able to postpone the mounting stage (we save all info we need for mounting inside the new instance variable).

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: sammy-SC

Differential Revision: D23725690

fbshipit-source-id: 09dd4a0912c6f5b34d805636b62f73ca12287329

* Fabric: Introducing `ShadowTree::getCurrentRevision()`

Summary:
Previously, to get a current root shadow node for a shadow tree, we called `tryCommit` method and stole a pointer from this. That was not a very straightforward method to get things done, and most importantly we need to do this to change the shape of the ShadowTreeCommitTransaction signature (remove a shared pointer from the callback) to make it simpler, faster and allow future improvements (see the next diff).

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: JoshuaGross, sammy-SC

Differential Revision: D23725689

fbshipit-source-id: 51950b843a0e401828b6c6a38e5e2aaaf21ec166

* Fabric: Removing shared_ptr from ShadowTreeCommitTransaction's argument

Summary:
We don't need a shared_ptr here and without it the code will be faster and simpler.
This change is aligned with any clone-line callbacks we have in the Core which accepts a `const &` and return `shared_ptr<>`.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: JoshuaGross, sammy-SC

Differential Revision: D23725687

fbshipit-source-id: 1cd959f4273913175d342302e2f12752f0114768

* Fabric: Using `thread_local` keyword instead on own implementation in TransactionTelemetry

Summary:
Apparently, there is C++ keyword for this.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: sammy-SC

Differential Revision: D23754284

fbshipit-source-id: 5f9bbcc72d9c586173624869d614f12d2319fb7b

* Add an explicit NDK version to Android template (#29403)

Summary:
Added an explicit NDK version to the Android template. This allows tooling to detect which NDK version to install automatically.

## 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
-->

[Android] [Added] - Add an explicit NDK version to Android template

Pull Request resolved: https://github.com/facebook/react-native/pull/29403

Test Plan: Template builds as it should. NDK version gets installed with initial Android set up.

Reviewed By: passy

Differential Revision: D23752007

Pulled By: fkgozali

fbshipit-source-id: 31c33f275f94a4a62338a61e79b31c4b996969bf

* Fabric: Removing `RCTCGColorRefUnretainedFromSharedColor()`

Summary:
This diff removes `RCTCGColorRefUnretainedFromSharedColor` function because it's not compatible with future changes we plan to make.
Converting SharedColor to unretained CGColorRef is actually quite dangerous because... it's an unowned pointer.

Reviewed By: JoshuaGross

Differential Revision: D23753509

fbshipit-source-id: df030ade69b63cbb872d6bdbde51575eedc6a4a6

* Fabric: Using RCTUIColorFromSharedColor everywhere

Summary:
Even though we have wonderful helper functions converting SharedColor to UIColor and CGColorRef, in many places we still use some hardcoded things. This diff fixes that; it will be important for the next diff.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: JoshuaGross

Differential Revision: D23753508

fbshipit-source-id: 09d280b132266252753526c2735ab3e41b96c8d5

* Fabric: Color conversion functions now do not depend on internal implementations of SharedColor

Summary:
This diff changes the implementation of `RCTCreateCGColorRefFromSharedColor` and `RCTUIColorFromSharedColor` in such a way that they don't rely on the fact that SharedColor is actually a `shared_ptr<CGColorRef>`. Instead, the methods just extract color components from SharedColor and create UIColor and CGColorRef objects on demand.
This allows us to change the implementation of SharedColor without worrying much about the rest of the system, which will do in the next diff.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: JoshuaGross

Differential Revision: D23753510

fbshipit-source-id: 340127527888776ebd5d241ed60c7e5220564013

* Fabric: Using `optional<int>` instead of `CGColorRef` on iOS

Summary:
Finally, this diff changes the internal implementation of SharedColor to be `optional<int>`.

Initially, when we started working on the new renderer, it seemed like a good idea to allocated CGColor objects ahead of time and store them with Props. Now, this idea does not look so good, especially because:
* Having `SharedColor` as a `shared_ptr` is a quite big perf overhead for copying this thing. And the size of the object is not small.
* Having `SharedColor` as a `shared_ptr` creates huge interconnectedness among pieces of the core and rendering. E.g. improper releasing a pointer in some component view can cause a crash somewhere in the core (because both places might use the same shared `blackColor`.

On Android, we already use simple `int` as a representation of a color, and this works great. And this diff implements something very similar to Android, but a bit differently: here we use `optional<int>` instead of custom class with a single `int` field and some magic value that represents "empty value".

This approach should fix T75836417 because now we don't have allocation and deallocation when we simply assign color values.

If this solution works fine on iOS, I will do unify all implementations among all platforms.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: JoshuaGross

Differential Revision: D23753507

fbshipit-source-id: 42fd6cee6bf7b39c92c88536da06ba9e8cf4d4db

* Fabric: Using pre-cached UIColor objects for black, white, and clear colors

Summary:
This change maps the three most used colors (black, white, clear) to corresponding predefined values in UIColor. This should meaningfully reduce the overall amount of allocated UIColor/CGColor objects. In my non-scientific measures, it reduces the number of CGColor objects from ~1500 to ~1000. And... it no much at least in terms of kilobytes. However, I still think it's a good idea to implement this because I hope that can remove some work from memory allocation infra and maybe enable some optimizations that UIKit hopefully does for black and white colors. (I tend to believe that this optimization exists because UIKit even has a classes called UIDeviceWhiteColor and UICachedDeviceWhiteColor.)

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: JoshuaGross

Differential Revision: D23753506

fbshipit-source-id: 46e58dc7e6b0dcab3c83d29c7257c90ffbd95246

* Coalesce touchMove events

Summary:
Changelog: [Internal]

To align more closely with Paper, Fabric should coalesce touchMove events.

on iOS it happens:
https://www.internalfb.com/intern/diffusion/FBS/browsefile/master/xplat/js/react-native-github/React/Base/RCTTouchEvent.m?lines=43

Reviewed By: JoshuaGross

Differential Revision: D23734212

fbshipit-source-id: a9d324a6481884905d7be6637fcafe4e71f2bd9f

* Fix LayoutAnimations assertion on `adjustDelayedMutationIndicesForMutation`

Summary:
`adjustDelayedMutationIndicesForMutation` asserts that the mutation is either Remove or Insert. At one callsite, we weren't checking the mutation type before calling `adjustDelayedMutationIndicesForMutation`.

Changelog: [Internal]

Reviewed By: shergin

Differential Revision: D23746617

fbshipit-source-id: 6046fec2eb4821094937b1b16f40347bbc55c20e

* Fix MountingCoordinator override mode

Summary:
In MountingCoordinator override mode (used in LayoutAnimations) we must set the start and end `diff` time when no real diff happens, otherwise we will hit an assert in telemetry later.

I also ensure that the TransactionNumber is incremented in that case.

Changelog: [Internal]

Reviewed By: shergin

Differential Revision: D23746684

fbshipit-source-id: b1fe3864e453fdba89d43cc827bd37434abf7a4d

* Fix MountingCoordinator RN_SHADOW_TREE_INTROSPECTION + LayoutAnimations

Summary:
Currently, MountingCoordinator's RN_SHADOW_TREE_INTROSPECTION code will crash often because it assumes there is always a "new" tree to compare the old tree to. In the LayoutAnimations context this is not always the case - in fact, the majority of the time, LayoutAnimations is producing mutations for animation without a "new" tree.

Just check that the tree exists before trying to print it.

Changelog: [Internal]

Reviewed By: shergin

Differential Revision: D23747289

fbshipit-source-id: a1ba22aeae32ed8915a53bc33cdc199e8ce5128a

* Fix compilation for LayoutAnimations debug mode

Summary:
iOS needs this function to be marked as static.

Changelog: [internal]

Reviewed By: shergin

Differential Revision: D23749613

fbshipit-source-id: a8c160646853450fc7d849448bdbb45e02beb964

* LayoutAnimations: at the end of every animation, issue an update mutation

Summary:
LayoutAnimations: at the end of every animation, issue an update mutation - this is so that the props data on the Mounting layer/StubViewTree layer is pointer-identical to the props data on the ShadowTree.

This unblocks iOS debug mode crashes.

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D23753606

fbshipit-source-id: 407e0c2746a65e6d3ee29c1cce891cd7c1013593

* Layout Events: throttle layout events sent to same node repeatedly

Summary:
Under Fabric only, we can enter an infinite layout loop where the emitted layout event oscillates between two height values that are off by a very small amount.

The cause is, in part, components that use layoutEvents to determine their dimensions: for example, using onLayout event "height" parameters to determine the height of a child. If the onLayout height changes rapidly, the child's height will change, causing another layout, ad infinitum.

This might seem like an extreme case but there are product use-cases where this is done in non-Fabric and layout stabilizes quickly. In Fabric, currently it may never stabilize.

Part of this is due to a longstanding issue that exists in Fabric and non-Fabric, that we cannot immediately fix: If in a single frame, C++ emits 100 layout events to ReactJS, ReactJS may only process 50 before committing the root. That will trigger more layout events, even though product code has only partially processed the layout events. At the next frame, the next 50 events will be processed which may again change the layout, emitting more events... etc. In most cases the tree will converge and layout values will stabilize, but in extreme cases in Fabric, it might not.

Part of this is because Fabric does not drop *stale* layout events. If 10 layout events are dispatched to the same node, it will process all 10 events in older. Non-Fabric does not have this behavior, so we're changing Fabric to drop stale events when they queue up.

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D23719494

fbshipit-source-id: e44a3b3e40585b59680299db3a4efdc63cdf0de8

* Copy all blocks generated by TurboModules

Summary:
The Apple documentation states: https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/Blocks/Articles/bxUsing.html#//apple_ref/doc/uid/TP40007502-CH5-SW1

> Typically, you shouldn’t need to copy (or retain) a block. You only need to make a copy when you expect the block to be used after destruction of the scope within which it was declared. Copying moves a block to the heap.

All blocks generated in the TurboModule infra, for callbacks and promise resolve/reject handlers, can be used after the destruction of the scope within which they were declared. Therefore, let's copy them in the hopes that they mitigate T75876134.

**Note:** We copy blocks before pushing them into the `retainedObjects` array in the legacy Infra as well. Context: D2559997 (https://github.com/facebook/react-native/commit/71da2917e577b7ec659083408cff7f9981d6600f), D5589246 (https://github.com/facebook/react-native/commit/2a6965df9063c795b3d3098c4db76e5f595ba44f)

Changelog: [Internal]

Reviewed By: fkgozali

Differential Revision: D23764329

fbshipit-source-id: e71360977bdff74dc570bd40f0139792860f811f

* Upgrade Hermes dependency to 0.7.0

Summary:
Use the latest published release of hermes-engine.
Changelog: [Android] [Changed] - Upgraded to Hermes 0.7.0
allow-large-files

Reviewed By: cpojer

Differential Revision: D23725129

fbshipit-source-id: 50938433147100e97699b717d77a687fbbfe892b

* Fabric: Enabling state auto-repeating for all state updates (gated)

Summary:
This enables a new state auto repeating mechanism built-in mechanism for all state updates which we already use for CK interop. This experiment is supposed to help with T74769670 and co.

This change is gated with MC.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: JoshuaGross

Differential Revision: D23762508

fbshipit-source-id: f535513c724ace9ede570177281324eb507329c5

* Stop accessing JVM in ~JavaTurboModule

Summary:
Inside JavaTurboModule, the native `CallInvoker` is used to schedule work on the NativeModules thread. So, in ~JavaTurboModule(), I scheduled some work on the NativeModules thread. This work holds a copy of the JNI global reference to the Java NativeModule object, and when it's executed, it resets this global reference to the Java NativeModule object. This should ensure that the we don't access the JVM in ~JavaTurboModule, which could crash the program.

I also removed the redundant `quitSynchronous()` in `~CatalystInstanceImpl()`, to prevent the NativeModules thread from being deleted before we delete the `jsi::Runtime`. This shouldn't cause an issue, because we delete the NativeModules thread when we call [ReactQueueConfigurationImpl.destroy()](https://fburl.com/codesearch/p7aurwn3).

Changelog: [Internal]

Reviewed By: ejanzer

Differential Revision: D23744777

fbshipit-source-id: a5c8d3f2ac4287dfef9a4b4404a04b335aa0963d

* Improve performance logger definition and type safety

Summary:
The way the performance logger is defined now is very unsafe regarding type safety, as all accesses to its properties is untyped (`any`) and it uses several `mixed` types in cases that could be more refined.

This migrates the creation of performance loggers to instances of a class to improve its type safety. If there's an impact in performance, it's expected to be positive.

Changelog:
[Internal][Changed] - Replaced object literals with class instances to create performance loggers

Reviewed By: lunaleaps

Differential Revision: D23758609

fbshipit-source-id: 0734742eb97d92a4a53f7b66a8ca45a2ae90946c

* Remove unused timespan descriptions from performance loggers

Summary:
The `description` parameter is never used so we can simplify the API.

Changelog:
[Internal][Changed] Removed `description` option from performance logger timespans

Reviewed By: lunaleaps

Differential Revision: D23758829

fbshipit-source-id: 10900f86effc3e1f54a408cf8f9fbc9b3b52f569

* Remove unnecessary addTimeAnnotation method from performance logger

Summary:
Changelog:
[Internal][Removed] Removed `addTimeAnnotation` method from performance loggers

Reviewed By: lunaleaps

Differential Revision: D23758816

fbshipit-source-id: 98e0abae25266f3dcc5953f25f20cde8e3dac190

* Remove update option from stopTimestamp method in performance loggers

Summary:
Changelog:
[Internal][Changed] Removed `update` option from `stopTimestamp` method in performance loggers

Reviewed By: lunaleaps

Differential Revision: D23759138

fbshipit-source-id: bb83b6f5ff2f640733c2e508779b3bc52800e4f6

* Propagate nativeID in createAnimatedComponent

Summary:
Changelog: [internal]

https://our.intern.facebook.com/intern/diffusion/FBS/browse/master/xplat/js/react-native-github/Libraries/Animated/createAnimatedComponent.js?commit=1b6ce6c3a69a&lines=82-112

`_isFabric` in `createAnimatedComponent` returns false for Fabric component, that's why nativeID was not being assigned and view got flattened.

To fix this, props.nativeID is propagated. SnackBar already has nativeID https://our.intern.facebook.com/intern/diffusion/FBS/browse/master/xplat/js/RKJSModules/Libraries/FDS/FDSLightweightFeedback/DEPRECATED_FDSSnackBar.js?commit=1b6ce6c3a69a&lines=277

Reviewed By: PeteTheHeat

Differential Revision: D23757304

fbshipit-source-id: 9e4b4599c95b8af8767793bc8cdce717a347a273

* Reintroduce experiment flag for Reparenting/Flattening Differ

Summary:
This flag was deleted in D23374948 (https://github.com/facebook/react-native/commit/6729a3e0bfc01119c8513dfcbb1f5fbe5fe81263), reintroduce it.

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D23771273

fbshipit-source-id: ae9595194bf14bc740d05b2ca6e7b5e22bdd566f

* Add cause to jsi::instrumentation::collectGarbage

Summary:
Continuing the adding of a "cause" field for logging to GCs.
This allows embedders of Hermes (such as React Native) to specify
the cause of a call to `collectGarbage`.

Notably, this allows Hermes to know when a GC is triggered by a memory warning.

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D23742099

fbshipit-source-id: 99453e632328c00045b92a72f789d41c898dc518

* Update Flipper (#29787)

Summary:
The current Flipper version included in new React Native is quite old, causing some bugs to be present which have long been solved, such as freezing the UI after inspecting it.
Fixes

This fixes https://github.com/facebook/react-native/issues/29492 /
https://github.com/facebook/flipper/issues/1399

## 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
-->

[general][changed] - Update Flipper to 0.54

Pull Request resolved: https://github.com/facebook/react-native/pull/29787

Test Plan:
Updated the RN 0.63.2 based test project https://github.com/mweststrate/flipper-issue-1399-repo with `use_flipper!('Flipper' => '0.54.0')` (in `ios/Podspec`) / `FLIPPER_VERSION=0.52.1` in `gradle.properties` in the test project https://github.com/mweststrate/flipper-issue-1399-repo and verified that everything builds and connects correctly, and that the bug is no longer present.

Tried to run RN-tester project in this repo. For iOS this succeeded, on Android I got a build error:

```
make: Leaving directory '/Users/mweststrate/Desktop/react-native/ReactAndroid/src/main/jni/react/jni'
make: Entering directory '/Users/mweststrate/Desktop/react-native/ReactAndroid/src/main/jni/react/jni'
fcntl(): Bad file descriptor
[armeabi-v7a] Compile++ thumb: folly_json <= FileUtil.cpp
/Users/mweststrate/Desktop/react-native/ReactAndroid/build/third-party-ndk/folly/folly/FileUtil.cpp:37:14: error: no matching function for call to 'wrapNoInt'
make: Leaving directory '/Users/mweststrate/Desktop/react-native/ReactAndroid/src/main/jni/react/jni'
  return int(wrapNoInt(open, name, flags, mode));
             ^~~~~~~~~
/Users/mweststrate/Desktop/react-native/ReactAndroid/build/third-party-ndk/folly/folly/detail/FileUtilDetail.h:34:9: note: candidate template ignored: couldn't infer template argument 'F'
ssize_t wrapNoInt(F f, Args... args) {
        ^
1 error generated.
make: *** [/opt/android_sdk/ndk/21.3.6528147/build/core/build-binary.mk:478: /Users/mweststrate/Desktop/react-native/ReactAndroid/build/tmp/buildReactNdkLib/local/armeabi-v7a/objs/folly_json/folly/FileUtil.o] Error 1
make: *** Waiting for unfinished jobs....
fcntl(): Bad file descriptor
make: Entering directory '/Users/mweststrate/Desktop/react-native/ReactAndroid/src/main/jni/react/jni'
[armeabi-v7a] Compile++ thumb: folly_json <= Demangle.cpp
```

No idea if it is related. I guess not since without making the change I got the same error.

Reviewed By: mweststrate

Differential Revision: D23767388

Pulled By: fkgozali

fbshipit-source-id: 35f0d3ddec41942f5bbc96cb391975d84729ef5e

* Fix flattening/unflattening case on Android

Summary:
There are cases where we Delete+Create a node in the same frame. Practically, the new differ should prevent this, but we don't want to rely on that necessarily.

See comments for further justification on why deleteView can do less work overall.

In reparenting cases, this causes crashes because dropView removes *and deletes* children that shouldn't necessarily be deleted.

Changelog: [Internal]

Reviewed By: shergin

Differential Revision: D23775453

fbshipit-source-id: c577c5af8c27cfb185d527f0afd8aeb08ee3a5fe

* Have BatchMountItem log the exact item that crashes

Summary:
Because BatchMountItem executes many items, sometimes it's unclear which MountItem causes a crash. Catch and log the exact item.

This shouldn't cause perf regressions because we have a try/catch block in FabricUIManager where execute is called.

Changelog: [Internal]

Reviewed By: shergin

Differential Revision: D23775500

fbshipit-source-id: c878e085c23d3d3a7ef02a34e5aca57759376aa6

* Additional differ test: flattening differ should not produce DELETE and CREATE mutation for the same tag in the same frame

Summary:
See additional assertion. Tests still pass, so no other change was necessary.

Changelog: [Internal]

Differential Revision: D23775553

fbshipit-source-id: 57d3191f25dd55ab4da189207f6d201a31b175e0

* Fabric: Removing catching all exceptions in UIManager::completeRoot

Summary:
This is a revert of D23529233 (https://github.com/facebook/react-native/commit/902611f14837752353e919dd1740812ec7260fb8).
It turns out it was a bad idea. With this catch-all thing, we don't get new information. Yeah, we crash earlier now but seems we have even less information about the crash. :(

I think D23754284 (https://github.com/facebook/react-native/commit/04c874bd9c6b15274fd87acf10cb3533b2eabc0d) should fix the issue.

Changelog: [Internal] Fabric-specific internal change.

Original commit changeset: 7ac7fb26ac08

Reviewed By: sammy-SC

Differential Revision: D23786086

fbshipit-source-id: 86784df0193abfb7328c4d5a16a9af4214e9a161

* Fabric: Marking all JS function lambdas `noexcept` in UIManagerBinding

Summary:
Exceptions in C++ work quite differently from exceptions in other languages. To make exceptions actually work **correctly** all the code needs to be written with "exceptions in mind" (e.g., see https://www.stroustrup.com/except.pdf). In short, if the code is not "exceptions ready", throwing an exception causes memory leaks, dangling pointers, and invariant violations all over the place, which will probably cause another crashes down the road (which will be especially hard to investigate and attribute to the original issue).
Fabric Core (Layout, Props parsing, ShadowNodes management, and so on) does not use exceptions because in most (all?) the cases the exception is now recoverable. So, if a program detects some internal state invariant violation or missing some resource, *logically* it's fatal. We also don't want to pay code-size and performance tax for exception support, so that's why we don't use them. It's just not the right fit for Fabric Core.

This does not mean that exceptions don't happen though. C++ standard library can throw them... sometimes. And if our library is compiled with exceptions enabled (still the case, unfortunately), an exception can bubble to JavaScript code and losing all context down the road. And it's hard to investigate such crashes. To isolate those occasional exceptions inside C++ core we are marking all C++/JS boundaries with `noexcept` that stops the bubbling.

I hope that will give us much more informative crash reports.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: sammy-SC

Differential Revision: D23787492

fbshipit-source-id: 0822dbf36fc680c15b02b5cd0f2d87328296b642

* Move TurboModule Core from ReactCommon/turbomodule to ReactCommon/react/nativemodule

Summary:
This diff moves the code of TurboModule Core from ReactCommon/turbomodule to ReactCommon/react/nativemodule

For iOS: Pod spec name stays as "ReactCommon/turbomodule/..." for now, only the source/header location is affected. The target will be renamed/restructured closer to TurboModule rollout.

changelog: [internal] Internal

Reviewed By: RSNara

Differential Revision: D23362253

fbshipit-source-id: c2c8207578e50821c7573255d4319b9051b58a37

* Notify ViewManagers when a View is deleted

Summary:
In a previous recent diff we changed Android's Delete mount instruction to *not* recursively delete the tree. This is fine, but because of that, we stopped calling `onDropViewInstance` when views are normally deleted.

Bring back that behaviour.

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D23801666

fbshipit-source-id: 54e6b52ab51fff2a45102e37077fe41081499888

* Prevent calling onTextLayout with the same value

Summary:
Changelog: [internal]

In D23648430 (https://github.com/facebook/react-native/commit/a315e4cd30e4b8da841f587650146a62c868f67d) I made a mistake. I prevented calling `onTextLayout` unless there are attachments in the component. It fixed the problem because I unintentionally prevented `onTextLayout`  to be called. Therefore, changes from D23648430 (https://github.com/facebook/react-native/commit/a315e4cd30e4b8da841f587650146a62c868f67d) need to be reverted.

To prevent infinite loop in `onTextLayout`, ParagraphEventEmitter checks if `linesMeasurements` have changed before dispatching it to JS.

Reviewed By: shergin

Differential Revision: D23782717

fbshipit-source-id: 0e84ae4f46d79ce0cf4c7340cd32be6f562ae179

* TurboModule Android: compile TurboModule C++ Core into ReactAndroid

Summary:
This is to prepare for enabling TurboModule on Android. This commit compiles in all the core files (C++) into the ReactAndroid NDK build step. This doesn't yet enable TurboModule by default, just compiling in the infra, just like for iOS.

New shared libs:
* libreact_nativemodule_core.so: The TurboModule Android core
* libreact_nativemodule_manager.so: The TurboModule manager/delegate

To be compatible with `<ReactCommon/` .h include prefix, the files had to move to local `ReactCommon` subdirs.

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D23805717

fbshipit-source-id: b41c392a592dd095ae003f7b2a689f4add2c37a9

* Add additional logging and asserts to StubViewTree

Summary:
Helps in testing LayoutAnimations or differ changes.

Changelog: [Internal]

Reviewed By: fkgozali

Differential Revision: D23797890

fbshipit-source-id: 1e612c04f9fbb256f2ace8a4a2ed9a477b4695a1

* Deleting unnecessary Differentiator code

Summary:
In the new Flattening differ, I experimentally verified that these two code paths are not hit (or redundant) and deleted them.

One of the branches did nothing and the other produced duplicate DELETE mutations for the same tag, that is handled elsewhere.

Changelog: [Internal]

Reviewed By: fkgozali

Differential Revision: D23806161

fbshipit-source-id: 9ad2929e2d719a7b9b34640ed35f7a696103604b

* LayoutAnimations: simplify index adjustment, (un)flattening detection

Summary:
In this diff I simplify index adjustment and add comments to rigorously describe what we're doing at each step of index adjustment.

I've also made unflattening detection more correct, robust, and slightly more efficient.

Bugs that existed before:

1) The reparenting detection that existed in the animations layer had some subtle bugs. I don't have proof that it results in any correctness issues or crashes, but I suspect it.
2) Correctness of index adjustment: there were cases where the Android mounting layer would crash because LayoutAnimations would try to remove a View at an index, but the index was wrong. This is why I sat down and diagrammed the relationships between all the bits of data we have for index readjustment - I believe this to be correct now.
3) Correctness of INSERT index adjustment: I had the insight that when we have batches of INSERTs to consecutive indices, we essentially want them to be treated as a single INSERT for adjustment purposes, so that they're all placed consecutively in the view layer. I added `ConsecutiveAdjustmentMetadata` to deal with this, and there are more comments in the code.

Changelog: [Internal]

Reviewed By: yungsters

Differential Revision: D23806163

fbshipit-source-id: cd9e94945034db8b840f2a806c6377034a91af61

* Deploy Flow v0.134.0

Summary: Changelog: [Internal]

Reviewed By: dsainati1

Differential Revision: D23769795

fbshipit-source-id: 520e3974a53ba5961a081219c0cbf19b7dfade06

* Daily `arc lint --take CLANGFORMAT`

Reviewed By: zertosh

Differential Revision: D23811656

fbshipit-source-id: 4104948d2e4db786998320bcfdb1598d4a497f2d

* Add extras to timespan and points in performance logger

Summary:
Changelog:
[Internal][Added] Added point-level extras to performance logger

Reviewed By: lunaleaps, rubennorte

Differential Revision: D23730275

fbshipit-source-id: 285c5d7ac769bd109df7ce0294da024401edf7d3

* Making Android versionCodeOverride for new apps using the template human-readable (#29808)

Summary:
The current calculation on versionCodeOverride is not human-readable.

Imagine if we have an android app with **versionName** `4.0` and **version code** `4`.

In the current implementation, the result of **versionCode** `4` for `armeabi-v7a` will be the seemingly arbitrary **1048580**. This makes the version code to be seemingly arbitrary and hard to read for humans. This PR proposes to change this calculation closer to google implementation of build number in Flutter (`abiVersionCode * 1000 + variant.versionCode`).
https://github.com/flutter/flutter/blob/39d7a019c150ca421b980426e85b254a0ec63ebd/packages/flutter_tools/gradle/flutter.gradle#L643-L647

With this change, our app with `versionCode 4 versionName "4.0"` for  `armeabi-v7a`  will have **1004**  as the version code instead of the seemingly arbitrary **1048580**. As you can see adopting the flutter style implementation make the version code easier to read and debug.

**1004**
**1** - The ABI Type `["armeabi-v7a": 1, "x86": 2, "arm64-v8a": 3, "x86_64": 4]`
**004** - Our versionCode.

Hopefully, this can prevent future issues like this https://github.com/facebook/react-native/issues/29790.

## Changelog

[Android] [Changed] - Making Android versionCodeOverride for new apps using the template human-readable

Pull Request resolved: https://github.com/facebook/react-native/pull/29808

Reviewed By: sammy-SC

Differential Revision: D23804632

Pulled By: fkgozali

fbshipit-source-id: 89b2c196b3bfe01fa608dfb595db6d3314ca1d63

* Codegen Android: adjust JNI output to compile from Gradle

Summary:
This adjusted the C++ output for Android codegen (NativeModule specs) so we can compile it with ndk-build in Gradle:
* Use `#include` instead of `#import` for header files
* Added `#pragma once`
* Removed direct include of `<fb/fbjni.h>` -- this is not necessary
* Added generated Android.mk file based on library name

Changelog: [Internal]

Reviewed By: shergin

Differential Revision: D23809082

fbshipit-source-id: 11ddfea7b48c8b2eb6efe885641ace4fc327d50d

* Codegen Android: Compile ReactAndroid codegen C++ output

Summary:
Now that the react-native-codegen produces the Android.mk for the JNI C++ output, let's compile them into its own shared library, to be included in the ReactAndroid final deliverable: libreact_codegen_reactandroidspec.so. This is gated behind `USE_CODEGEN` env var.

Note: RNTester specific C++ spec files are not compiled here.

Changelog: [Internal]

Reviewed By: shergin

Differential Revision: D23809081

fbshipit-source-id: 7a90f420a923d5d02654facac01ffe025c321e44

* Use Element<> in FindNodeAtPointTest

Summary: Changelog: [Internal]

Reviewed By: JoshuaGross

Differential Revision: D23815171

fbshipit-source-id: bf420be172a55a966f8881371473e121c3848c78

* Fix ordering of children in LayoutableShadowNode::findNodeAtPoint

Summary:
Changelog: [internal]

`LayoutableShadowNode::findNodeAtPoint` was iterating children in incorrect order and wasn't taking zIndex into accout.

Reviewed By: JoshuaGross

Differential Revision: D23814866

fbshipit-source-id: 38eee297147a5c5912304d139bb10f8b16ae2ee1

* Call stopObserving on correct queue

Summary:
Since `dealloc` can be called from any thread, this would result `stopObserving` being called on a different thread/queue than the specified `methodQueue`. We specifically encountered this issue with a module needing the main queue having its `stopObserving` called on a background queue.

Changelog:
[iOS][Fixed] - Call [RCTEventEmitter stopObserving] on specified method queue

Reviewed By: RSNara

Differential Revision: D23821741

fbshipit-source-id: 693c3be6876f863da6dd214a829af2cc13a09c3f

* Pull out construction of Layout from TextLayoutManager.measureText into separate function

Summary:
Changelog: [Internal]

Construction of Layout will be needed in `TextLayoutManager.measureLines`, pulling it out into separate function prevents code duplication.

Reviewed By: shergin

Differential Revision: D23782905

fbshipit-source-id: 8ab817559ca154716a190ca1012e809c5fa2fd6e

* Wire call from C++ to Java to get lines measurements

Summary: Changelog: [Internal]

Reviewed By: shergin

Differential Revision: D23782998

fbshipit-source-id: fa9bda274c024d5bbd3ca24f394b5d76f8c07ad2

* Implement onTextLayout on Text component.

Summary:
Changelog: [Internal]

Add `Text.onTextLayout` implementation to Android's Text component.

Reviewed By: JoshuaGross

Differential Revision: D23782311

fbshipit-source-id: fdb5709aaf68efee0ab895a6661396f92cfc768a

* Fix Xcode bundler in staging and release (#29477)

Summary:
Revert "feat: improve monorepo support by removing redundant PROJECT_ROOT (https://github.com/facebook/react-native/issues/28354)"

This reverts commit a8e85026cfa60056b1bcbcd39cde789e4d65f9cb.

This commit a8e85026cfa60056b1bcbcd39cde789e4d65f9cb somehow broke the bundler when making a staging or release build in Xcode that results in unresolved files and main.jsbundle nonexistance issue. I figured this out by replacing react-native-xcode.sh from RN v0.63.2 by the one from v0.62.2 where everything works just fine and then reverting the changes line by line. It seems like this pr will fix similar issues stated here https://stackoverflow.com/questions/62806319/main-jsbundle-does-not-exist-this-must-be-a-bug-with-main-jsbundle-issue-afte/62829256#62829256 and here https://github.com/facebook/react-native/issues/29205

## Changelog

[iOS] [Fixed] - fix "main.jsbundle does not exist" issue

Pull Request resolved: https://github.com/facebook/react-native/pull/29477

Test Plan:
With react-native-xcode.sh from RN v0.63.2
![image](https://user-images.githubusercontent.com/32848434/88342113-7ce55d80-cd47-11ea-9dab-bf41ec6d6ab5.png)

With my changes
![image](https://user-images.githubusercontent.com/32848434/88342376-f0876a80-cd47-11ea-9c08-96b892784da1.png)

Reviewed By: sammy-SC

Differential Revision: D23817847

Pulled By: hramos

fbshipit-source-id: 4b729c1231d30e89073b2520aeadee944c84421c

* New Share API Use Cases (#29856)

Summary:
* New use cases for share API in rn-tester

## Changelog
[General] [Changed] - Changed use cases for share API in rn-tester

## Test Plan
* Tested app in both Android and iOS

![Screenshot_2020-09-09-21-20-41-322_com facebook react uiapp](https://user-images.githubusercontent.com/42653703/92624772-83bf3400-f2e5-11ea-820f-a7f3d9a44a11.jpg)

![image](https://user-images.githubusercontent.com/42653703/92624985-c1bc5800-f2e5-11ea-9f30-b88ab786963b.png)

Pull Request resolved: https://github.com/facebook/react-native/pull/29856

Reviewed By: hramos

Differential Revision: D23784222

Pulled By: rickhanlonii

fbshipit-source-id: f311201a49e0a76abb6634232106ed756143da30

* Open source react-native-modules ESLint rule

Summary:
Open source this ESLint rule so that we can lint our open source NativeModule specs.

Changelog: [Internal]

Reviewed By: shergin, cpojer

Differential Revision: D23791748

fbshipit-source-id: e44444bc87eaa9dc9b7f2b3ed03151798a35e8a5

* feat: enable bitcode (#365)

Summary:
Bitcode is turned on by default in React Native and so, setting it here as well.

Changelog: [iOS] [Changed] - Upgraded JSI with a new HERMES_ENABLE_BITCODE flag

Pull Request resolved: https://github.com/facebook/hermes/pull/365

Reviewed By: tmikov

Differential Revision: D23823228

Pulled By: Huxpro

fbshipit-source-id: d43638818a733f6a87b2f4a1ecadad8ea9c7a419

* Add new ReactMarkers for bridgeless init start/end

Summary: Adding two new ReactMarkers for start and end of bridgeless initialization. Creating new ones instead of reusing existing ones to make it easier to differentiate data from the bridge vs. bridgeless, and also because our existing markers 1) aren't very easy to understand, and 2) don't map cleanly to the new architecture.

Reviewed By: PeteTheHeat

Differential Revision: D23789156

fbshipit-source-id: 2ed10769e08604e591503a2bc9566aeb1d0563ed

* Set useLineSpacingFromFallbacks when measuring text

Summary:
Changelog: [internal]

When paper measures text, it sets `useLineSpacingFromFallbacks` flag on the Layout object. In Fabric this was missing and can cause incorrect layout.

Reviewed By: JoshuaGross

Differential Revision: D23845441

fbshipit-source-id: 538f440cdbbf8df2cba0458837b80db103888113

* Make React-Core compatible with Swift modules (#29995)

Summary:
Related to https://github.com/facebook/react-native/issues/29633

Support Swift based libraries using Xcode 12’s build system.

## Changelog

[iOS] [Fixed] - Support Swift based libraries using Xcode 12’s build system.

Pull Request resolved: https://github.com/facebook/react-native/pull/29995

Test Plan:
* Building RNTester still works
* Swift based pod tested in https://github.com/mrousavy/react-native-blurhash/issues/58

Reviewed By: fkgozali

Differential Revision: D23824438

Pulled By: appden

fbshipit-source-id: 418caf9808cb6326e3d6efdc8b37131a5705e7f6

* Sort logger alphabetically

Summary:
Rearranging to alphabetically sort, no functionality changes

Changelog: [Internal]

Reviewed By: rubennorte, motiz88

Differential Revision: D23836997

fbshipit-source-id: 00232b88379e44920ecb74fa6ff43f36d941d93b

* Add close() to IPerformanceLogger

Summary:
To represent a final state where a logger should no longer be used

Changelog: [Internal] - To represent a final state where a logger should no longer be used

Reviewed By: rubennorte

Differential Revision: D23845307

fbshipit-source-id: 4b2bfda4f7425ba6bc8e5e1233d9baea60dd8667

* RNTester Android: Add stub C++ for TurboModule provider (#30014)

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/30014

This is the base setup to compile C++ as part of RNTester app. There is no dependencies on ReactAndroidNdk lib yet, just a bunch of ndkBuild setup in Gradle. Note: this is using Gradle's `nkdBuild` support instead of calling `ndk-build` manually like in ReactAndroid/build.gradle.

Reference: https://google.github.io/android-gradle-dsl/current/com.android.build.gradle.internal.dsl.ExternalNativeNdkBuildOptions.html

Note that `ANDROID_NDK` env var is honored to pick the right NDK version.

For now, this is gated behind `USE_CODEGEN` env variable.

Changelog: [Internal]

Reviewed By: JoshuaGross

Differential Revision: D23887058

fbshipit-source-id: 7a962649461d15af46999a15b900464543e5b05c

* New Button Component Use Cases (#29848)

Summary:
* New use cases for button component in rn-tester
 * E2E tests for the button component

## Changelog
[General] [Changed] - Changed use cases for button component in rn-tester

## Test Plan
![image](https://user-images.githubusercontent.com/42653703/92123053-ced6d400-ee19-11ea-8f10-c5e8529c85ca.png)
After -
![image](https://user-images.githubusercontent.com/42653703/92625569-70609880-f2e6-11ea-9fb9-f7327d842a34.png)
Before -
![image](https://user-images.githubusercontent.com/42653703/92625555-6a6ab780-f2e6-11ea-90d1-8c54ebc60062.png)

Pull Request resolved: https://github.com/facebook/react-native/pull/29848

Reviewed By: hramos

Differential Revision: D23649694

Pulled By: rickhanlonii

fbshipit-source-id: 3590eca08ea58c771596ad731f74eb233b1a40d8

* Minor Code Improvements in RNTester (#29868)

Summary:
* Update single-letter variable names to be more descriptive
* Remove event listener on component unmount
* Add flow types
* Refactor RNTesterNavbar to use descriptive component names

Pull Request resolved: https://github.com/facebook/react-native/pull/29868

Reviewed By: hramos

Differential Revision: D23598579

Pulled By: rickhanlonii

fbshipit-source-id: c5cfc61d7b2fcb2942bf149d0a8ba0b58b0192e6

* Prevent change of delegate in RCTUITextView

Summary:
Changelog: [internal]

# Problem

`[RCTUITextView setDelegate]` is a public method and if something changes the delegate, appropriate events won't be called on the component (onTextChange, onSelectionChange and the others).

# Solution

Prevent setting of delegate from outside of the class. Ideally we would want to hide `setDelegate` altogether but that would require a rewrite of `RCTUITextView`.

Reviewed By: JoshuaGross, shergin

Differential Revision: D23813095

fbshipit-source-id: 8b76ac86727d262d0f9b81adfc8e75157847284c

* Fix touch handling in bridged paper components

Summary:
Changelog: [internal]

If view was bridged from Paper, hit testing would return Paper view which doesn't have reference to Fabric's event emitter.
To fix this, if the bridged view is returned from hit testing, it is swapped with interop view which has reference to event emitter.

Reviewed By: shergin

Differential Revision: D23840054

fbshipit-source-id: d4aa4ee8da4e1da80d2e2b69b79ed82d726f04e3

* TurboModule Android: add dependency on ReactAndroid codegen output to RNTester

Summary:
This adds shared libraries dependencies to RNTester so that it can call `ReactAndroidSpec_ReactAndroidSpec_ModuleProvider()` C++ lookup function. That function is generated by the react-native-codegen during build time. This does not make RNTester use TurboModule yet, just the necessary setup to link the C++ libs together.

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D23901952

fbshipit-source-id: fd5ee0ca266609207962adc5ceaf814956052eec

* Fix rounding in Slider component

Summary:
Changelog: [Internal]

There was a typo in condition. We need to be comparing step prop and not value. The same condition is implemented in Paper.

Reviewed By: JoshuaGross

Differential Revision: D23903493

fbshipit-source-id: 37506d0fac63f624332041602489ab1cf378bfcc

* Do not override decoders to RCTImageLoader (#29711)

Summary:
I (actually, [we](https://github.com/expo/expo/issues/9858)) noticed GIFs are no longer animating in Expo client after [enabling TurboModules](https://github.com/expo/expo/pull/9687).

## Changelog

[iOS] [Fixed] - Fix `RCTImageLoader` not using decoders provided.

<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->

Pull Request resolved: https://github.com/facebook/react-native/pull/29711

Test Plan:
![cat](https://user-images.githubusercontent.com/1151041/90775800-90112c00-e2f9-11ea-95cd-ab95a97068f4.gif)

The cat is moving! Before applying this commit `RCTGIFDecoder` provided in the initalizer is removed from the `_decoders` array in the

```objc
_decoders = [_bridge modulesConformingToProtocol:protocol(RCTImageDataDecoder)];
```

Also, compare

https://github.com/facebook/react-native/blob/8f306cd66a8bc6054ee13701f02329ab5817b69a/Libraries/Image/RCTImageLoader.mm#L243-L250

and

https://github.com/facebook/react-native/blob/8f306cd66a8bc6054ee13701f02329ab5817b69a/Libraries/Image/RCTImageLoader.mm#L177-L184

This PR makes `_decoders` behave the same as `_loaders`.

Reviewed By: PeteTheHeat

Differential Revision: D23908238

Pulled By: fkgozali

fbshipit-source-id: 1d7a6e0d180277f23d8c28916734713bc1833b8b

* Fix rounding issue when setting padding

Summary:
Changelog: [Internal]

Padding needs to be rounded down (floor function), not rounded to the closest natural number.
Otherwise the content of the view might not fit.

Reviewed By: JoshuaGross

Differential Revision: D23905145

fbshipit-source-id: e84d70155b207144b98646dd0c4fea7a8c4bd876

* LayoutAnimations: force props to update when executing "final" mutations

Summary:
When an animation is completed or a conflicting animation is detected, force props, state, layout, etc to update.

Currently, when a final animation mutation is queued, some attributes can be updated but not others, causing unexpected visual glitches at least on Android.

Some of these are arguably component bugs, but it's easier to just flush all attributes by tricking the platforms into updating all attributes. This will also prevent us from having to track down more of these bugs, potentially.

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D23886519

fbshipit-source-id: 8e5081bbe3b7843c16c0f283fa07fdec0e211aa8

* TurboModule Android: compile codegen C++ output into librntester_appmodules.so

Summary:
The react-native-codegen provides Android.mk in the Android C++ output, but for RNTester (or hosting apps), we should just compile the codegen output with the rest of the app-specific C++ files. This is to simplify the build configuration, and also to not add too many additional .so libs to the APK.

With this commit, `RNTesterAppModuleProvider.cpp` should be "complete" for RNTester use-case. This TurboModule lookup function is the one described in https://github.com/react-native-community/discussions-and-proposals/issues/273.

Changelog: [Internal]

Reviewed By: hramos

Differential Revision: D23913149

fbshipit-source-id: d1ca136787b87a0e8e6504318e1f0a78efef46ea

* Follow-up for fixing xiaomi NullPointer crash

Summary:
This is a follow-up for fixing the xiaomi NullPointer crash (D23331828 (https://github.com/facebook/react-native/commit/07a597ad185c8c31ac38bdd4d022b0b880d02859) D23451929 (https://github.com/facebook/react-native/commit/b5b4a7041027fd767850a564b5d80fa4a98ba2a2)):

1, Clean up previous temporary fix in js.

2, Cover all cases including caretHidden is set and isn't set, in previous fix if caretHidden isn't set then fix won't be executed.

Changelog: [Internal]

Reviewed By: makovkastar

Differential Revision: D23816541

fbshipit-source-id: a7543f6767430abb74141a747b08391986662958

* Workaround for Date Picker in iOS14

Summary:
iOS14 has introduced new styles for date picker. The default new calendar style breaks the old spinner type style.

This is a workaround to keep the spinner style as a default, until the calendar style is properly supported. According to [this github comment](https://github.com/react-native-community/datetimepicker/issues/285) it works well.

This will fix DatePicker for both Fabric and Paper, since Fabric uses the interop layer to render it.

Changelog: [Internal]

Reviewed By: fkgozali

Differential Revision: D23935328

fbshipit-source-id: 1a7fadba274e0537f0ac4ced60e23e7c809d57dc

* Group accessible views using the view hierarchy

Summary: In iOS when a parent UIView returns YES on [shouldGroupAccessibilityChildren](https://developer.apple.com/documentation/objectivec/nsobject/1615143-shouldgroupaccessibilitychildren), VoiceOver groups together the accessible children of the parent view, regardless of their position on screen. In iOS this defaults to NO.

Reviewed By: sammy-SC

Differential Revision: D23844265

fbshipit-source-id: eb99bf0873ccfd9fb196f8f7b6eafe055f6ae810

* Fabric: Fixed crash in `colorComponentsFromColor()`

Summary:
This fixes a recently introduced crash in `colorComponentsFromColor()` (iOS implementation) caused by dereferencing a null pointer.

The fix is just a copy of a code fragment from a previous implementation.

Reviewed By: fkgozali

Differential Revision: D23944812

fbshipit-source-id: 977135dd75c4375affddfd75183e4890618ae819

* round up layoutWidth for Android 11 in ReactTextShadowNode

Summary:
in Android 11, there's an issue where Text content is being clipped. The root cause appears to be a breaking change in how Android 11 is measuring text. rounding up the layoutWidth calculation mitigates the issue.

Changelog: [Internal]

Reviewed By: JoshuaGross

Differential Revision: D23944772

fbshipit-source-id: 1639259da1c2c507c6bfc80fed377577316febac

* Don't crash when promise task is cancelled before its resolved (#29969)

Summary:
This pull request fixes a potential `TypeError` in TaskQueue.js, that happens if a promise is added to the task queue, which is cancelled between the promise starting and resolving.

The exact error this resolves is
```js
TypeError: TaskQueue: Error resolving Promise in task gen1: Cannot set property ‘popable’ of undefined
      167 |           queueStackSize: this._queueStack.length,
      168 |         });
    > 169 |       this._queueStack[stackIdx].popable = true;
          |                                              ^
      170 |       this.hasTasksToProcess() && this._onMoreTasks();
      171 |     })
      172 |     .catch(ex => {
      at Libraries/Interaction/TaskQueue.js:169:46
```

This specific error was also reported in https://github.com/facebook/react-native/issues/16321

## Changelog

[General] [Fixed] - Prevent TypeError in TaskQueue when cancelling a started but not resolved promise.

Pull Request resolved: https://github.com/facebook/react-native/pull/29969

Test Plan:
The added test demonstrates the error, if run without the fixed applied to TaskQueue.js.
This is a race condition error, so is difficult to replicate!

Reviewed By: yungsters

Differential Revision: D23785972

Pulled By: appden

fbshipit-source-id: ddb8d06b37d296ee934ff39815cf5c9026d73871

* Android: consolidate various prebuilt C++ .so configuration into Android-prebuilt.mk

Summary:
To make it easier for hosting app or other lib to get access to the ReactAndroidNdk .so outputs, let's define common targets in a dedicated Android-prebuilt.mk. Hosting app's Android.mk just need to include the mk path.

Changelog: [Internal]

Reviewed By: yungsters

Differential Revision: D23938538

fbshipit-source-id: 850d690326d134212d5f040c6fa54ab50c53cb87

* TurboModule Android: rename libreact_nativemodule_manager to libturbomodulejsijni

Summary:
TurboModule Java files are still using the old lib name: `turbomodulejsijni`, so let's keep it that way for now.

Changelog: [Internal]

Reviewed By: yungsters

Differential Revision: D23946945

fbshipit-source-id: ff095ff51dca532c82e67e1c75e9a4e9be392d61

* TurboModule Android: Implement TurboModuleManagerDelegate specific to RNTester

Summary:
This provides the RNTester specific impl of the manager delegate. The class is responsible to provide module lookup during runtime for TurboModule, and the C++ impl is using the codegen-generated lookup functions from :ReactAndroid and :packages:rn-tester:android:app Gradle targets.

Note: RNTester still needs to explicitly enable TurboModule and instantiate this manager before it can activate TurboModule.

Changelog: [Internal]

Reviewed By: yungsters

Differential Revision: D23938537

fbshipit-source-id: 7957847ecc58fef8d9a276d9d3d477ecec36a700

* TurboModule Android: allow RNTester to activate TurboModule system

Summary:
If built with `USE_CODEGEN=1` flag set, RNTester now activates the TurboModule system, also using various codegen output from the previous commits.

Note that this is very early integration, and not thoroughly tested yet.

To verify:

```
console.warn('TM enabled?', global.__turboModuleProxy != null);
```

{F337454276}

Changelog: [Internal]

Reviewed By: yungsters

Differential Revision: D23946944

fbshipit-source-id: 5838aeb9ded07b1cc0fcb069535d1c6fb3725973

* Fix passing react native path in Podfile template (#29285)

Summary:
Since https://github.com/react-native-community/cli/commit/e949e234b03fb65f8e4ed2706dfaa745aa59a14f#diff-d1800049b92343288bcbc1c484575058 the RN cli script returns an object with `:reactNativePath` instead of just JSON. Not super familiar with how objects / JSON works in ruby but using this syntax instead works.

## Changelog

[Fixed] [iOS] - Fix passing react native path in Podfile template

Pull Request resolved: https://github.com/facebook/react-native/pull/29285

Test Plan: Tested in a project inside a monorepo using the latest version of RN CLI that the proper react-native path is now passed.

Reviewed By: fkgozali

Differential Revision: D23941162

Pulled By: hramos

fbshipit-source-id: 0115412ec6d6bca101612d760dfc00cf89d97f1e

* Animated: Early detection of division by zero in AnimatedDivision

Summary:
Same as D20969087 (https://github.com/facebook/react-native/commit/be7867375580ed391bb10c50b768d998087e848d) but a bit more sophisticated.

We currently see a lot of errors happens because of division by zero in AnimatedDivision module. We already have a check for that in the module but it happens during the animation tick where the context of execution is already lost and it's hard to find why exactly it happens.
Adding an additional check to the constructor should trigger an error right inside render function which should make the error actionable.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: fkgozali

Differential Revision: D23908993

fbshipit-source-id: d21be9a72ec04fe4ff0740777d9ff49cf1bcde73

* Fabric: Failing early in case if a argument of `-[RCTComponentViewFactory registerComponentViewClass:]` is nil

Summary:
Subject.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: JoshuaGross

Differential Revision: D23914517

fbshipit-source-id: 1c909e7d21b12326881990ecf855e814bf957f3c

* Fabric: Adding `#pragma once` to `ImageTelemetry.h`

Summary:
Without this thing some stuff does not compile.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: fkgozali

Differential Revision: D23948622

fbshipit-source-id: f066ada183c0fd6a7b5eec542395d44bbbfe80a3

* Make blocking people work in Dating Settings

Summary:
Blocking people didn't work in Dating Settings without the Bridge.

Changelog: [Internal]

Reviewed By: ejanzer

Differential Revision: D23904867

fbshipit-source-id: 4a68b9d99fcc812f6616783a06dc047a3bc64491

* Fix slider's initial value

Summary:
Changelog: [Internal]

value needs to be set after minimum and maximum, otherwise it gets pinned to previous minimum/maximum.

Default minimum is 0 and maximum is 1. If we set value to 20 and maximum to 50, previously the value would get pinned to 1 (maximum value).

See [Apple Docs](https://developer.apple.com/documentation/uikit/uislider/1621346-value?language=objc) for more.

Reviewed By: JoshuaGross

Differential Revision: D23903545

fbshipit-source-id: 8e9dd49ced79d43b9591c7d24de59b9eaff5bdfd

* Do not attach root view until size is available

Summary:
Changelog: [internal]

# Why is text laid out twice in Fabric?

Layout constraints (min and max size) change during startup of Fabric surface.
1. `Scheduler::startSurface` is called with max size being {inf, inf}.
2. `Scheduler::constraintSurfaceLayout` is called with max size equal to viewport.

These are two operations that don't happen one after the other and on Android, CompleteRoot is called from JS before second operation is called. This triggers layout with max size {inf, inf} and later when second operation is called. Layout happens again now with correct size.

# Fix
Make sure `Scheduler::startSurface` is called with proper values and not {inf, inf}.

Reviewed By: JoshuaGross, yungsters

Differential Revision: D23866735

fbshipit-source-id: b16307543cc75c689d0c1f0a16aa581458f7417d

* RNTester: Add TextInput example to RTL tester

Summary:
Add a TextInput to RTL screen in RNTester, to test RTL languages with TextInput.

Changelog: [Internal]

Reviewed By: shergin

Differential Revision: D23914627

fbshipit-source-id: 84c62efe7034c0dfa2ef21be3f085880292c3930

* Update PerformanceLogger to nullable timespans, points, extras

Summary: Changelog: [Internal][Fixed] - When we close performance loggers (D23845307 (https://github.com/facebook/react-native/commit/aebb97b9c64a8d84cf852ae8efc5ef28b36da610)) we cannot rely that a timespan/point/extra will be in perf logger. Update types to reflect that.

Reviewed By: rubennorte

Differential Revision: D23907741

fbshipit-source-id: 63673aa69cd8c76253e4fee3463e37c86265cf7b

* Make the Instagram app compile again

Summary:
Wrap iOS 14 SDK code in a `#if/#endif` so that the Instagram app compiles again

Changelog: [Internal]

Reviewed By: PeteTheHeat

Differential Revision: D23948336

fbshipit-source-id: 67e6ee48d1951ae405c12b4ad39cf8c9817df627

* Pressability: Support Lazy Hook Initialization

Summary:
Changes `usePressability` so that it accepts a nullable `config` argument.

This makes it possible for a component to use `usePressability` and lazily allocate the `config` and subsequent instance of `Pressability`. This can be useful for components that are commonly allocated but seldom pressed because it lets many usages of `usePressability` avoid allocating many extraneous objects.

Changelog:
[Internal]

Reviewed By: kacieb

Differential Revision: D23708206

fbshipit-source-id: 4a5063067131ce8c957fb16c49a2045e8c0b19fa

* Text: Cleanup Native Component Configuration

Summary:
Cleans up the native component configuration for `RCTText` and `RCTVirtualText`.

This //does// lead to a breaking change because `Text.viewConfig` will no longer exist. However, I think this is acceptable because `viewConfig` has already long stopped being an exported prop on other core components (e.g. `View`).

Changelog:
[General][Removed] - `Text.viewConfig` is no longer exported.

Reviewed By: shergin

Differential Revision: D23708205

fbshipit-source-id: 1ad0b0772735834d9162a65d9434a9bbbd142416

* remove most of tvOS remnants from the code (#29407)

Summary:
Refs: [0.62 release](https://reactnative.dev/blog/#moving-apple-tv-to-react-native-tvos), https://github.com/facebook/react-native/issues/28706, https://github.com/facebook/react-native/issues/28743, https://github.com/facebook/react-native/issues/29018

This PR removes most of the tvOS remnants in the code. Most of the changes are related to the tvOS platform removal from `.podspec` files, tvOS specific conditionals removal (Obj-C + JS) or tvOS CI/testing pipeline related code.

In addition to the changes listed above I have removed the deprecated `Platform.isTVOS` method. I'm not sure how `Platform.isTV` method is correlated with Android TV devices support which is technically not deprecated in the core so I left this method untouched for now.

## 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
-->

* **[Internal] [Removed]** - remove most of tvOS remnants from the code:
  * `TVEventHandler`, `TVTouchable`, `RCTTVView`, `RCTTVRemoteHandler` and `RCTTVNavigationEventEmitter`
* **[Internal] [Removed]** - remove `TARGET_TV_OS` flag and all the usages
* **[iOS] [Removed]** - remove deprecated `Platform.isTVOS` method
* **[iOS] [Removed]** - remove deprecated and TV related props from View:
  * `isTVSelectable`, `hasTVPreferredFocus` and `tvParallaxProperties`
* **[iOS] [Removed]** - remove `BackHandler` utility implementation

Pull Request resolved: https://github.com/facebook/react-native/pull/29407

Test Plan: Local tests (and iOS CI run) do not yield any errors, but I'm not sure how the CI pipeline would react to those changes. That is the reason why this PR is being posted as Draft. Some tweaks and code adjustment could be required.

Reviewed By: PeteTheHeat

Differential Revision: D22619441

Pulled By: shergin

fbshipit-source-id: 9aaf3840c5e8bd469c2cfcfa7c5b441ef71b30b6

* chore: deduplicate lock, update packages repository fields (#30044)

Summary:
This small PR includes the following changes:
* deduplicate yarn lock file using [`yarn-deduplicate`](https://github.com/atlassian/yarn-deduplicate) package
  * deduplicate script has been added as `update-lock`, let me know if you would like also to see this in [`postinstall`](https://docs.npmjs.com/misc/scripts) (to automatically optimize lock on every dependency change)
* according to the [npm docs](https://docs.npmjs.com/files/package.json#repository):
  * main `package.json` repository field has been replaced with shorthand
  * monorepo packages repository field has been extended by `directory`

The main goal of introducing deduplication script was to optimize the dependencies footprint while developing and speed up the initial installation process. Running `yarn-deduplicate` also increase the security in some way, because it enforces usage only of the latest version of the package. You can read more about the benefits in the deduplicate script [repository](https://github.com/atlassian/yarn-deduplicate#duplicated-packages).

## 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
-->

[Internal] [Added] - add yarn lock deduplication script

Pull Request resolved: https://github.com/facebook/react-native/pull/30044

Test Plan: `yarn install` was successful, this also should not affect yarn workspaces in any way.

Reviewed By: GijsWeterings

Differential Revision: D23959812

Pulled By: cpojer

fbshipit-source-id: e2455e3718378e1ce6206e79463d4083f8fe5d47

* Daily `arc lint --take CLANGFORMAT`

Reviewed By: zertosh

Differential Revision: D23986055

fbshipit-source-id: 7bfe9f06f236f8866e812db060edf3d089fe253c

* Convert AndroidDialogPicker to JS view configs

Summary:
Convert AndroidDialogPicker to JS view configs

Changelog: [Internal]

Reviewed By: ejanzer

Differential Revision: D23911673

fbshipit-source-id: d5fefa997432f0096308ab5593ba74c2c07b71e1

* Fix dismissal animation of Modal Component

Summary:
Changelog: [Internal]

Fabric removes components bottom up (from leafs to the root).
This means that by the time Fabric hides Modal, it has no content and therefore it appears as if Modal disappears without Animation.

To fix this, we snapshot contents of the Modal before any of its contents are removed.

Reviewed By: shergin

Differential Revision: D23976244

fbshipit-source-id: 01c13b74e97f82816e8946fd9d1add1db10340b1

* Allow Java classes to hook into ScrollView scroll and layout events

Summary:
For advanced interop cases.

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D23984345

fbshipit-source-id: f5c2a43a1bf5937f9974bcc5c66c36ec35e679c5

* Remove unuse…
@sammy532
Copy link

I have this problem with react-native version 0.71.13

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. Merged This PR has been merged. Platform: iOS iOS applications.
Projects
None yet
Development

Successfully merging this pull request may close these issues.