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

feat: improve monorepo support by removing redundant PROJECT_ROOT #28354

Closed
wants to merge 1 commit into from

Conversation

grabbou
Copy link
Contributor

@grabbou grabbou commented Mar 20, 2020

Summary

Historically, React Native didn't support a lot of custom project structures apart from the standard flat directory with ios and android folders. The CLI had to be explicitly started from the project root, otherwise Metro didn't work right.

In order to resolve the project root in the most accurate way, React Native assumed that project root is always ../../ from its location in node_modules - this is not true when the installation gets hoisted (e.g. in a monorepo).

To address that, @janicduplessis brought support for custom PROJECT_ROOT that allowed overriding the ../../ in case it wasn't true.

Today, CLI is able to automatically resolve the project root, no matter where it's started. It will traverse the tree of the directories upwards and stop as soon as it meets package.json.

As a result, it doesn't really matter from where we start the CLI anymore as a part of react-native-xcode.sh.

By replacing the default value of $REACT_NATIVE_DIR/../../ with $PWD, that is default for all Xcode scripts, we can make the setup for monorepo easier - nobody will need to set $PROJECT_ROOT` in order to override the incorrect defaults.

By default, all scripts defined in Xcode run from $PWD directory, which is the location of the iOS project. In the future, we will be able to remove cd entirely.

To better understand this PR, let's look a few hypothetical structures as an example:

Monorepo:

tl;dr works out of the box, no need to mess around with paths

- package.json
- packages/
  - my-app/
     - index.js
     - package.json
     - ios/
        - MyApp.xcodeproj

Before this PR, the react-native-xcode.sh will start the CLI like this:

cd $REACT_NATIVE_DIR/../../
node <absolute_path_to_cli.js> bundle --entry-point index.js
  • Because we change the directory to the root of monorepo, CLI throws an error. All in all, there's no react-native dependency at the workspace root.

  • Some users turn no hoist in an act of troubleshooting the errors, which resolves the problem - react-native is moved under my-app/node_modules which makes this mechanism resolve properly.

  • Some users find out about PROJECT_ROOT and set it to overwrite the default value. For example, setting export PROJECT_ROOT = "$PWD/../ will set the directory to my-app, which has a dependency on react-native in a package.json and makes the CLI happy.

After this PR, the react-native-xcode.sh will start the CLI like this:

cd $PWD
node <absolute_path_to_cli.js> bundle --entry-point index.js
  • The $PWD is packages/my-app/ios/ because that's where the Xcode project is located. CLI will automatically set the root to ../ because that's where it finds package.json with react-native dependency. It will pass that root to Metro, unless users have set a different one themselves. Thanks to that, all paths to JavaScript files remain working and unaffected.

  • No need to set PROJECT_ROOT anymore.

  • We don't rely on the location of node_modules, which is cleaner and future proof.

Standard:

tl;dr no changes

- ios/
   - MyApp.xcodeproj
- index.js
- package.json

Before this PR, the react-native-xcode.sh will start the CLI like this:

cd $REACT_NATIVE_DIR/../../
node <absolute_path_to_cli.js> bundle --entry-point index.js
  • Everything works fine. Path from react-native inside node_modules is correct - the project root is set right to /

After this PR, the react-native-xcode.sh will start the CLI like this:

cd $PWD
node <absolute_path_to_cli.js> bundle --entry-point index.js
  • The root will be set to where Xcode project is located, which is /ios. This is the PWD for all Xcode scripts.

CLI will look for the package.json going upwards from ios folder. Will stop at /, find out it has react-native dependency, load it and its commands and proceed further.

Changelog

[iOS] [Feature] - Better monorepo support when building release apk

Test Plan

  • All projects (standard/monorepo) run without issues.
  • PROJECT_ROOT is not needed.

CC: @Titozzz (who wrote monorepo guide), @alloy, @bartolkaruza

@facebook-github-bot facebook-github-bot added CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. p: Callstack Partner: Callstack Partner labels Mar 20, 2020
# For new users, we default to $PWD - not changing things all.
#
# For context: https://github.com/facebook/react-native/commit/9ccde378b6e6379df61f9d968be6346ca6be7ead#commitcomment-37914902
PROJECT_ROOT=${PROJECT_ROOT:-$PWD}

cd "$PROJECT_ROOT" || exit
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I would remove this entirely, but I don't really want to run into all the users that have some crazy setup today. Historically, there was a lot of hacks around setting up monorepos and we're working with the CLI team to educate the developers that some of these are not needed anymore.

Copy link
Collaborator

@Titozzz Titozzz left a comment

Choose a reason for hiding this comment

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

Cool changes, less user pain is great

@alloy
Copy link
Contributor

alloy commented Mar 20, 2020

Nice one 👌

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.

@react-native-bot
Copy link
Collaborator

This pull request was successfully merged by @grabbou in a8e8502.

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 Mar 20, 2020
@hramos hramos deleted the grabbou-patch-1 branch March 24, 2020 18:40
musiquarc pushed a commit to musiquarc/react-native that referenced this pull request Jun 8, 2020
…cebook#28354)

Summary:
Historically, React Native didn't support a lot of custom project structures apart from the standard flat directory with `ios` and `android` folders. The CLI had to be explicitly started from the project root, otherwise Metro didn't work right.

In order to resolve the project root in the most accurate way, React Native assumed that project root is always `../../` from its location in `node_modules` - this is not true when the installation gets hoisted (e.g. in a monorepo).

To address that, janicduplessis brought support for custom [`PROJECT_ROOT`](facebook@9ccde37) that allowed overriding the `../../` in case it wasn't true.

Today, CLI is able to automatically resolve the project root, no matter where it's started. It will traverse the tree of the directories upwards and stop as soon as it meets `package.json`.

As a result, it doesn't really matter from where we start the CLI anymore as a part of `react-native-xcode.sh`.

By replacing the default value of `$REACT_NATIVE_DIR/../../` with `$PWD, that is default for all Xcode scripts, we can make the setup for monorepo easier - nobody will need to set `$PROJECT_ROOT` in order to override the incorrect defaults.

By default, all scripts defined in Xcode run from `$PWD` directory, which is the location of the iOS project. In the future, we will be able to remove `cd` entirely.

To better understand this PR, let's look a few hypothetical structures as an example:

#### Monorepo:

> tl;dr works out of the box, no need to mess around with paths

```
- package.json
- packages/
  - my-app/
     - index.js
     - package.json
     - ios/
        - MyApp.xcodeproj
```

**Before this PR**, the `react-native-xcode.sh` will start the CLI like this:

```bash
cd $REACT_NATIVE_DIR/../../
node <absolute_path_to_cli.js> bundle --entry-point index.js
```

- Because we change the directory to the root of monorepo, CLI throws an error. All in all, there's no `react-native` dependency at the workspace root.

- Some users turn `no hoist` in an act of troubleshooting the errors, which resolves the problem - `react-native` is moved under `my-app/node_modules` which makes this mechanism resolve properly.

- Some users find out about `PROJECT_ROOT` and set it to overwrite the default value. For example, setting `export PROJECT_ROOT = "$PWD/../` will set the directory to `my-app`, which has a dependency on `react-native` in a `package.json` and makes the CLI happy.

**After this PR**, the `react-native-xcode.sh` will start the CLI like this:

```bash
cd $PWD
node <absolute_path_to_cli.js> bundle --entry-point index.js
```

- The `$PWD` is `packages/my-app/ios/` because that's where the Xcode project is located. CLI will automatically set the root to `../` because that's where it finds `package.json` with `react-native` dependency. It will pass that root to Metro, unless users have set a different one themselves. Thanks to that, all paths to JavaScript files remain working and unaffected.

- No need to set `PROJECT_ROOT` anymore.

- We don't rely on the location of `node_modules`, which is cleaner and future proof.

#### Standard:

> tl;dr no changes

```
- ios/
   - MyApp.xcodeproj
- index.js
- package.json
```

**Before this PR**, the `react-native-xcode.sh` will start the CLI like this:

```bash
cd $REACT_NATIVE_DIR/../../
node <absolute_path_to_cli.js> bundle --entry-point index.js
```

- Everything works fine. Path from `react-native` inside `node_modules` is correct - the project root is set right to `/`

**After this PR**, the `react-native-xcode.sh` will start the CLI like this:

```bash
cd $PWD
node <absolute_path_to_cli.js> bundle --entry-point index.js
```

- The root will be set to where Xcode project is located, which is `/ios`. This is the PWD for all Xcode scripts.

CLI will look for the `package.json` going upwards from `ios` folder. Will stop at `/`, find out it has `react-native` dependency, load it and its commands and proceed further.

## Changelog

[iOS] [Feature] - Better monorepo support when building release apk
Pull Request resolved: facebook#28354

Test Plan:
- All projects (standard/monorepo) run without issues.
- PROJECT_ROOT is not needed.

CC: Titozzz (who wrote monorepo guide), alloy, bartolkaruza

Reviewed By: cpojer

Differential Revision: D20558005

Pulled By: hramos

fbshipit-source-id: 2551120beadcfd4c2f1393ce8a2c2fa6b93c9290
musiquarc pushed a commit to musiquarc/react-native that referenced this pull request Jun 8, 2020
…cebook#28354)

Summary:
Historically, React Native didn't support a lot of custom project structures apart from the standard flat directory with `ios` and `android` folders. The CLI had to be explicitly started from the project root, otherwise Metro didn't work right.

In order to resolve the project root in the most accurate way, React Native assumed that project root is always `../../` from its location in `node_modules` - this is not true when the installation gets hoisted (e.g. in a monorepo).

