Merge from upstream 0.64-stable to v0.64.0 #863
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Summary: Upgrade metro to 0.64.0 Changelog: [Internal] Reviewed By: cpojer Differential Revision: D24753886 fbshipit-source-id: af679ec912c5cd8049a998d045ce8a75bf30e5d3
Summary: When running yarn install from the codegen directory it will reinstall all dependencies for the react-native workspace inside the react-native package. In my case this caused issues with metro because it would now have 2 copies of it (node_modules/metro and node_modules/react-native/node_modules/metro). To avoid this copy the react-native-codegen source in a temporary directory and yarn install from there, then copy the built files back. ## Changelog [Internal] - Build rn-codegen in a temporary directory Pull Request resolved: facebook#30292 Test Plan: Tested the script in an app with codegen enabled. Fresh install with rn-codegen not built, made sure no extra modules are installed under node_modules/react-native/node_modules. Reviewed By: yungsters Differential Revision: D24893216 Pulled By: fkgozali fbshipit-source-id: 2c372b755632ea6f50ad5d4562248612b349a9a6
Summary: If $FBSOURCE_ENV isn't set, this failed with `/root/react-native/packages/react-native-codegen/android/../scripts/oss/build.sh: line 20: FBSOURCE_ENV: unbound variable`. This commit fixes https://app.circleci.com/pipelines/github/facebook/react-native/7080/workflows/5cf18a1f-e6d2-4648-8217-d42e9a61fef1/jobs/176451 Changelog: [Internal] Reviewed By: yungsters Differential Revision: D24912950 fbshipit-source-id: 113e3dd7f78c75fc3adea0b21c9e38910be8c065
Summary: Add the `react-native-codegen` source to the `react-native` npm package. Instead of using `react-native-codegen` from npm, the iOS app template will now build the package from source. Doing so removes the need to carefully time `react-native-codegen` npm releases to oss `react-native` releases, as the codegen and the oss release will be cut at the same time. Changelog: [Internal] - Removed react-native-codegen dependency from iOS app template Reviewed By: TheSavior Differential Revision: D24904655 fbshipit-source-id: a07932bc748e2afb9359de584181bcb9dd0810ea
Summary: Fixes facebook#30415 This is a quick and dirty fix to unblock publish, of excluding a class from Javadoc generation that is importing a class current build logic cannot handle. This is not a long-term fix for the issue. ## 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] [Fixed] - Fix :ReactAndroid:androidJavadoc task Pull Request resolved: facebook#30417 Test Plan: Tested that the task now completes locally. Reviewed By: lunaleaps Differential Revision: D25041282 Pulled By: fkgozali fbshipit-source-id: f774ab30a09db473178e2a51c77860e4985dd8e3
Summary: Use pre-built react-native-codegen library from npm in the iOS app template. Built react-native-codegen from source when used with RNTester. Published react-native-codegen@0.0.6. Changelog: [iOS][Added] - Use react-native-codegen in iOS app template [Internal] - Bump react-native-codegen: 0.0.6 Reviewed By: fkgozali Differential Revision: D25128036 fbshipit-source-id: f294c23b9b911aae6f404edc01b62426fb578477
Summary: Part of react-native-community/releases#207 Migrate warnings in index.js to point to new lean core repos NOTE: some npm modules has been transferred to new nom namespace, such as `react-native-picker/picker` `react-native-async-storage/async-storage` `react-native-masked-view/masked-view`. Some lean core repo has been transferred to new repo, but its npm namespace remains the same. ex: clipboard module exists in react-native-clipboard/clipboard repo, but npm package name is still `react-native-community/clipboard` (they're planned to be migrated in the future) ## 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] - Migrate warnings in index.js to point to new lean core repos Pull Request resolved: facebook#30422 Test Plan: - Updated repo URL can be accessed - Updated npm package can be installed Reviewed By: rickhanlonii Differential Revision: D25077750 Pulled By: cpojer fbshipit-source-id: b736ea449835bdf3d2a2f85e5c86e5253b90db78
Summary: _**Fixed**_ version of [the previous PR](facebook#28792) after reverting [changes](facebook@c8d678a#commitcomment-39299254) ---- I've noticed that currently there is no option to disable button within the `ActionSheetIOS`. It can be really useful and decided to extend the API to support that functionality. I added a new option called `disabledButtonsIndices` to `ActionSheetIOS` which is an array of button indices which should be disabled. `ActionSheetIOS` documentation - PR facebook/react-native-website#1898 ## Changelog [iOS] [Added] - Add disableButtonsIndices option to ActionSheetIOS component Pull Request resolved: facebook#28979 Test Plan: 1. Run the `RNTester` 2. Choose `ActionSheetIOS` 3. Check the fourth example `Show Action Sheet with disabled buttons` 4. `Option 1` and `Option 2` should be disabled screenshot | gif --- | --- <img width="493" alt="Screenshot 2020-04-30 at 15 16 22" src="https://user-images.githubusercontent.com/22746080/80739025-1ec52780-8b16-11ea-8b1c-30bb40ad8c99.png"> | <img src="https://user-images.githubusercontent.com/22746080/80739043-24227200-8b16-11ea-8bcb-af25eb57baac.gif" width="493" /> Reviewed By: sammy-SC Differential Revision: D21727497 Pulled By: PeteTheHeat fbshipit-source-id: 749b6c623eb8a44fe2bd96829ce89be5310e2368
Summary: Upgrading CLI to latest. This diff is intended to be cherry-picked to 0.64. cc grabbou kelset alloy [Internal] [Changed] - Bump CLI to ^5.0.1-alpha.0 Pull Request resolved: facebook#30420 Test Plan: None Reviewed By: MichaReiser Differential Revision: D25063261 Pulled By: cpojer fbshipit-source-id: e1788fd40db2b00daaf888e7b2afaf708ade5451
Summary: Fixes: facebook#29455 Modal's onDismiss is not called on iOS. This issue occurred the commit facebook@bd2b7d6 and was fixed the commit facebook@27a3248. However, the master and stable-0.63 branches do not have this modified commit applied to them. ## Changelog <!-- Help reviewers and the release process by writing your own changelog entry. For an example, see: https://github.com/facebook/react-native/wiki/Changelog --> [iOS] [Fixed] - Modal's onDismiss prop will now be called successfully. Pull Request resolved: facebook#29882 Test Plan: Tested on iOS with this change: 1. Set function Modal's onDismiss prop. 1. Set Modal's visible props is true. (show Modal) 1. Set Modal's visible props is false. (close Modal) 1. The set function in onDismiss is called. Reviewed By: shergin Differential Revision: D24648412 Pulled By: hramos fbshipit-source-id: acf28fef21420117c845d3aed97e47b5dd4e9390
…0449) Summary: Move the codegen invocation out of Podfiles and into the FBReactNativeSpec Pod itself. With this change, developers do not need to modify their existing project's Podfiles, and yet the codegen will be integrated into their projects automatically by way of the FBReactNativeSpec Pod. This is accomplished in part by injecting a script build phase into the Pods Xcode project that is generated by CocoaPods. The build phase will save the output of the codegen script to a log in the derived files directory. The codegen will be executed if the codegen log file is not present, or if the contents of the Libraries directory has changed. The codegen will thus be invoked in these situations: **RNTester:** * When `packages/rn-tester/RNTesterPods.xcworkspace` is built, if the codegen output logfile is not present or if the input files have changed. **OSS React Native apps:** * When `ios/AwesomeProject.xcworkspace` is built, if the codegen output file is not present or if the input files have changed. Normally, this should not happen, as we do not expect folks to update the contents of `node_modules/react-native/Libraries`. Pull Request resolved: facebook#30449 Changelog: [Internal] - Moved codegen invocation out of Podfile and into FBReactNativeSpec Pod Reviewed By: fkgozali Differential Revision: D25138896 fbshipit-source-id: 4779f822459cea2c30fd544eee19a49e8d80153d
Summary: Quick fix for Circle CI: Ensure FBReactNativeSpec dir exists before touching files. Changelog: [Internal] Reviewed By: fkgozali Differential Revision: D25285573 fbshipit-source-id: 8dec496856c90accc687648d7068aadfea24d72b
Summary: The wrong value for the path to react-native-codegen was being used. The issue was introduced during the refactoring of this script for use in FBReactNativeSpec.podspec. Changelog: [Internal] Motivation: Reviewed By: fkgozali Differential Revision: D25290355 fbshipit-source-id: 5a46c680e7ea41157b03cf54a640a8816fb682b3
Summary: Update template devDependencies before 0.64.0 release [JavaScript] [Changed] - Update devDependencies (`babel/core` to `7.12.9`, `babel/runtime` to `7.12.5`, `react-native-community/eslint-config` to `2.0.0`, `babel-jest` to `26.6.3`, `eslint` to `7.14.0` and `jest` to `26.6.3`) Pull Request resolved: facebook#30489 Test Plan: - [ ] Check babel - [ ] Check eslint - [ ] Check jest Reviewed By: lunaleaps Differential Revision: D25377357 Pulled By: TheSavior fbshipit-source-id: fd8e1992860a7fbae710898fbee249e9c36d2229
…k#30461) Summary: Just thought I'd add these instructions so devs don't have to check the docs. Also, it makes iOS match Android with instructions in the configuration files ## Changelog N/A (in my opinion) Pull Request resolved: facebook#30461 Test Plan: N/A (because not a code change) Reviewed By: hramos Differential Revision: D25309687 Pulled By: TheSavior fbshipit-source-id: a1907089b9d2e7fe6f2498ce27129c3ae65f7c9a
https://github.com/facebook/hermes/releases/tag/v0.7.2 is out so we can bump the pod version 🎉 Question: Is `~> 0.7.2` too strict? Would `>= 0.7.2` be better? Also, It doesn't look like we are restricting any version on the trunk?
Summary: Recently introduced steps to run Hermes accidentally removed `!` from the `use_react_native`, causing `pod install` to fail with an error. ## Changelog [INTERNAL] [iOS] - Fix Podfle in default template Pull Request resolved: facebook#30571 Test Plan: Run `pod install` with this file and it should work. Reviewed By: appden Differential Revision: D25537263 Pulled By: TheSavior fbshipit-source-id: da7f21775cbe641e34aded87a92c696539f4d5c3
Summary: Fixes facebook#29984 Right now, running a React Native application with Xcode 12 in Release mode on an iPhone Simulator will fail with something like below: > [some file path], building for iOS Simulator, but linking in object file built for iOS, file '[some file path]' for architecture arm64 The best explanation of this issue has been provided by alloy in facebook#29984: > This issue has started coming up with Xcode 12 and support for the new ARM based Macs, as `arm64` now no longer can be assumed to _only_ be for iOS devices. This means Xcode 12 will now also build for `arm64` simulator SDKs and it has become ambiguous if an arch slice in a prebuilt binary is meant for a simulator or device. > > In any case, for now this means that you can configure your Xcode project to exclude `arm64` when building for any iOS simulator SDK. This PR implements aforementioned workaround. ## Changelog [FIX] [IOS] - Fix running React Native project with Xcode 12 in Release on iPhone Simulator Pull Request resolved: facebook#30543 Test Plan: Switch your scheme to Release and run the app on simulator. Will complete w/o issues. Reviewed By: appden Differential Revision: D25537295 Pulled By: TheSavior fbshipit-source-id: 2dc05cb80e59f1d95d2a84ab55ed6a5b5446411c
…iOS (facebook#30592) Summary: When building React Native application in Release mode for an iPhone Simulator _and_ targeting `armv7`, Xcode will build all architectures (due to `ONLY_ACTIVE_ARCH` set to `false`, unlike in Debug mode). As a result, Xcode will try building for `i386` (32-bit iPhone Simulator), which fails as we don’t build Hermes binaries for `i386`. Fix is to disable `i386`, since it is not supported by `Hermes` and certain `Folly` features. ## Changelog [IOS] [BREAKING] - `i386` architecture will be automatically disabled when Hermes is being used. This might be potentially breaking for your workflow if you target `armv7` devices, as you will no longer be able to test on the simulator. [IOS] [FEATURE] - Replace `flipper_post_install` with `react_native_post_install` hook. Will automatically detect if Flipper is enabled. Pull Request resolved: facebook#30592 Test Plan: Run React Native application with Hermes enabled (or Flipper) in Release mode and it should work just fine. Reviewed By: appden Differential Revision: D25564738 Pulled By: TheSavior fbshipit-source-id: e786ab73fb0a77de5869cf9e5999726c7d29f1d4
Summary: Changelog: [General][Fixed] Fix stalling UI due to a bug in KeyboardAvoidingView I introduced this bug in D22764192 (facebook@b08fff6). The stalling was caused by onLayout in JavaScript triggering native layout which called onLayout in JavaScript without terminating condition. The fix is to only cause native layout once from JavaScript's onLayout function. This makes sure both Fabric and Paper works correctly and UI stall isn't caused. Resolves: facebook#30495 facebook#30532 Reviewed By: TheSavior Differential Revision: D25522362 fbshipit-source-id: 602e540bb1c40ae4f421b3e6ebc5a047cd920c17
…k#29610) Summary: There has been a long-standing issue where black-box testing frameworks like Appium and Xamarin UITest have not been able to access the `testID` view prop for Android (see facebook#7135). A natural place for this to be exposed is via a view's `resource-id`. The `resource-id` is what I have used when working on UIAutomator-based tests for native Android apps and is a non-localized, development-only identifier. As mentioned in the linked ticket, you can dynamically set the resource-id using the view's AccessibilityNodeInfo. This change simply checks to see if a testID is provided for a view and then exposes it through the view's accessibility node delegate. ## 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] [Fixed] - Fixes facebook#7135, facebook#9942, and facebook#16137. Display the `testID` as the `resource-id` for black-box testing frameworks Pull Request resolved: facebook#29610 Test Plan: I used the `uiautomatorviewer` tool to verify that the resource-id is populated with the `testID` of a few different views of the RNTester app. <img width="912" alt="Screen Shot 2020-08-10 at 3 38 27 PM" src="https://user-images.githubusercontent.com/875498/89838534-55044100-db20-11ea-9be2-ba507a81f6fb.png"> <img width="1096" alt="Screen Shot 2020-08-10 at 3 40 41 PM" src="https://user-images.githubusercontent.com/875498/89838542-5897c800-db20-11ea-9895-462c6fea1130.png"> Reviewed By: JoshuaGross Differential Revision: D25799550 Pulled By: fkgozali fbshipit-source-id: e64ff1b90fb66b427fce7af533aa94792cfbcad3
Summary: The TurboModuleUtils.h includes "folly/Optional.h" which is not used and creates an unnecessary dependency on Folly. In this PR we remove this unnecessary include. It is required for the microsoft/react-native-windows#6804 where we add an experimental support for the C++ TurboModules. While the C++ TurboModules use the same JSI and TurboModule code defined in react-native, we provide a layer that let them to work over the ABI-safe Microsoft.ReactNative.dll boundary. The RNW Nuget distribution with DLL files includes a few source files to create native/turbo modules that work through the ABI-safe API. The TurboModuleUtils.h is one of such files. By removing the dependency on Folly we reduce requirements for the native module code. After this PR is merged we will remove the fork of the TurboModuleUtils.h added in microsoft/react-native-windows#6804. ## Changelog [Internal] [Fixed] - Remove dependency on Folly in TurboModuleUtils.h Pull Request resolved: facebook#30672 Test Plan: The change does not bring any functional changes. It may only affect code compilation where some code may depend on TurboModuleUtils.h when it needs the "folly/Optional.h". The fix is add the `#include <folly/Optional.h>` there explicitly. I had run the iOS tests and they passed: ``` yarn pod install in packages\rn-tester ./scripts/objc-test.sh test ``` Reviewed By: mdvacca Differential Revision: D25758927 Pulled By: fkgozali fbshipit-source-id: 347d8f6bc333a3df67095ea0dc7221c818432fab
Summary: Since iOS 14 refresh control is sometimes visible when it shouldn't. It seems to happen when it is removed and added back to the window. This repros easily when using react-native-screens with react-navigation tabs. Inactive tabs are detached from the window to save resources. Calling endRefreshing when refresh control is added to the window fixes the layout. It will also be called on first mount where it is not necessary, but should be a no-op and didn't cause any issues. I also decided to call it for all ios versions, although it is only needed on iOS 14+ to avoid forking behavior more. ## Changelog [iOS] [Fixed] - Fix RefreshControl layout when removed from window Pull Request resolved: facebook#31024 Test Plan: Before: https://user-images.githubusercontent.com/2677334/108666197-93ea5a80-74a4-11eb-839b-8a4916967bf8.mov After: https://user-images.githubusercontent.com/2677334/108666223-9ea4ef80-74a4-11eb-8489-4e5d257299c8.mov Reviewed By: shergin Differential Revision: D26590759 Pulled By: PeteTheHeat fbshipit-source-id: b8c06068a24446b261cbeb88ff166289724031f1
…an/0.64-merge-head
…an/0.64-merge-head
…an/0.64-merge-head
Summary: Upgrades the `react-hooks` eslint-rules to `4.2.0` Changelog: [Internal] Reviewed By: GijsWeterings Differential Revision: D26366235 fbshipit-source-id: 04628e8f2a6c56eacba516d877df143c6c81adb8
…an/0.64-merge-head
…an/0.64-merge-head
…an/0.64-merge-head
This is needed after upgrading to v5.0.1-alpha.0 of the CLI tools.
…an/0.64-merge-head
…an/0.64-merge-head
…an/0.64-merge-head
…an/0.64-merge-head
…an/0.64-merge-head
* Add the missing android folder to files in package.json * Fix for submit button disappear bug in comments Co-authored-by: Mayuresh Gharpure <Mayuresh.Gharpure@microsoft.com>
HeyImChris
approved these changes
Oct 25, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Please select one of the following
Summary
Merge facebook/react-native's 0.64-stable branch into react-native-macos's 0.64-stable branch up to v0.64.0 (specifically, ace025d).
These changes were made by repeatedly running git merge and resolving merge conflicts as needed.
Validation