-
Notifications
You must be signed in to change notification settings - Fork 24.3k
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
Conversation
# 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 |
There was a problem hiding this comment.
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.
There was a problem hiding this 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
Nice one 👌 |
There was a problem hiding this 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.
This pull request was successfully merged by @grabbou in a8e8502. When will my fix make it into a release? | Upcoming Releases |
…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
…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
…ROOT (facebook#28354)" This reverts commit a8e8502.
# 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} |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 :)
There was a problem hiding this comment.
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)
is there a guide on how to use monorepo with this pr ? |
…ROOT (facebook#28354)" This reverts commit a8e8502.
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
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
* 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…
…PROJECT_ROOT (facebook#28354)"" This reverts commit 6afacda.
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
* 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…
Summary
Historically, React Native didn't support a lot of custom project structures apart from the standard flat directory with
ios
andandroid
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 innode_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 removecd
entirely.To better understand this PR, let's look a few hypothetical structures as an example:
Monorepo:
Before this PR, the
react-native-xcode.sh
will start the CLI like this: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 undermy-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, settingexport PROJECT_ROOT = "$PWD/../
will set the directory tomy-app
, which has a dependency onreact-native
in apackage.json
and makes the CLI happy.After this PR, the
react-native-xcode.sh
will start the CLI like this:The
$PWD
ispackages/my-app/ios/
because that's where the Xcode project is located. CLI will automatically set the root to../
because that's where it findspackage.json
withreact-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:
Before this PR, the
react-native-xcode.sh
will start the CLI like this:react-native
insidenode_modules
is correct - the project root is set right to/
After this PR, the
react-native-xcode.sh
will start the CLI like this:/ios
. This is the PWD for all Xcode scripts.CLI will look for the
package.json
going upwards fromios
folder. Will stop at/
, find out it hasreact-native
dependency, load it and its commands and proceed further.Changelog
[iOS] [Feature] - Better monorepo support when building release apk
Test Plan
CC: @Titozzz (who wrote monorepo guide), @alloy, @bartolkaruza