To address that, janicduplessis brought support for custom [`PROJECT_ROOT`](facebook@9ccde37) that allowed overriding the `../../` in case it wasn't true.

Today, CLI is able to automatically resolve the project root, no matter where it's started. It will traverse the tree of the directories upwards and stop as soon as it meets `package.json`.

As a result, it doesn't really matter from where we start the CLI anymore as a part of `react-native-xcode.sh`.

By replacing the default value of `$REACT_NATIVE_DIR/../../` with `$PWD, that is default for all Xcode scripts, we can make the setup for monorepo easier - nobody will need to set `$PROJECT_ROOT` in order to override the incorrect defaults.

By default, all scripts defined in Xcode run from `$PWD` directory, which is the location of the iOS project. In the future, we will be able to remove `cd` entirely.

To better understand this PR, let's look a few hypothetical structures as an example:

#### Monorepo:

> tl;dr works out of the box, no need to mess around with paths

```
- package.json
- packages/
  - my-app/
     - index.js
     - package.json
     - ios/
        - MyApp.xcodeproj
```

**Before this PR**, the `react-native-xcode.sh` will start the CLI like this:

```bash
cd $REACT_NATIVE_DIR/../../
node <absolute_path_to_cli.js> bundle --entry-point index.js
```

- Because we change the directory to the root of monorepo, CLI throws an error. All in all, there's no `react-native` dependency at the workspace root.

- Some users turn `no hoist` in an act of troubleshooting the errors, which resolves the problem - `react-native` is moved under `my-app/node_modules` which makes this mechanism resolve properly.

- Some users find out about `PROJECT_ROOT` and set it to overwrite the default value. For example, setting `export PROJECT_ROOT = "$PWD/../` will set the directory to `my-app`, which has a dependency on `react-native` in a `package.json` and makes the CLI happy.

**After this PR**, the `react-native-xcode.sh` will start the CLI like this:

```bash
cd $PWD
node <absolute_path_to_cli.js> bundle --entry-point index.js
```

- The `$PWD` is `packages/my-app/ios/` because that's where the Xcode project is located. CLI will automatically set the root to `../` because that's where it finds `package.json` with `react-native` dependency. It will pass that root to Metro, unless users have set a different one themselves. Thanks to that, all paths to JavaScript files remain working and unaffected.

- No need to set `PROJECT_ROOT` anymore.

- We don't rely on the location of `node_modules`, which is cleaner and future proof.

#### Standard:

> tl;dr no changes

```
- ios/
   - MyApp.xcodeproj
- index.js
- package.json
```

**Before this PR**, the `react-native-xcode.sh` will start the CLI like this:

```bash
cd $REACT_NATIVE_DIR/../../
node <absolute_path_to_cli.js> bundle --entry-point index.js
```

- Everything works fine. Path from `react-native` inside `node_modules` is correct - the project root is set right to `/`

**After this PR**, the `react-native-xcode.sh` will start the CLI like this:

```bash
cd $PWD
node <absolute_path_to_cli.js> bundle --entry-point index.js
```

- The root will be set to where Xcode project is located, which is `/ios`. This is the PWD for all Xcode scripts.

CLI will look for the `package.json` going upwards from `ios` folder. Will stop at `/`, find out it has `react-native` dependency, load it and its commands and proceed further.

## Changelog

[iOS] [Feature] - Better monorepo support when building release apk
Pull Request resolved: facebook#28354

Test Plan:
- All projects (standard/monorepo) run without issues.
- PROJECT_ROOT is not needed.

CC: Titozzz (who wrote monorepo guide), alloy, bartolkaruza

Reviewed By: cpojer

Differential Revision: D20558005

Pulled By: hramos

fbshipit-source-id: 2551120beadcfd4c2f1393ce8a2c2fa6b93c9290
makarkotlov pushed a commit to makarkotlov/react-native that referenced this pull request Jul 23, 2020
# For new users, we default to $PWD - not changing things all.
#
# For context: https://github.com/facebook/react-native/commit/9ccde378b6e6379df61f9d968be6346ca6be7ead#commitcomment-37914902
PROJECT_ROOT=${PROJECT_ROOT:-$PWD}
Copy link
Contributor

Choose a reason for hiding this comment

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

I know this PR is old, but I believe we have a bug here. If $PWD is going to be the ios folder when this script is invoked from Xcode, then this line should be

PROJECT_ROOT=${PROJECT_ROOT:-$PWD/..}

cc @grabbou

Copy link
Contributor

Choose a reason for hiding this comment

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

@stigi would you mind opening a PR agains the main repo with the one line change you propose there? Once it's up it'd be way easier to test it & then have the fix you are proposing available for everyone :)

Copy link
Contributor

Choose a reason for hiding this comment

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

@kelset I was to quick to shoot. There's already a PR that is discussing the issue. It's not only PROJECT_ROOT that's broken, but also REACT_NATIVE_DIR. I left my comments in the PR #29477 (comment)

@KingAmo
Copy link

KingAmo commented Aug 25, 2020

is there a guide on how to use monorepo with this pr ?

grabbou added a commit to callstack/react-native that referenced this pull request Sep 17, 2020
facebook-github-bot pushed a commit that referenced this pull request Sep 22, 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
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
alloy added a commit to microsoft/react-native-macos that referenced this pull request Sep 30, 2020
* Upgrade to Metro 0.59

Summary:
Upgrades RN to Metro 0.59.

Changelog: [Internal] Metro Upgrade

Reviewed By: motiz88

Differential Revision: D20533864

fbshipit-source-id: 3c5fb8e37d2363edf0b9a1a8cfbdefba00763415

* Fix mock for TextInput (#28332)

Summary:
This PR adds the `isFocused` method to the mock of the TextInput component. My understanding some of the latest changes on the TextInput to make it use a forwardRef change the way this method is mock giving an error when trying to use in on a mock.
The change suggested here fixes the issue.

## Changelog

[JavaScript] [Fixed] - Fix the mock for TextInput to support the `isFocused` method
Pull Request resolved: https://github.com/facebook/react-native/pull/28332

Reviewed By: cpojer

Differential Revision: D20538044

Pulled By: TheSavior

fbshipit-source-id: be734af105ab62ffdf9ed4017bd70845e207f8cd

* Properly handle LogBox errors during tests

Summary:
This diff fixes an issue where errors in LogBox during tests would cause the tests to crash.

The crash is due to the NativeExceptionsManager module not being mocked (as all native module need to be in tests). The fix is to properly mock the NativeExceptionManger.

This fix exposed an infinite loop issue where failures in LogBox will be logged to the ExceptionManager, which logs to the console, which logs to LogBox, creating a loop. This diff also fixes that look by moving the LogBox internal error check to the top of the monkey patched console methods.

Changelog: [Internal]

Differential Revision: D20428590

fbshipit-source-id: 7289a480c99ba8dee67772178b7629afb40b330a

* Back out "Track animations and flush them"

Summary:
Original commit changeset: b594d0e6e9b6

D20319824 introduced a problem in LayoutAnimations, which makes surfaced as the problem in T63911344. This diff reverts D20319824.

Changelog: [Internal]

Reviewed By: lunaleaps

Differential Revision: D20541918

fbshipit-source-id: ff72b839f57d39051122920a38b2632cbb5ec362

* Consolidate "dispatchMountItems" reentrancy prevention code, and retry code, in one function

Summary:
Simplifying the dispatchMountItems reentrance and retry logic.

Motivation: cleanup so I can work on dispatching ViewCommands before anything else.

Importantly, this gives us the properties that:
1) Only one function is responsible for calling dispatchMountItems
2) Only one function is responsible for deciding if we shouldn't call dispatchMountItems due to reentrance
3) Only one function is responsible for all cleanup
4) Only one function maintains all of the relevant flags (except dispatchPreMountItems... two total now, instead of 4 before)

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D20437035

fbshipit-source-id: 5370366790eb25f653bee6c1950e747458374a61

* Only retry ViewCommand mount items if exception is marked as "Retryable"

Summary:
Instead of just blindly retrying all ViewCommands if they fail - which could be dangerous, since it's arbitrary imperative commands we'd be executing twice, potentially with bad app state - we only retry if the ViewCommand throws a "RetryableMountingLayerException".

Changelog: [Internal] Optimization to ViewCommands

Reviewed By: mdvacca

Differential Revision: D20529985

fbshipit-source-id: 0217b43f4bf92442bcc7ca48c8ae2b9a9e543dc9

* Introduce early dispatch of ViewCommands in FabricUIManager

Summary:
Earlier this week I introduced a change in the old, non-Fabric renderer (D20378633 D20427803) that (gated behind a feature-flag) executes ViewCommands before all other types of commands, as a perf optimization and (I think) a potential fix for a category of race conditions.

I've added more details in comments here.

The Fabric renderer uses the same feature-flag that I introduced for the non-Fabric renderer.

Changelog: [Internal] Fabric

Reviewed By: mdvacca

Differential Revision: D20449186

fbshipit-source-id: bb3649f565f32c417a6247369902333989a043aa

* Change nightly build from hourly to nightly (daily at 00:00) (#28346)

Summary:
We initially added the nightly build test to run every hour, in order to more quickly validate it. Now that it has been validated we can run it every night as it is intended to do.

cc hramos

## Changelog

[General] [Changed] - Change nightly build from hourly to nightly
Pull Request resolved: https://github.com/facebook/react-native/pull/28346

Reviewed By: cpojer

Differential Revision: D20550143

Pulled By: hramos

fbshipit-source-id: 9487c6785684ad6ea7e877290d50a33118090a7f

* Add diffing to app bundle size reports (#28284)

Summary:
Add diffing to app bundle size reports.

## Changelog

[Internal] [Changed] - Add diffing to app bundle size reports

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

Test Plan:
- App bundle size reports should now display a diff where available
  - Right now, the database contains only one entry for the last known good iOS build
- Triggering a new build should not create additional comments

Reviewed By: cpojer

Differential Revision: D20450158

Pulled By: hramos

fbshipit-source-id: 720772275f24d3ff0a49705f4dada2efe2e99bd3

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

Summary:
Historically, React Native didn't support a lot of custom project structures apart from the standard flat directory with `ios` and `android` folders. The CLI had to be explicitly started from the project root, otherwise Metro didn't work right.

In order to resolve the project root in the most accurate way, React Native assumed that project root is always `../../` from its location in `node_modules` - this is not true when the installation gets hoisted (e.g. in a monorepo).

To address that, janicduplessis brought support for custom [`PROJECT_ROOT`](https://github.com/facebook/react-native/commit/9ccde378b6e6379df61f9d968be6346ca6be7ead) that allowed overriding the `../../` in case it wasn't true.

Today, CLI is able to automatically resolve the project root, no matter where it's started. It will traverse the tree of the directories upwards and stop as soon as it meets `package.json`.

As a result, it doesn't really matter from where we start the CLI anymore as a part of `react-native-xcode.sh`.

By replacing the default value of `$REACT_NATIVE_DIR/../../` with `$PWD, that is default for all Xcode scripts, we can make the setup for monorepo easier - nobody will need to set `$PROJECT_ROOT` in order to override the incorrect defaults.

By default, all scripts defined in Xcode run from `$PWD` directory, which is the location of the iOS project. In the future, we will be able to remove `cd` entirely.

To better understand this PR, let's look a few hypothetical structures as an example:

#### Monorepo:

> tl;dr works out of the box, no need to mess around with paths

```
- package.json
- packages/
  - my-app/
     - index.js
     - package.json
     - ios/
        - MyApp.xcodeproj
```

**Before this PR**, the `react-native-xcode.sh` will start the CLI like this:

```bash
cd $REACT_NATIVE_DIR/../../
node <absolute_path_to_cli.js> bundle --entry-point index.js
```

- Because we change the directory to the root of monorepo, CLI throws an error. All in all, there's no `react-native` dependency at the workspace root.

- Some users turn `no hoist` in an act of troubleshooting the errors, which resolves the problem - `react-native` is moved under `my-app/node_modules` which makes this mechanism resolve properly.

- Some users find out about `PROJECT_ROOT` and set it to overwrite the default value. For example, setting `export PROJECT_ROOT = "$PWD/../` will set the directory to `my-app`, which has a dependency on `react-native` in a `package.json` and makes the CLI happy.

**After this PR**, the `react-native-xcode.sh` will start the CLI like this:

```bash
cd $PWD
node <absolute_path_to_cli.js> bundle --entry-point index.js
```

- The `$PWD` is `packages/my-app/ios/` because that's where the Xcode project is located. CLI will automatically set the root to `../` because that's where it finds `package.json` with `react-native` dependency. It will pass that root to Metro, unless users have set a different one themselves. Thanks to that, all paths to JavaScript files remain working and unaffected.

- No need to set `PROJECT_ROOT` anymore.

- We don't rely on the location of `node_modules`, which is cleaner and future proof.

#### Standard:

> tl;dr no changes

```
- ios/
   - MyApp.xcodeproj
- index.js
- package.json
```

**Before this PR**, the `react-native-xcode.sh` will start the CLI like this:

```bash
cd $REACT_NATIVE_DIR/../../
node <absolute_path_to_cli.js> bundle --entry-point index.js
```

- Everything works fine. Path from `react-native` inside `node_modules` is correct - the project root is set right to `/`

**After this PR**, the `react-native-xcode.sh` will start the CLI like this:

```bash
cd $PWD
node <absolute_path_to_cli.js> bundle --entry-point index.js
```

- The root will be set to where Xcode project is located, which is `/ios`. This is the PWD for all Xcode scripts.

CLI will look for the `package.json` going upwards from `ios` folder. Will stop at `/`, find out it has `react-native` dependency, load it and its commands and proceed further.

## Changelog

[iOS] [Feature] - Better monorepo support when building release apk
Pull Request resolved: https://github.com/facebook/react-native/pull/28354

Test Plan:
- All projects (standard/monorepo) run without issues.
- PROJECT_ROOT is not needed.

CC: Titozzz (who wrote monorepo guide), alloy, bartolkaruza

Reviewed By: cpojer

Differential Revision: D20558005

Pulled By: hramos

fbshipit-source-id: 2551120beadcfd4c2f1393ce8a2c2fa6b93c9290

* Fix `test_android`: Remove references to fbsource cell (#28363)

Summary:
Fixes https://github.com/facebook/react-native/issues/28361.

## Changelog

[Internal] [CI] - Fix test_android
Pull Request resolved: https://github.com/facebook/react-native/pull/28363

Test Plan:
Prior to fix:

```
react-native $ ./scripts/circleci/buck_fetch.sh
Guessing 168a69309928ba16065cdb33b1775a4af9f924a6 as the last one used version.
Using additional configuration options from /Users/hramos/.buckconfig.d/experiments, /etc/buckconfig.d/fb_chef.ini, /etc/buckconfig.d/fb_chef_override.ini
Invalidating internal cached state: Watchman failed to start. This may cause slower builds.
Parsing buck files: finished in 1.5 sec
Buck wasn't able to parse /Users/hramos/git/react-native/ReactAndroid/src/main/java/com/facebook/fbreact/specs/BUCK:
IOError: [Errno 2] No such file or directory: '/Users/hramos/git/react-native/tools/build_defs/platform_defs.bzl'
Call stack:
  File "/Users/hramos/git/react-native/.buckd/resources/168a69309928ba16065cdb33b1775a4af9f924a6/buck_server/buck_parser/profiler.py", line 507, in wrapped
    return func(*args, **kwargs)
  File "/Users/hramos/git/react-native/ReactAndroid/src/main/java/com/facebook/fbreact/specs/BUCK", line 1
    load("//tools/build_defs:platform_defs.bzl", "ANDROID")
  File "/Users/hramos/git/react-native/.buckd/resources/168a69309928ba16065cdb33b1775a4af9f924a6/buck_server/buck_parser/profiler.py", line 507, in wrapped
    return func(*args, **kwargs)

This error happened while trying to get dependency '//ReactAndroid/src/main/java/com/facebook/fbreact/specs:FBReactNativeSpec' of target '//ReactAndroid/src/main/java/com/facebook/react/devsupport:devsupport'
```
After fix:

```
react-native $ ./scripts/circleci/buck_fetch.sh
+ buck fetch ReactAndroid/src/test/java/com/facebook/react/modules
Guessing 168a69309928ba16065cdb33b1775a4af9f924a6 as the last one used version.
Using additional configuration options from /Users/hramos/.buckconfig.d/experiments, /etc/buckconfig.d/fb_chef.ini, /etc/buckconfig.d/fb_chef_override.ini
Invalidating internal cached state: Watchman failed to start. This may cause slower builds.
Parsing buck files: finished in 1.1 sec
Configuration 'ANDROID_SDK' points to an invalid directory '/opt/android_sdk'.
    When creating rule //ReactAndroid/src/main/java/com/facebook/hermes/instrumentation:instrumentation.
```

> Note: I don't have the Android SDK configured in this machine.

Verified on Circle CI. `test_android` is now green: https://circleci.com/gh/facebook/react-native/140682?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link

Reviewed By: cpojer

Differential Revision: D20564934

Pulled By: hramos

fbshipit-source-id: 5d843b8f113c4db5391ee39addc3ff259d962290

* Fix TextInput left/right padding

Summary:
This fixes two things:

1) Currently it only respects Start and End padding, and if there's a Theme default, it will override Left/Right padding. Whoops.
2) Currently it doesn't respect when a TextInput starts with padding, but then is removed.

This resolves both.

It still does not account for RTL support.

Changelog: [Internal] Fix AndroidTextInput padding

Reviewed By: mdvacca

Differential Revision: D20573151

fbshipit-source-id: e89791641b6699e728cde9dbd661a8c21485fbc8

* Validate selection range passed to setTextAndSelection

Summary:
Changelog: [Internal]

# Fabric

1. If `start` and `end` parameters in `setTextAndSelection` are -1, we don't move the cursor. Previously the cursor would be moved to beginning of text input.

2. In view commands, do not validate `eventCount`. It is passed in as undefined from JS because Fabric's text input doesn't use `eventCount`.

# Paper

1. If `start` and `end` parameters in `setTextAndSelection` are -1, we don't move the cursor. Previously the cursor would be moved to beginning of text input.

Reviewed By: shergin

Differential Revision: D20538290

fbshipit-source-id: c7aeddc25f58697254474058ce901df958321f7c

* Remove ReactTypes from fbsource and React sync

Summary:
See https://github.com/facebook/react/pull/18366

This contains a fork of the upstream Flow types. We shouldn't be syncing this since these leads to conflicting types.

As a result, these uses have already been codemodded away. Only the imports remained.

Changelog:

[React Core] - Remove ReactTypes from sync.

Reviewed By: gaearon

Differential Revision: D20583740

fbshipit-source-id: fc86a934cbdca8ff90fe90282b86ecc945a85e5f

* Fix controlled TextInput with child nodes

Summary:
Changelog: [Internal]

# There are three changes in this diff

## _stateRevision is replaced with a BOOL
`_stateRevision` was protecting against setting attributed string that is already visible to the user. Previously this was ok because the change was only coming from native, any changes from JS were ignored.

Imagine following scenario:

1. User taps key.
2. Update state is called on component initiated by native.
3. New state is created with incremented revision by one.
4. `_stateRevision` gets set to new state's revision + 1.
5. Now JS wants to change something because it just learnt that user tapped the key.
6. New state is created again with incremented revision by one.
7. Update state is called on the component, but the change isn't applied to the text view because `_state->getRevision()` will equal `_stateRevision`.

By having a BOOL instead of number, we very explicitly mark the region in which we don't want state changes to be applied to text view.

## Calling [_backedTextInputView setAttributedText] move cursor to the end of text input
This is prevented by storing what the current selection is and applying it after `[_backedTextInputView setAttributedText]` is called.
This was previously invisible because JS wasn't changing contents of `_backedTextInputView`.

## Storing of previously applied JS attributed string in state

This is the mechanism used to detect when value of text input changes come from JavaScript. JavaScript sends text input value changes through props and as children of TextInput.
We compare what previously was set from JavaScript to what is currently being send from JavaScript and if they differ, this change is communicated to the component.
Previously only first attributed string send from JavaScript was send to the component.

# Problem

If children are used to set text input's value, then there is a case in which we can't tell what source of truth should be.

Let's take following example
We have a text field that allows only 4 characters, again this is only a problem if those 4 characters come as children, not as value.
This is a controller text input.

1. User types 1234.
2. User types 5th character.
3. JavaScript updates TextInput, saying that the content should stay 1234.
4. In `TextInputShadowNode` `hasJSUpdatedAttributedString` will be set to false, because previous JS value is the same as current JS value.

Reviewed By: shergin

Differential Revision: D20587681

fbshipit-source-id: 1b8a2efabbfa0fc87cba210570142d162efe61e6

* Daily `arc lint --take BUCKFORMAT`

Reviewed By: zertosh

Differential Revision: D20593906

fbshipit-source-id: b056947c698508119dc9d4d1bba202295b8f0fda

* RN picker - implement background color

Summary:
add support to the android implementation of the Picker component for setting the background color.

Changelog: [Android] [Added] - Support item background color in Dialog Picker

Differential Revision: D20566131

fbshipit-source-id: d693b40803fa1051ec955c5728994c820fecd9e9

* Fabric: Modernizing Yoga Dirty flag test.

Summary:
Now we using TEST_F thing that allows consilidating initialization.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: mdvacca

Differential Revision: D20578788

fbshipit-source-id: 103bcb8fdeb3dbf297385cfe56415bd646e16791

* Fabric: Changing signature of `ComponentDescriptor::createState`

Summary:
This is pure syntactic change. Often we don't have a shared pointer to ShadowNodeFamily and only have just a reference. At the same time, `ComponentDescriptor::createState` does not have to accept a shared pointer. So, it's better to accept just a reference.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: sammy-SC

Differential Revision: D20578787

fbshipit-source-id: 905277001e096d41e75007575b59ea2ea15fbf4b

* Fabric: View Test: Changing state should not dirty Yoga tree (in some most cases)

Summary: Changelog: [Internal] Fabric-specific internal change.

Reviewed By: mdvacca

Differential Revision: D20578789

fbshipit-source-id: 4336165217bd39fc8065cfaeb96ef7753433d48a

* Get ReactiveNative compiled with Clang 10 (#28362)

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

Fixed a few compilation errors emitted by Clang 10.

Changelog:
[iOS] [Fixed] - Get ready for Clang 10

Differential Revision: D20549970

fbshipit-source-id: dc36a85d90d3e43a05f045feb57c6ab6ded67da7

* Guard against null values in object parameters for bridged methods

Summary:
Handles the case when a value in an object parameter of a turbo module spec is null (even if the type is nullable).

For example, given:
```
export interface Spec extends TurboModule {
  +myFunc: ({|
    foo: ?string,
  |}) => void;
}
```
and calling `NativeModule.myFunc({foo: null})`, we see an error like:
```
JSON value '<null>' of type NSNull cannot be converted to NSString
```
Guarding against this by converting NSNull's to nils

## Changelog:

[iOS] [Fixed] - Fix crash when passing null value in object parameter of bridged method

Reviewed By: fkgozali

Differential Revision: D20591590

fbshipit-source-id: fdb90f34131427a235f2e3c99147bf1e6a9c6732

* Modify pending deletion tags to be cross manageChildren

Summary:
Changelog: [Internal]

Removing historic layout animations index adjustment (D20323928) broke the Dating Secret Crush screen.

Since flushing animations (D20319824) had to be reverted due to issues with Saved + Privacy Shortcuts (https://fburl.com/tasks/eijtmifu) we need to track pending deletions across `manageChildren` operations.

Reviewed By: JoshuaGross

Differential Revision: D20601079

fbshipit-source-id: c6f116683750e97abe7f988cf361d2a6449e90e6

* Enable label-actions on the react-native repository (#28374)

Summary:
Enhance our issue management workflow by having the bot respond automatically whenever a label is applied to the issue.

## Changelog

[Internal] - CI
Pull Request resolved: https://github.com/facebook/react-native/pull/28374

Test Plan: Not tested. If needed, could be applied to a different, test repository.

Reviewed By: cpojer

Differential Revision: D20606887

Pulled By: hramos

fbshipit-source-id: 874d1464527ea76bf51394a7d3e98e4fd8f69345

* Fix Animated Value initialized with undefined in ScrollView (#28349)

Summary:
When passing an object to contentOffset that doesn't have `y` prop set it causes the following error:

```
 Error: AnimatedValue: Attempting to set value to undefined

This error is located at:
    in ScrollView (at src/index.js:638)
...
```

This happens since a runtime check was added to the `AnimatedValue` constructor. (a3aaa471eca58b31597b9a0669f7ade385ccb175)

According to flow types the object passed to contentOffset should always contain both x and y props but since it worked before when y is undefined I think its fine to patch the runtime behaviour defensively, especially since the code change is simple.

## Changelog

[General] [Fixed] - Fix Animated Value initialized with undefined in ScrollView
Pull Request resolved: https://github.com/facebook/react-native/pull/28349

Test Plan: Tested that the crash no longer reproduces when passing an empty object to contentOffset.

Reviewed By: cpojer

Differential Revision: D20601664

Pulled By: hramos

fbshipit-source-id: b098a2dd1e702f995a9a92fa6e4e9a204187dac4

* xplat/js/react-native-github/ReactCommon/fabric/components/textinput/

Summary: Changelog: [Internal]

Reviewed By: scottrice

Differential Revision: D20619227

fbshipit-source-id: 674337e6ce585a4e96d020f9624b874ba86e2d80

* Seed ssh known hosts with github's public key (#28370)

Summary:
The [previous attempt](https://github.com/facebook/react-native/pull/28304) to fix the publish step failed, so now reverting to manually configuring things. This PR adds an entry to SSH’s `known_hosts` file using github.com’s public key that I have verified as per [these instructions](https://serverfault.com/a/807363):

```
~/C/R/react-native [master] » nmap github.com --script ssh-hostkey
Nmap scan report for github.com (140.82.118.4)
rDNS record for 140.82.118.4: lb-140-82-118-4-ams.github.com
PORT     STATE SERVICE
22/tcp   open  ssh
| ssh-hostkey:
|   1024 ad:1c:08:a4:40:e3:6f:9c:f5:66:26:5d:4b:33:5d:8c (DSA)
|_  2048 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48 (RSA)
```

These fingerprints line up with [the ones posted by GitHub](https://help.github.com/en/github/authenticating-to-github/githubs-ssh-key-fingerprints), so my setup should be good and can be trusted to grab the public key from the right host:

```
~/C/R/react-native [master] » ssh-keyscan -t rsa -H github.com
# github.com:22 SSH-2.0-babeld-d48c3acd
|1|If6MU203eXTaaWL678YEfWkVMrw=|kqLeIAyTy8pzpj8x8Ae4Fr8Mtlc= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==
```

## Changelog

[Internal] [Fixed] - Make automated publishing of packages from CI work again
Pull Request resolved: https://github.com/facebook/react-native/pull/28370

Test Plan: I used the command being added in this PR in [a failed CI job](https://app.circleci.com/pipelines/github/facebook/react-native/4104/workflows/916127cb-177f-4583-9f90-cae5318041d8/jobs/140810). When I invoked the publish script manually I was not greeted by the blocking prompt and the package was successfully published: https://www.npmjs.com/package/react-native/v/0.0.0-56cf99a96

Reviewed By: cpojer

Differential Revision: D20601527

Pulled By: hramos

fbshipit-source-id: b1a4405228408cfc4a1b3b44ab88c79522af3a66

* Fix app bundle size diff not always being compared against latest commit (#28368)

Summary:
- Timestamp of entries in our Firebase instance sometimes get stored as number. This means that we may not always be diffing against the latest master commit.
- Size report of Android and iOS gets overwritten depending on which build finishes first.

## Changelog

[Internal] [Fixed] - App bundle size diff not always being compared against latest commit
[Internal] [Fixed] - Android and iOS app bundle size diff overwrite each other
Pull Request resolved: https://github.com/facebook/react-native/pull/28368

Test Plan:
- We are now using Firebase's own [firebase.firestore.Timestamp.now](https://firebase.google.com/docs/reference/js/firebase.firestore.Timestamp#now) to ensure that we always get a timestamp in the preferred format. This has been tested locally but can only be verified when merged to master and we start getting new data. In the meantime, I'll manually fix up all the entries in the store.
- There should be one app bundle size comment for Android and one for iOS in this PR.

Reviewed By: cpojer

Differential Revision: D20601620

Pulled By: hramos

fbshipit-source-id: 0c3e4b78a74cbd659f1957a6aa74322b016e0646

* Hopefully fix so loading crashes

Summary:
Changelog:

[Android][Internal] Fix potential initializer interruption threading crashes.

Reviewed By: mdvacca

Differential Revision: D20615755

fbshipit-source-id: 58b706deeb6df1998caff5bf2ae9ec60114313fe

* Fix label-actions configuration

Summary:
Adds back a missing label key, fixes open source issue: https://github.com/facebook/react-native/issues/28378

Changelog:
[Internal] [CI] - Fix label-actions config

Reviewed By: cpojer

Differential Revision: D20625887

fbshipit-source-id: 63c90db249aa9c15369a4b5bcab71cbe75c6d4b8

* Changing Order Of mOverrideColorScheme In Constructor

Summary:
Changelog: [Android] [Updated]

mOverrideColorScheme should be assigned before the first colorSchemeForCurrentConfiguration call, so the initial setting of mColorScheme will reflect the override

Reviewed By: zackargyle

Differential Revision: D20630173

fbshipit-source-id: a2a2d174d3fc40c14f27dce6a7fa8e67203480c9

* hermes | inspector | Don't include posix headers on non-posix systems

Summary:
Changelog: [Internal]

Hermes inspector includes pthreads, arpa and sys headers on all OSes that would break vanilla Windows builds. This diff adds a check for posix-compliance before inclusion

(Note: this ignores all push blocking failures!)

Reviewed By: dulinriley

Differential Revision: D20564449

fbshipit-source-id: 8e264bc3104065dc4315bb291e8560609fe65184

* Upgrade Prettier from 1.17 to 2.0.2.

Summary:
This gets us on the latest Prettier 2.x:
https://prettier.io/blog/2020/03/21/2.0.0.html

Notably, this adds support for TypeScript 3.8,
which introduces new syntax, such as `import type`.

Reviewed By: zertosh

Differential Revision: D20636268

fbshipit-source-id: fca5833d003804333a05ba16325bbbe0e06d6c8a

* Back out "Upgrade Prettier from 1.17 to 2.0.2."

Differential Revision: D20639755

fbshipit-source-id: 5028563f9cf0527a30b4259daac50cdc03934bfd

* Fabric: Additional temporary checks in prop parsing infra

Summary:
While ViewConfig infra isn't perfect we need to check some value for correctness during prop-parsing.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: JoshuaGross

Differential Revision: D20639055

fbshipit-source-id: 193dcd0769bc7777bc8d60c964ede72ebdaa83e4

* Update React package

Summary:
This just updates the `react` package to the latest stable version. We updated it to experimental internally earlier so this brings the open source version to the latest before the branch cut. This doesn't include any breaking changes.

Changelog:

[General][Changed] - Update to React 16.13.1

Reviewed By: cpojer

Differential Revision: D20642909

fbshipit-source-id: 68a4c74bfe72f1abdb33b0b9071a4f4e8e568318

* Fix sketchy null checks induced by new formatting in Prettier 2.0

Summary:
Update code to prepare for Prettier 2.0, which will
reformat `a || (b || c)` to `a || b || c`.

Changelog: [Internal] prepare for Prettier 2.0

Reviewed By: kassens

Differential Revision: D20639483

fbshipit-source-id: c2932b1495884684172ba9291d56c546f51711b8

* RN picker - fix types in AndroidDialogPickerManagerInterface

Summary:
according to [this crash report](https://our.intern.facebook.com/intern/logview/details/facebook_android_crashes/7ba7056481015482c6166d65cb97e49d/?trace_key=1506fe36a70dd5e50cdc8968f6317f27), `value` was throwing an NPE despite being null-checked. this is because it was an `int` rather than an `Integer`, so the null check wasn't working

Changelog: Fix types in AndroidDialogPickerManagerInterface

Reviewed By: mdvacca

Differential Revision: D20646343

fbshipit-source-id: a27587e0a48f5782bcf5ffddb604018218e65206

* Remove RCTExportModule log spam

Summary:
The bridge complains if modules aren't exported, which isn't really helpful with lazily loaded modules and turbo modules.

I considered only turning this off when TurboModules is enabled, but figured we'd be killing this soon anyways... If anyone feels strongly I can go that approach.

Changelog: [iOS][Internal] Remove RCTExportModule log spam

Reviewed By: shergin

Differential Revision: D20629575

fbshipit-source-id: d32d9fe244c4d06acfee982fca7c7f63da294dc5

* De-jank DevLoadingView

Summary:
## Problems
Repro steps:
1. Disable Fabric (because CMD + R doesn't work with Fabric right now).
2. Open up Marketplace and hit `CMD + OPT + R`
3. **Observe:** The progress bar doesn't show up right away. It also doesn't actually show progress.
https://pxl.cl/140g1

RN Support post: https://fb.workplace.com/groups/rn.support/permalink/3437652016283389/

## Fixes
The first problem is that progress bar doesn't actually show progress.

**Fix:** Bundle load progress is updated in `RCTCxxBridge`, where we first require `RCTDevLoadingView`, and then call its `updateProgress` method. Previously, we wouldn't  lazily load `RCTDevLoadingView`, it already didn't exist. Lazily loading `RCTDevLoadingView` causes the progress view to show up. Here: https://pxl.cl/140gt

If you look at the above video, you'll notice there are two stages to the progress bar: stage 1 displays the actual progress. Stage 2 prompts that we're downloading the JS bundle. As you can see, stage 1 and stage 2 have different background colors, even though both of them are green.

**Fix:** I adjusted the JS to match the Native color. Here: https://pxl.cl/140gT

We're almost there, but the progress bar is dismissed twice?

**Fix:** I dug into the code, and the reason why was because when we hit `CMD + R`, we invalidate the bridge, and immediately re-initialize it. This means that we asynchronously invalidate the old TurboModuleManager, and immediately create a brand new one. Therefore, two `RCTDevLoadingView` modules can (and do) exist at once. So, I moved `RCTDevLoadingView` to be an instance member of `FBReactModule`, to ensure that it doesn't get cleaned up and re-created when TurboModuleManager is deleted and re-created. This finally fixed the progress bar jank:
https://pxl.cl/140hn

Changelog:
[iOS][Fixed] - Remove RCTDevLoadingView jank

Reviewed By: rickhanlonii

Differential Revision: D20607815

fbshipit-source-id: 05825c67adaf3cfda70be0fa2dc92d413dc8921b

* Fix retaining self in block in LogBox impl

Summary:
Logbox has a retain cycle (see linked task for my deeper investigation).

This diff doesn't fix the retain cycle, but it's just good practice to not retain self strongly in blocks.

Changelog: [iOS][Internal] Fix retaining self in block in LogBox implementation

Reviewed By: shergin

Differential Revision: D20630693

fbshipit-source-id: cf399495e9bcd1917932fcc0e9c9d2d2a32bf6f0

* Flow type infoLog

Summary:
Changelog:
[General][Internal] flow type infoLog

Reviewed By: zackargyle

Differential Revision: D20577939

fbshipit-source-id: eed4401b2ae0a6bf845fdcb54c6abe1fe98fe7c1

* Replace fbsource// with // in xplat/js/ files [1]

Summary:
`fbsource//xplat` and `//xplat` are equivalent for FB BUCK targets. Removing extra prefix for consistency.

Changelog: [Internal]

Reviewed By: scottrice

Differential Revision: D20495655

fbshipit-source-id: a57b72f694c533e2e16dffe74eccb8fdec1f55f5

* Deploy Flow 0.121 to Xplat (#901)

Summary:
Deploy Flow 0.121 to Xplat

bypass-lint
allow-large-files

Closes https://github.com/facebook/flipper/pull/901

Changelog: [Internal]

Reviewed By: panagosg7

Differential Revision: D20570316

fbshipit-source-id: a76983d6f46c8b995ce2dd5cd1e014534790698a

* Replace fbsource// with // in xplat/js/ files [3]

Summary:
`fbsource//xplat` and `//xplat` are equivalent for FB BUCK targets. Removing extra prefix for consistency.

Changelog: [Internal]

Reviewed By: JoshuaGross

Differential Revision: D20656211

fbshipit-source-id: deb91b917d349bc500acbb03d734ff621f6e1fc7

* Replace fbsource// with // in xplat/js/ files [4]

Summary:
`fbsource//xplat` and `//xplat` are equivalent for FB BUCK targets. Removing extra prefix for consistency.

Changelog: [Internal]

Reviewed By: JoshuaGross, shergin

Differential Revision: D20656696

fbshipit-source-id: 10f02decb1dc969fd3491ac90d97f09e2bda59e7

* Add Needs: Repro bot action (#28397)

Summary:
Add automated response for Needs: Repro

## Changelog

[Internal] [Added] - Add automated response for Needs: Repro
Pull Request resolved: https://github.com/facebook/react-native/pull/28397

Test Plan: Bot should add a comment with the Needs: Repro label.

Reviewed By: cpojer

Differential Revision: D20665378

Pulled By: hramos

fbshipit-source-id: 1c7d878faacf935a640849f74c81f119e5c7e92d

* Daily `arc lint --take CLANGFORMAT`

Reviewed By: zertosh

Differential Revision: D20666684

fbshipit-source-id: 32255ac7509e0257693969a7b4b044569af30df7

* ✅ Green CI: Fix JavaScript e2e tests, disable failing Android e2e test (#28392)

Summary:
Jobs now have a `run_disabled_tests` argument that allows for the selective execution of disabled tests. When working on re-enabling a failing test, the contributor just needs to set `run_disabled_tests` to `true` in the appropriate workflow in `.circleci/config.yml`.

Tests can be kept green by moving failing tests into the disabled section until a contributor can provide a fix, thus ensuring signal is maintained on master. For example, a failing end-to-end test might be disabled in order to allow the signal from unit tests to be provided, as opposed to flat out failing the entire job.

What was done in this PR:
* The failing `test_js_e2e` job has been fixed, and merged into the `test_js` job. An empty disabled tests section is added for future use.
* The failing `test_ios_e2e` job has been merged into `test_ios`, with all of its steps gated behind the `run_disabled_steps` argument.
* The failing Android end-to-end tests have been added to `test_android`, gated behind the `run_disabled_steps` argument
* The failing Podspecs test has been added back into `test_ios`, gated behind the `run_disabled_steps` argument

## Changelog

[Internal] [CI] - ✅ Green CI, disabled test infrastructure work
Pull Request resolved: https://github.com/facebook/react-native/pull/28392

Test Plan: Verified on Circle CI

Reviewed By: cpojer

Differential Revision: D20665512

Pulled By: hramos

fbshipit-source-id: 831738027f90f4b23313893d8342d7e654f34726

* Upgrade internal packages to support ESLint >= 6 (#28393)

Summary:
Fixes https://github.com/facebook/react-native/issues/28293

I've tested it with https://github.com/react-native-community/react-native-template-typescript and it seems to be working as expected - no warnings, supports typescript 3.8.

(note: I didn't upgrade the package version as I don't know how the releases work for this package)

## Changelog

[CATEGORY] [TYPE] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/28393

Reviewed By: hramos

Differential Revision: D20647112

Pulled By: cpojer

fbshipit-source-id: ca6b67971f625dc8125a58f9220dfcd86250ba94

* Fabric: Fixing a deadlock in RCTSurfacePresenter

Summary:
This is another attempt to fix an issue very similar to T59424871. The previous attempt was in D19249490. I don't know why we don't see production crashes (stalls) but it happened to me (and not to me) in the debugger. The previous attempt didn't work because we still could have a deadlock because we tried to acquired shared mutex already owned exclusively by the `suspend` method.

Here is another approach: Instead of using one shared mutex, now we use two. One is similar to what we had and another that protects `suspend` and `resume`. Besides that, now we pass a Scheduler to functions that use that explicitly. This way we can be more explicit about acquiring mutexes and the overall flow of execution. The idea is: Now an arbitrary code that can be reentrant does not cover with mutexes, so the deadlock is not possible.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: sammy-SC

Differential Revision: D20639228

fbshipit-source-id: 98515742f00f2ae94b50b585c9f1f0611e169ebe

* Update React Hooks Plugin

Summary:
Updates `eslint-plugin-react-hooks` to 3.0.0. This introduces a new lint error when you use a Hook inside a class.

Changelog:
[General][Changed] - Updated the React Hooks ESLint Plugin

Reviewed By: cpojer

Differential Revision: D20675528

fbshipit-source-id: d0cbe9748fd15df7a4c6de00bd1462610e0a43d6

* Upgrade React DevTools 4.0.6 -> 4.6.0

Summary:
Upgrading the embedded version of React DevTools, primarily to pull in [this PR](https://github.com/facebook/react/pull/18397) which will reduce the impact of this package on `node_modules` size.

# Update process

Following a similar process as D15973709, I began by searching for [all of the references](https://our.intern.facebook.com/intern/biggrep/?corpus=xplat&filename=.json&case=false&view=default&extre=&s=%22react-devtools&engine=apr_strmatch&context=false&filter[uninteresting]=false&filter[intern]=false&filter[test]=false&grep_regex=) to the `react-devtools-core` package and updated all v4 usage to to point to the new 4.6.0 release:

1: Manually update "react-devtools-core" versions:
```
js/package.json
js/react-native-github/package.json
nuclide/package.json
sonar/desktop/app/package.json
sonar/desktop/plugins/reactdevtools/package.json
vscode/modules/vscode-webview/package.json
```
2: Setup Yarn proxy:
```
yarn config set proxy http://fwdproxy:8080/
yarn config set https-proxy http://fwdproxy:8080
```
3: Run "yarn" in each of the above directories.
4: Run the lockfile shell script:
```
~/xplat/js/scripts/update-oss-yarn-lockfile.sh
```
5: Update the generated `MOBILE_JS_NODE_MODULE_DEPS.bzl` by running
```
js1 build buckfiles
```

## Changelog:

[General] [Changed] - Upgrade embedded React DevTools backend from v4.0.6 to v4.6.0.

Reviewed By: cpojer, gaearon

Differential Revision: D20676091

fbshipit-source-id: 99865bdba9bce45e2a7d582d5fb550cfdbeeca3a

* Make ScrollView use ForwardRef

Summary:
Have ScrollView use forwardRef so that the host component methods like `measure` and `measureLayout` are available without having to call `getNativeScrollRef`. Instead, you can use `<ScrollView ref={myRef} />` and directly call all methods of ScrollView and host components on `myRef`.

Previous usage:
```
const myRef = React.createRef<React.ElementRef<typeof ScrollView>>();
<ScrollView ref={myRef} />

const innerViewRef = myRef.current.getNativeScrollRef();

innerViewRef.measure();
```
New usage:
```
const myRef = React.createRef<React.ElementRef<typeof View>>();
<ScrollView ref={myRef} />

// now, myRef.current can be used directly as the ref
myRef.current.measure();
myRef.current.measureLayout();

// Additionally, myRef still has access to ScrollView methods
myRef.current.scrollTo(...);
```

Changes:

* Added deprecation warnings to ScrollView methods `getNativeScrollRef`, `getScrollableNode`, and `getScrollResponder`
* Added the forwardRef call to create `ForwardedScrollView` - this takes in `ref` and passes it into the class ScrollView as `scrollViewRef`.
* Forwarded the ref to the native scroll view using `setAndForwardRef`.
* Added statics onto `ForwardedScrollView` so that `ScrollView.Context` can still be accessed.
* Added type `ScrollViewImperativeMethods`, which lists the public methods of ScrollView.
* Converted all public methods of ScrollView to arrow functions. This is because they need to be bound to the forwarded ref.
* Bound all public methods of ScrollView to the forwarded ref in the `setAndForwardRef` call.
* Flow typed the final output (ForwardedScrollView) as an abstract component that takes in the props of the `ScrollView` class, and has all methods of both the inner host component (`measure`, `measureLayout`, etc) and the public methods (`scrollTo`, etc).

Changes to mockScrollView:
* Changed mockScrollView to be able to mock the function component instead of a class component
* Updated necessary tests

Changelog:
[General] [Changed] - Make ScrollView use forwardRef

Reviewed By: TheSavior

Differential Revision: D19304480

fbshipit-source-id: 6c359897526d9d5ac6bc6ab6d5f9d82bfc0d8af4

* Fix issue with onEndReached

Summary:
onEndReached can be triggered twice when more items are added to the end of the list. This change makes it so that a second call to onEndReached won't happen until the user scrolls down to the new end of the list.

Changelog:

[General] [Fixed] - Fix double call to onEndReached in VirtualizedList

Reviewed By: sahrens

Differential Revision: D20066740

fbshipit-source-id: 129d7ae6bfd241eeea18fe0bb12b82be67735874

* Remove console warnings from ScrollView methods

Summary:
The newly added console warnings in D19304480 are adding a lot of warning noise due to missed infra callsites. Those callsites need to be updated before these warnings can be added.

Changelog:
[Removed] Remove console warnings from ScrollView methods

Reviewed By: rickhanlonii

Differential Revision: D20700917

fbshipit-source-id: cb618ee3a291d26e1942e4f91bbc02dee41fb78b

* Upgrade react-docgen, jscodeshift and flow-parser

Summary:
In preparation for upgrading babel, I'm updating some of our source transform tools to the latest versions.

Changelog: [Internal]

Reviewed By: GijsWeterings

Differential Revision: D20675201

fbshipit-source-id: fa4fee2652529c6677087e42cdd1325a8080e46f

* Ship State Reconciliation 100% on all platforms

Summary:
State Reconciliation has been running 50/50 for a while and all metrics look stable. This is necessary for providing a good experience so we should ship to everyone unconditionally.

Changelog: [Internal] Fabric diffing reconciliation process improvement

Reviewed By: mdvacca

Differential Revision: D20715694

fbshipit-source-id: 25b2635ecc29b67e2911679c9db66bc84d37dec1

* Core telemetry tests: update so they pass on my machine

Summary:
`std::this_thread::sleep_for` is not really precise and will attempt to sleep for "at least" that much time, but may sleep much longer depending on what CPUs are doing and scheduling policies.

To get this to pass on my machine, I had to substantially increase the thresholds.

Changelog: [Internal]

Reviewed By: shergin

Differential Revision: D20689571

fbshipit-source-id: f159420d24a95da2b5d95d49ed7882e783291e98

* Optimize diff algorithm to produce fewer remove+insert ("move") paired instructions

Summary:
An evolution of D20633188 but more performant.

There are three optimized paths before the slow path.

The first optimized path tries to pair identical nodes from old/new tree, and generate Update mutations, until we hit nodes that are different (indicating either a remove or an insert). This already existed.

The next two optimizations, introduced by Tim in his JS pseudocode, were inspired by ReactJS's diffing algorithm. They work in cases where the rest of the nodes are (1) all removals/deletes or (2) all creates+inserts.

Finally, if those final two optimized paths can't run, it's because there is a mix of delete+remove, create+insert, and "move" operations, mixed at the beginning, middle, and/or end of the list.

This has slightly better average/best-case complexity as the previous implementation.
In particularly pathological cases where all nodes are arbitrarily reordered, or reversed, for instance (ABCDE->EDCBA) the algorithm has the same complexity as the previous algorithm (quadratic).

For now iOS is pinned to the older differ

Changelog: [Internal] Experiment to optimize diffing algorithm in Fabric

Reviewed By: shergin

Differential Revision: D20684094

fbshipit-source-id: d29fba95a0328156c023e1c87804f23770ee1d91

* Unit test for V2 "minimal instruction" diffing algorithm

Summary:
This unit test is to verify that the new diffing algorithm generates a "minimal" instruction set, with regards to removes and inserts ("moves").

These unit tests are here to verify the expected behavior in this new algorithm, but these tests may be modified or deleted in the future if we decide we want to change this behavior.

Changelog: [Internal] fabric unit test

Reviewed By: mdvacca

Differential Revision: D20706592

fbshipit-source-id: 5f9991498e0d788ecbf88d938bfe6d3f0f27af40

* Add ES Lint rules for `DynamicColorIOS()`and `ColorAndroid()` (#28398)

Summary:
The [PlatformColor PR](https://github.com/facebook/react-native/pull/27908) added support for iOS and Android to express platform specific color values.   The primary method for an app to specify such colors is via the `PlatformColor()` method that takes string arguments.   The `PlatformColor` method returns an opaque Flow type enforcing that apps use the PlatformColor method instead of creating Objects from scratch -- doing so would make it harder to write static analysis tools around Color values in the future.   But in addition to `PlatformColor()`, iOS has a `DynamicColorIOS()` method that takes an Object.   The Flow type for this Object cannot be opaque, but we still want to enforce that app code doesn't pass variables instead of Object literals or that values in the Objects are variables.   To ensure `DynamicColorIOS()` can be statically analyzed this change adds an ESLint rule to enforce that `DynamicColorIOS()` takes an Object literal of a specific shape.   A `ColorAndroid()` was also introduced not for practical use but just to test having platform specific methods for more than one platform in the same app.   A second ESLint rule is created for `ColorAndroid` as well.

## Changelog

[General] [Changed] - Add ES Lint rules for `DynamicColorIOS()`and `ColorAndroid()`
Pull Request resolved: https://github.com/facebook/react-native/pull/28398

Test Plan: `yarn lint` passes.

Reviewed By: cpojer

Differential Revision: D20685383

Pulled By: TheSavior

fbshipit-source-id: 9bb37ccc059e74282b119577df0ced63cb9b1f53

* fix: Android gradle config when bundling for release (#28415)

Summary:
This fix aims to address the issue when bundling an Android app for release and getting the error exhibited in https://github.com/facebook/react-native/issues/28002 which I also encountered myself.

The config was changed sometime in November 2019 (as part of https://github.com/facebook/react-native/issues/26940, commit https://github.com/facebook/react-native/commit/a3b08048674e324dbe1f0ca816f35607e9e06a2f) to be very opinionated when it comes to the use of `npx` which Gradle itself cannot find anyway (I have `npx` installed globally and it didn't pick it up).

Another issue that the use of `npx` creates is that Gradle should only ever use the currently installed react-native cli rather than a (possibly) higher version which may not always have backward compatibility.

The proposed change simply throws a more descriptive error rather than defaulting to a tool which may or may not exist on the machine, be it CI or a development environment. I've also modified the RNTester app to reflect the correct config implementation relative to the RNTester app itself.

In real projects, the config inside `android/app/build.gradle` should look similar to the following snippet:

```
project.ext.react = [
  cliPath: "$rootDir/../node_modules/react-native/cli.js",
  entryFile: "index.js"
];
```

## Changelog
[Android] [Fixed] - Gradle release config
Pull Request resolved: https://github.com/facebook/react-native/pull/28415

Test Plan:
- [x] Successfully bundled an Android release build with correct config
- [x] Works with RNTester app

Reviewed By: mdvacca

Differential Revision: D20714372

Pulled By: hramos

fbshipit-source-id: 4d66139249c6f840582a71a48c64e6a6595f7af0

* Reimplement D19965405: Small improvements in Differentiator/TinyMap

Summary:
Two things:
1) I reimplement Valentin's idea in D19965405, so that TinyMaps can be iterated over, with a couple of bugfixes (calling front() or back() on an empty vector will crash).
2) I now use TinyMap instead of better::map in the "optimized" diffing algorithm.
3) `erase` now actually removes elements from the vector, but only when more than half of elements have been erased.
4) If you repeatedly erase elements at the beginning of the vector, they will no longer be iterated over. This is a specific optimization for our heaviest TinyMap use-cases.

These amount to some small but hopefully somewhat meaningful perf improvements.

Changelog: [Internal] Fabric perf

Reviewed By: shergin

Differential Revision: D20718719

fbshipit-source-id: 91f4b2e2e0f6387ae484e43d5b0095103087baa6

* Remove LayoutInspectingPolicy.includeScrollViewContentOffset

Summary:
`LayoutInspectingPolicy` has two flags, `includeTransform` and `includeScrollViewContentOffset`.

`includeScrollViewContentOffset` seems to be redundant for two reasons.

# 1st
From looking at callers, they have always the same value.
I looked at all call sites, and they are either always both set to true or both set to false.

# 2nd
The way we include scroll view content offset, is through transformation, so setting `includeTransform` to true and `includeScrollViewContentOffset` to false will include content offset anyway. In order to make both flags work, we would need to introduce further changes to `getRelativeLayoutMetrics`. But since the flag isn't used anyway, I think it is better to get rid of it for now. If we need it in the future, we could re-introduce it.

Reviewed By: shergin

Differential Revision: D20622256

fbshipit-source-id: fb6156c66b752319ea928239fa723ff90688b0a0

* Add support for translation and rotation to operator * between Rect and Transform

Summary:
Changelog: [Internal]

Until now `Rect operator*(Rect const &rect, Transform const &transform)` supported only scaling. Now it supports translation and rotation as well.

Reviewed By: shergin

Differential Revision: D20622876

fbshipit-source-id: 1b65393bd3fd6fd9a8941903e0f2681a10097e4a

* Include transform property when calling getRelativeLayoutMetrics

Summary:
Changelog: [Internal]

Current implementation of `measure` doesn't take transform into account..

So if you had a view which has width and height 100 and had `Scale(0.5, 0.5, 1)` (this will shrink view by half). Calling `getRelativeLayoutMetrics` would report its size being `{100, 100}`.
This applies if view's parent has transformation as well, because transformation is applied to all subviews of the view as well.

Reviewed By: mdvacca

Differential Revision: D20621590

fbshipit-source-id: 2cf902a0494291c821ecada56f810c5e6620db5a

* feat: migrate appveyor to circleci (#28245)

Summary:
This issue closes https://github.com/facebook/react-native/issues/28241
Migrated Windows test from AppVeyor to CircleCI

## Changelog

[Internal] [Changed] - Migrated Windows test from AppVeyor to CircleCI
Pull Request resolved: https://github.com/facebook/react-native/pull/28245

Test Plan: For CircleCI to Pass

Reviewed By: cpojer

Differential Revision: D20689163

Pulled By: hramos

fbshipit-source-id: 285c762457ef00f7884ee9157b3f336044c0452f

* Remove "Debug with Nuclide" option

Summary: This is no longer needed.

Reviewed By: cpojer

Differential Revision: D20722274

fbshipit-source-id: 5bc3104e90811d724f42aadbf137ab8eff718ca0

* experiment to preload RN bridge after fb4a bookmarks render

Summary:
Changelog:
[Android][Internal] add internal supermodule label

Reviewed By: mdvacca

Differential Revision: D20434200

fbshipit-source-id: fae50309cdd0df4a4523c2f88d1c8e01a7163575

* Fix CursorDrawable Color Tint for Android 10+

Summary:
Accessing this field via reflection is explicitly blacklisted by Google in Android 10 and higher. They have provided a new API to change the color, which I have implemented here. [The old setColorFilter is deprecated](https://developer.android.com/reference/android/graphics/drawable/Drawable#setColorFilter(int,%20android.graphics.PorterDuff.Mode)) so I also updated that method call as well.

Changelog: [General] [Fixed] Use new setTextCursorDrawable API for Android 10

Reviewed By: JoshuaGross

Differential Revision: D20656068

fbshipit-source-id: 58a92b57c0a892c7c87fc5d735e4ceaa4e987ec7

* Early return on tinting CursorDrawable if no color supplied

Summary:
There's (potentially) a lot of expensive reflection calls here that, as best I can tell, end up being ignored if the supplied color is null. Better to early return.

Changelog: [General] [Internal] Preclude reflection when setting cursor color if color is null

Reviewed By: JoshuaGross

Differential Revision: D20670594

fbshipit-source-id: 480a988355bbd79008002c4326d4b35035ec2a95

* Partial React Sync for Inspector

Summary:
Partial sync for React that includes:

- https://github.com/facebook/react/pull/18388
- https://github.com/facebook/react/commit/dd7e5e4f5ac2ffac3171ef61daee2cb1edc69635

Created from this branch: https://github.com/facebook/react/compare/master...rickhanlonii:rh-partial-3-24?expand=1

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D20651395

fbshipit-source-id: 67baf7c407f75d9fd01c17f2203a77a38567100e

* Enable inspector for Fabric

Summary:
## Overview
This diff refactors the Inspector, moving logic to look up view data for a touched view inside the renderer as `getInspectorDataForViewAtPoint`. We then implement that same function for Fabric in order to support the inspector in that renderer.

Requires https://github.com/facebook/react/pull/18388

## Motivation

Reason one for this refactor is that, previously, the inspector held all of the logic to look up view data for a given x,y touch coordinate. To do this, it would take the React tag and coordinates, look up the native view tag, measure it, and then ask React internals for the Fiber information of that tag. All of this is deeply coupled to React internals, yet the logic is outside of React core in the Inspector.

Reason two is that, for Fabric, the logic for getting the view data is different than Paper. In Fabric, we pass the x,y coordinates to native directly, which returns an instance handle. That handle can be used to measure the ShadowNode, or retrieve the Fiber information.

By moving the logic into the renderer in React core, we decouple the implementation details of looking up view data for a tapped point and allow ourselves the ability to add and change renderer-specific code for the actual lookup without impacting outsiders like the Inspector.

Changelog: [Internal]

Reviewed By: TheSavior

Differential Revision: D20291710

fbshipit-source-id: a125223f2e44a6483120c41dc6146ad75a0e3e68

* chore: update url of warning message from deprecated imports (#28452)

Summary:
Some of the repository name of Lean Core(https://github.com/facebook/react-native/issues/23313) libraries has been renamed.
This PR updates the warning message to display the updated url.

## Changelog

[General] [Changed] - Update warning message of deprecated imports
Pull Request resolved: https://github.com/facebook/react-native/pull/28452

Test Plan: updated URL can be accessed.

Reviewed By: cpojer

Differential Revision: D20745184

Pulled By: TheSavior

fbshipit-source-id: 2c3ed6a000b45022ca6c4862305aa567c4d18b2e

* Add `upgrade-support` link on issue creation (#28411)

Summary:
This PR adds a https://github.com/react-native-community/upgrade-support link for the user when creating an issue.
Changelog:
[Internal]

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

Reviewed By: cpojer

Differential Revision: D20714274

Pulled By: hramos

fbshipit-source-id: 4ca42224a50e386b95f21f0fb236a917e1b6b982

* Update PixelRatio 'getFontScale' method description (#28407)

Summary:
Refs facebook/react-native-website#1776.

Despite in-code description `PixelRatio.getFontScale()` is working properly on the iOS (it also reflects the user settings).

This PR updates the in-code description to match current behaviour.

I have decided to skip in the code information about additional setting in `Accessibility` menu and in `Control Centre`, but if you think it is important just let me know, I can update this PR.

## Changelog

[Internal] [Fixed] - Fix PixelRatio getFontScale method description
Pull Request resolved: https://github.com/facebook/react-native/pull/28407

Test Plan: N/A

Differential Revision: D20750260

Pulled By: shergin

fbshipit-source-id: c40ec2fd49cd60e2975351c3a1c453aab0045da4

* Remove allowDisablingImmediateExecutionOfScheduleMountItems feature flag

Summary:
No longer needed.

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D20747684

fbshipit-source-id: a8077519b7670d72e23267b1c1423556ec97be3f

* RuntimeExecutor helpers that modify the way of the callback is being executed.

Summary:
Here we implement a bunch of helper methods that allow customizing the behavior of a RuntimeExecutor "on-demand" on the caller side. We will use it in the next diff(s).

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: PeteTheHeat

Differential Revision: D20551411

fbshipit-source-id: 51d3cd02b69753110c0e1155347c6e52eb882c7d

* Fabric: Using `executeSynchronouslyOnSameThread_CAN_DEADLOCK` in MainRunLoopEventBeat

Summary:
We are replacing inline-ed implementation with practically the same one implemented as the helper method.

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: sammy-SC

Differential Revision: D20551409

fbshipit-source-id: fcc6f497cd240af65fba534051c217fe5746ce82

* Set RootNodeKind trait in ModalHostViewShadowNode

Summary:
Changelog: [internal]

`ModalHostViewShadowNode` didn't have `RootNodeKit` trait, therefore `getRelativeLayoutMetrics`  was including nodes in ancestors that it shouldn't have.

Reviewed By: shergin

Differential Revision: D20735801

fbshipit-source-id: 6b81e3b174c2f82e530abc2bca2da8bebc2270b0

* mention RNTester app in contributor guide (#28042)

Summary:
motivation is following - the RNTester app is imho the best place to try out any changes that a contributor would make, yet it is not directly mentioned in the contributor guide. This fixes it.

## Changelog

[Internal] - Docs
Pull Request resolved: https://github.com/facebook/react-native/pull/28042

Test Plan: not necessary

Reviewed By: TheSavior

Differential Revision: D20401260

Pulled By: hramos

fbshipit-source-id: 01c1b7dff56b59909c94b2feb609650f0baba1a9

* Buck: Use Android SDK 29 during build (#28455)

Summary:
Fixes `test_android` and `test_docker` build failures. Thanks to dulmandakh for identifying the fix.

Changelog:
[Internal] [Android] [Changed] - Use Android SDK 29 to build during CI tests
Pull Request resolved: https://github.com/facebook/react-native/pull/28455

Test Plan: Circle CI shows `test_android` and `test_docker` passing: https://app.circleci.com/jobs/github/facebook/react-native/142273

Reviewed By: sturmen

Differential Revision: D20766589

Pulled By: hramos

fbshipit-source-id: 8ef8a8ce3a6e7353ae47425accb3bd26cf1608c4

* Assign orderIndex_ in ConcreteViewShadowNode constructor instead of ViewShadowNode's constructor

Summary:
Changelog: [Internal]

`orderIndex_` was only being assigned for `ViewShadowNode`, not for other `ShadowNodes` that are later represented on the screen.

Reviewed By: shergin

Differential Revision: D20746477

fbshipit-source-id: c04c2cfea14b9141d22bc3d9e9bb4c0c59925754

* Implement nativePerformanceNow to improve Profiler API results (#27885)

Summary:
When experimenting with React Profiler API (https://reactjs.org/docs/profiler.html), I noticed that durations are integers without a debugger, but they are doubles with higher precision when debugger is attached. After digging into React Profiler code, I found out that it's using `performance.now()` to accumulate execution times of individual units of work. Since this method does not exist in React Native, it falls back to Javascript `Date`, leading to imprecise results.

This PR introduces `global.nativePerformanceNow` function which returns precise native time, and a very basic `performance` polyfill with `now` function.

This will greatly improve React Profiler API results, which is essential for profiling and benchmark tools.

Solves https://github.com/facebook/react-native/issues/27274

## Changelog

[General] [Added] - Implement `nativePerformanceNow` and `performance.now()`
Pull Request resolved: https://github.com/facebook/react-native/pull/27885

Test Plan:
```
const initialTime = global.performance.now();
setTimeout(() => {
  const newTime = global.performance.now();
  console.warn('duration', newTime - initialTime);
}, 1000);
```

### Android + Hermes

![Screenshot_1580198068](https://user-images.githubusercontent.com/13116854/73245757-af0d6c80-41b5-11ea-8130-dde14ebd41a3.png)

### Android + JSC

![Screenshot_1580199089](https://user-images.githubusercontent.com/13116854/73246157-92256900-41b6-11ea-87a6-ac222383200c.png)

### iOS

![Simulator Screen Shot - iPhone 8 - 2020-01-28 at 10 06 49](https://user-images.githubusercontent.com/13116854/73245871-f136ae00-41b5-11ea-9e31-b1eff5717e62.png)

Reviewed By: ejanzer

Differential Revision: D19888289

Pulled By: rickhanlonii

fbshipit-source-id: ab8152382da9aee9b4b3c76f096e45d40f55da6c

* Save/restore IP when leaving the interpreter

Summary:
This diff implements the instruction pointer save/restore trick Tzvetan came up with; allowing us to observe and modify the IP from outside the interpreter loop with negligible overhead.

From Tzvetan's internal post on the subject:

> [Today] the interpreter IP is just a local variable in the interpreter function, so there is no way to get to its value from outside the function. It lives in a register and we don't want to make it a Runtime field since the overhead [of accessing it via memory in the interpeter loop] would kill us.

> However, if you really think about it, it only lives in a register while the interpreter function is running. For the rest of the time, it is spilled by the C++ compiler onto the stack.
So, precisely when we need it, it is actually stored in memory. The only problem is, we don't know where! Admittedly, that is an annoying problem, but it feels like it should be solvable.

> What if, instead of relying on the compiler to spill the IP register, we manually spill it ourselves, to a known location? It works. Example: https://godbolt.org/z/ftSDnp

This diff implements this approach across the whole interpreter loop: whenever we call out of the loop we capture/publish the IP and restore it again immediately after the external call returns. This means we can now see the IP outside the interpret loop and even change it. This is effectively "for free" as the compiler now skips spilling/restoring the IP behind the scenes.

The immediate benefit of this is knowing the current IP allows us to have more accurate stack-traces during execution. In future this may enabled tricks like changing the IP before returning to th…
grabbou added a commit to callstack/react-native that referenced this pull request Oct 23, 2020
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
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…
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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. p: Callstack Partner: Callstack Partner
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants