mirror of
https://github.com/facebook/react-native.git
synced 2025-11-01 09:14:26 +00:00
bccbf4d00a41679c8d3ed4db3964f4fa651cd702
25 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Mike Grabowski
|
42dde12aac |
Exclude i386 from valid architectures when building with Hermes on iOS (#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: https://github.com/facebook/react-native/pull/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 |
||
|
Mike Grabowski
|
fdcacd7f76 |
fix: building in release mode for simulator (#30543)
Summary: Fixes https://github.com/facebook/react-native/issues/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 https://github.com/facebook/react-native/issues/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: https://github.com/facebook/react-native/pull/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 |
||
 Janic Duplessis
|
0959ff36d1 |
Move hermes to a separate podspec (#30478)
Summary: Hermes being a subspec of ReactCore causes some build issues when RN is included in 2 different targets. It also causes it to include a lot of additional dependencies that it doesn't need. This moves it to a separate podspec loosely based on other specs in ReactCommon. ## Changelog [iOS] [Fixed] - Move hermes to a separate podspec Pull Request resolved: https://github.com/facebook/react-native/pull/30478 Test Plan: Test that it builds and run properly in an app Reviewed By: fkgozali Differential Revision: D25308237 Pulled By: hramos fbshipit-source-id: b4cc44ea2b1b854831e881dbbf9a2f30f6704001 |
||
 Héctor Ramos
|
c901c1fbce |
Integrate Native Module codegen into Xcode build pipeline (#30449)
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: https://github.com/facebook/react-native/pull/30449 Changelog: [Internal] - Moved codegen invocation out of Podfile and into FBReactNativeSpec Pod Reviewed By: fkgozali Differential Revision: D25138896 fbshipit-source-id: 4779f822459cea2c30fd544eee19a49e8d80153d |
||
|
Héctor Ramos
|
e99b8bbb40 |
Use react-native-codegen@0.0.6 in new app template
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 |
||
 Kevin Gozali
|
58c80d4f8d |
Use codegen from source in default iOS template apps
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 |
||
|
Mike Grabowski
|
c95ee5ac18 |
feat: Enable Hermes to work on iOS (#29914)
Summary: This PR makes it possible to build iOS applications with Hermes. Note that it doesn't work with `use_frameworks!` just yet. Fixes https://github.com/facebook/react-native/issues/27845 (by downgrading iOS deployment target for RCT-Folly to 9.0) Fixes https://github.com/facebook/react-native/issues/28810 (as above) Checklist: - [x] Adjust release scripts to create Hermes bytecode bundle - [x] Release new Hermes npm package that includes iOS files (unreleased right now, if you want to try locally, you have to clone Hermes and `yarn link` its master to this project) - [x] Test on a new React Native application in both Debug and Release (Device) - [x] Test on an RNTester application in both Debug and Release (Device) - [x] Add missing `i386` to Hermes framework and enable Bitcode - [x] Inspect CI failures for possible regressions - [x] Resolve Folly issue as reported https://github.com/facebook/react-native/issues/27845 and https://github.com/facebook/react-native/issues/28810 - [x] Release new Hermes and test against it that everything works ## Changelog [IOS] [FEATURE] - Enable Hermes on iOS [INTERNAL] - Upgrade to CocoaPods 1.10.0 to resolve Xcode 12.0 issues [INTERNAL] - Upgrade to Xcode 12.0 on the CircleCI [INTERNAL] - Fix building RNTester in Release mode [INTERNAL] - Fix build-time errors of `libevent` with `use_frameworks!` [INTERNAL] - Introduce `USE_HERMES` variable and test all RNTester configurations on the CI [INTERNAL] - Do not fetch CocoaPods repository since we're using CDN anyway Pull Request resolved: https://github.com/facebook/react-native/pull/29914 Test Plan: Turn on `hermes_enabled` to true in your `Podfile`, install pods, and run the iOS application. Your app should be running Hermes now. Preview: (note "Engine: Hermes") <img width="395" alt="Screenshot 2020-09-09 at 19 22 32" src="https://user-images.githubusercontent.com/2464966/92631584-d7c01d80-f2d1-11ea-9b40-33d73db96a53.png"> Reviewed By: hramos Differential Revision: D24684845 Pulled By: cpojer fbshipit-source-id: 900cbe3bf9398a6fd4a773d552899a001bf5146b |
||
|
Héctor Ramos
|
d03c0f965e |
Generate FBReactNativeSpec ObjC++ source files using CocoaPods
Summary: Move FBReactNativeSpec codegen invocation to shared `react_native_pods.rb` script and trigger codegen to run as part of `pod install` in both RNTester as well as React Native for iOS projects. These files need to be generated before CocoaPods generates the Pods project, so the codegen is invoked as part of a `pre_install` hook during `pod install`. The codegen hook can now take optional paths to allow it to run within different contexts (as part of a `react-native` repo checkout with access to the codegen source, or as part of a React Native iOS project that depends on the `react-native-codegen` npm package). ## Motivation The FBReactNativeSpec ObjC++ source files (FBReactNativeSpec.h and FBReactNativeSpec-generated.mm) can be generated on demand from the native module specs in `Libraries/` using `react-native-codegen`. They can therefore be removed from the repository, but before we do so, we must ensure they get generated when a React Native iOS workspace is created or updated. Invoking the codegen as part of the `pod install` step that creates a React Native iOS Xcode workspace ensures the specs are available in the following scenarios: * Whenever a new React Native iOS project is created. The `react-native init` command invokes `pod install`. * Whenever a React Native iOS project is upgraded. The `react-native upgrade` command invokes `pod install` as well. * For contributors to the open source project running the RNTester application, the codegen will be invoked when the RNTester workspace is generated by CocoaPods using `pod install` in `packages/rn-tester`. In any other case, the codegen can still be invoked directly via `scripts/generate-native-modules-specs.sh`. > **Note:** > The codegen will only process native modules in React Native's own Libraries directory. Changelog: [iOS][Changed] - Generate FBReactNativeSpec ObjC++ source files using CocoaPods. Reviewed By: fkgozali Differential Revision: D24348111 fbshipit-source-id: d62ae5c6f8ce6358bf96a2801c3cdb3d94dd868d |
||
 Michel Weststrate
|
d8b70b19b3 |
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 |
||
 Eloy Durán
|
941bc0ec19 |
Upstream RN macOS Hermes integration bits (#29748)
Summary: Microsoft’s RN for macOS fork supports the Hermes engine nowadays https://github.com/microsoft/react-native-macos/pull/473. As a longer term work item, we’ve started moving bits that are not invasive for iOS but _are_ a maintenance burden on us—mostly when merging—upstream. Seeing as this one is a recent addition, it seemed like a good candidate to start with. As to the actual changes, these include: * Sharing Android’s Hermes executor with the objc side of the codebase. * Adding a CocoaPods subspec to build the Hermes inspector source and its dependencies (`Folly/Futures`, `libevent`). * Adding the bits to the Xcode build phase script that creates the JS bundle for release builds to compile Hermes bytecode and source-maps… * …coincidentally it turns out that the Xcode build phase script did _not_ by default output source-maps for iOS, which is now fixed too. All of the Hermes bits are automatically enabled, on macOS, when providing the `hermes-engine-darwin` [npm package](https://www.npmjs.com/package/hermes-engine-darwin) and enabling the Hermes pods. ## Changelog [General] [Added] - Upstream RN macOS Hermes integration bits Pull Request resolved: https://github.com/facebook/react-native/pull/29748 Test Plan: Building RNTester for iOS and Android still works as before. To test the actual changes themselves, you’ll have to use the macOS target in RNTester in the macOS fork, or create a new application from `master`: <img width="812" alt="Screenshot 2020-08-18 at 16 55 06" src="https://user-images.githubusercontent.com/2320/90547606-160f6480-e18c-11ea-9a98-edbbaa755800.png"> Reviewed By: TheSavior Differential Revision: D23304618 Pulled By: fkgozali fbshipit-source-id: 4ef0e0f60d909f3c59f9cfc87c667189df656a3b |
||
 Nico Burns
|
dc2df75426 |
Make flipper pods configurations configurable (#29074)
Summary: This PR allows the use_flipper! helper function to be used in projects that have more than just Debug/Release configurations. For example, a project may have DevDebug, DevRelease, ProdDebug, and ProdRelease configurations. These projects can now do: ```ruby use_flipper!(configurations: ['DevDebug', 'ProdDebug']) ``` ## Changelog [iOS][Added] Ability to set which configuration to enable flipper for when using use_flipper! Pull Request resolved: https://github.com/facebook/react-native/pull/29074 Test Plan: I don't know how to run code in this repository, so I copy and pasted this function into the Podfile of an existing project. My complete Podfile is as below: ```ruby # Uncomment the next line to define a global platform for your project platform :ios, '10.0' require_relative '../node_modules/react-native-community/cli-platform-ios/native_modules' project 'marketplace', 'Dev.Debug' => :debug, 'Dev.Release' => :release, 'Prod.Debug' => :debug, 'Prod.Release' => :release def use_flipper!(versions = {}, configurations: ['Debug']) versions['Flipper'] ||= '~> 0.33.1' versions['DoubleConversion'] ||= '1.1.7' versions['Flipper-Folly'] ||= '~> 2.1' versions['Flipper-Glog'] ||= '0.3.6' versions['Flipper-PeerTalk'] ||= '~> 0.0.4' versions['Flipper-RSocket'] ||= '~> 1.0' pod 'FlipperKit', versions['Flipper'], :configurations => configurations pod 'FlipperKit/FlipperKitLayoutPlugin', versions['Flipper'], :configurations => configurations pod 'FlipperKit/SKIOSNetworkPlugin', versions['Flipper'], :configurations => configurations pod 'FlipperKit/FlipperKitUserDefaultsPlugin', versions['Flipper'], :configurations => configurations pod 'FlipperKit/FlipperKitReactPlugin', versions['Flipper'], :configurations => configurations # List all transitive dependencies for FlipperKit pods # to avoid them being linked in Release builds pod 'Flipper', versions['Flipper'], :configurations => configurations pod 'Flipper-DoubleConversion', versions['Flipper-DoubleConversion'], :configurations => configurations pod 'Flipper-Folly', versions['Flipper-Folly'], :configurations => configurations pod 'Flipper-Glog', versions['Flipper-Glog'], :configurations => configurations pod 'Flipper-PeerTalk', versions['Flipper-PeerTalk'], :configurations => configurations pod 'Flipper-RSocket', versions['Flipper-RSocket'], :configurations => configurations pod 'FlipperKit/Core', versions['Flipper'], :configurations => configurations pod 'FlipperKit/CppBridge', versions['Flipper'], :configurations => configurations pod 'FlipperKit/FBCxxFollyDynamicConvert', versions['Flipper'], :configurations => configurations pod 'FlipperKit/FBDefines', versions['Flipper'], :configurations => configurations pod 'FlipperKit/FKPortForwarding', versions['Flipper'], :configurations => configurations pod 'FlipperKit/FlipperKitHighlightOverlay', versions['Flipper'], :configurations => configurations pod 'FlipperKit/FlipperKitLayoutTextSearchable', versions['Flipper'], :configurations => configurations pod 'FlipperKit/FlipperKitNetworkPlugin', versions['Flipper'], :configurations => configurations end # Post Install processing for Flipper def flipper_post_install(installer) installer.pods_project.targets.each do |target| if target.name == 'YogaKit' target.build_configurations.each do |config| config.build_settings['SWIFT_VERSION'] = '4.1' end end end end target 'marketplace' do # Comment the next line if you're not using Swift and don't want to use dynamic frameworks #use_frameworks! pod 'FBLazyVector', :path => '../node_modules/react-native/Libraries/FBLazyVector' pod 'FBReactNativeSpec', :path => '../node_modules/react-native/Libraries/FBReactNativeSpec' pod 'RCTRequired', :path => '../node_modules/react-native/Libraries/RCTRequired' pod 'RCTTypeSafety', :path => '../node_modules/react-native/Libraries/TypeSafety' pod 'React', :path => '../node_modules/react-native/' pod 'React-Core', :path => '../node_modules/react-native/' pod 'React-CoreModules', :path => '../node_modules/react-native/React/CoreModules' pod 'React-Core/DevSupport', :path => '../node_modules/react-native/' pod 'React-RCTActionSheet', :path => '../node_modules/react-native/Libraries/ActionSheetIOS' pod 'React-RCTAnimation', :path => '../node_modules/react-native/Libraries/NativeAnimation' pod 'React-RCTBlob', :path => '../node_modules/react-native/Libraries/Blob' pod 'React-RCTImage', :path => '../node_modules/react-native/Libraries/Image' pod 'React-RCTLinking', :path => '../node_modules/react-native/Libraries/LinkingIOS' pod 'React-RCTNetwork', :path => '../node_modules/react-native/Libraries/Network' pod 'React-RCTSettings', :path => '../node_modules/react-native/Libraries/Settings' pod 'React-RCTText', :path => '../node_modules/react-native/Libraries/Text' pod 'React-RCTVibration', :path => '../node_modules/react-native/Libraries/Vibration' pod 'React-Core/RCTWebSocket', :path => '../node_modules/react-native/' pod 'React-cxxreact', :path => '../node_modules/react-native/ReactCommon/cxxreact' pod 'React-jsi', :path => '../node_modules/react-native/ReactCommon/jsi' pod 'React-jsiexecutor', :path => '../node_modules/react-native/ReactCommon/jsiexecutor' pod 'React-jsinspector', :path => '../node_modules/react-native/ReactCommon/jsinspector' pod 'ReactCommon/callinvoker', :path => '../node_modules/react-native/ReactCommon' pod 'ReactCommon/turbomodule/core', :path => '../node_modules/react-native/ReactCommon' pod 'Yoga', :path => '../node_modules/react-native/ReactCommon/yoga', :modular_headers => true pod 'DoubleConversion', :podspec => '../node_modules/react-native/third-party-podspecs/DoubleConversion.podspec' pod 'glog', :podspec => '../node_modules/react-native/third-party-podspecs/glog.podspec' pod 'Folly', :podspec => '../node_modules/react-native/third-party-podspecs/Folly.podspec' pod 'Intercom', '~> 6.0.0' pod 'RNDeviceInfo', :path => '../node_modules/react-native-device-info' pod 'react-native-netinfo', :podspec => '../node_modules/react-native-community/netinfo/react-native-netinfo.podspec' pod 'BugsnagReactNative', :podspec => '../node_modules/bugsnag-react-native/BugsnagReactNative.podspec' pod 'rn-fetch-blob', :podspec => '../node_modules/rn-fetch-blob/rn-fetch-blob.podspec' use_native_modules! pod 'react-native-intercom', :path => '../node_modules/react-native-intercom' pod 'react-native-image-resizer', :path => '../node_modules/react-native-image-resizer' pod 'RNVectorIcons', :path => '../node_modules/react-native-vector-icons' pod 'react-native-camera', :path => '../node_modules/react-native-camera' pod 'RNCPushNotificationIOS', :path => '../node_modules/react-native-community/push-notification-ios' pod 'RNDateTimePicker', :path => '../node_modules/react-native-community/datetimepicker' # Enables Flipper. # # Note that if you have use_frameworks! enabled, Flipper will not work and # you should disable these next few lines. use_flipper!(configurations: ['Dev.Debug', 'Prod.Debug']) post_install do |installer| flipper_post_install(installer) installer.pods_project.targets.each do |target| # The following is needed to ensure the "archive" step works in XCode. # It removes React & Yoga from the Pods project, as it is already included in the main project. # Without this, you'd see errors when you archive like: # "Multiple commands produce ... libReact.a" # "Multiple commands produce ... libyoga.a" targets_to_ignore = %w(React yoga) if targets_to_ignore.include? target.name target.remove_from_project end end end end ``` I then ran `pod install`: ``` nico:ios/ (dev*) $ pod install [20:14:43] Adding a custom script phase for Pod RNFBApp: [RNFB] Core Configuration Detected React Native module pods for BVLinearGradient, RNCAsyncStorage, RNCPicker, RNCPushNotificationIOS, RNDateTimePicker, RNFBApp, RNFBAuth, RNFBDatabase, RNFBDynamicLinks, RNFBFirestore, RNFBStorage, RNSVG, RNVectorIcons, ReactNativeNavigation, react-native-camera, react-native-cameraroll, react-native-config, react-native-flipper, react-native-get-random-values, react-native-image-resizer, and react-native-intercom Analyzing dependencies Downloading dependencies Generating Pods project Integrating client project Pod installation complete! There are 73 dependencies from the Podfile and 88 total pods installed. [!] use_native_modules! skipped the react-native dependency 'react-native-photo-view'. No podspec file was found. - Check to see if there is an updated version that contains the necessary podspec file - Contact the library maintainers or send them a PR to add a podspec. The react-native-webview podspec is a good example of a package.json driven podspec. See https://github.com/react-native-community/react-native-webview/blob/master/react-native-webview.podspec - If necessary, you can disable autolinking for the dependency and link it manually. See https://github.com/react-native-community/cli/blob/master/docs/autolinking.md#how-can-i-disable-autolinking-for-unsupported-library [!] use_native_modules! skipped the react-native dependency 'detox'. No podspec file was found. - Check to see if there is an updated version that contains the necessary podspec file - Contact the library maintainers or send them a PR to add a podspec. The react-native-webview podspec is a good example of a package.json driven podspec. See https://github.com/react-native-community/react-native-webview/blob/master/react-native-webview.podspec - If necessary, you can disable autolinking for the dependency and link it manually. See https://github.com/react-native-community/cli/blob/master/docs/autolinking.md#how-can-i-disable-autolinking-for-unsupported-library ``` Reviewed By: cpojer Differential Revision: D22795421 Pulled By: passy fbshipit-source-id: 89ba555eadc4918e9ac464a19a318198b237e01e |
||
 Ramanpreet Nara
|
eb2a561ecb |
Rename <ReactCommon/NativeModulePerfLogger.h> to <reactperflogger/NativeModulePerfLogger.h>
Summary: ## Motivation This rename will fix the following CircleCI build failures: - [test_ios_unit_frameworks](https://circleci.com/gh/facebook/react-native/150473?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link) - [test_ios_detox_frameworks](https://circleci.com/gh/facebook/react-native/150474?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link) ## Investigation We have 4 podspec targets that map to the same header namespace (i.e: `header_dir`) `ReactCommon`: - **New:** `React-perflogger`: Directory is `ReactCommon/preflogger`, and contains `NativeModulePerfLogger.{h,cpp}`. - `React-runtimeexecutor`: Directory is `ReactCommon/runtimeexecutor`, and contains only `RuntimeExecutor.h` - `React-callinvoker`: Directory is `ReactCommon/callinvoker`, and contains only `CallInvoker.h` - `ReactCommon/turbomodule/core`: Directory is `ReactCommon/turbomodule`, and contains C++ files, as well has header files. **The problem:** We couldn't import headers from `React-perflogger` in `ReactCommon/turbomodule/core` files. **The cause:** I'm not entirely sure why, but I was able to discern the following two rules by playing around with the podspecs: 1. If your podspec target has a cpp file, it'll generate a framework when `USE_FRAMEWORKS=1`. 2. Two different frameworks cannot map to the same `module_name` or `header_dir`. (Why? No clue. But something breaks silently when this is the case). So, this is what happened when I landed `React-perflogger` (D21443610): 1. The TurboModules code generates the `ReactCommon` framework that uses the `ReactCommon` header namespace. 2. `React-runtimeexecutor` and `React-callinvoker` also used the `ReactCommon` header namespace. However, neither generate a framework because of Rule 1. 3. When I comitted `React-perflogger`, I introduced a second framework that competed with the `ReactCommon` framework (i.e: TurboModules code) for the `ReactCommon` header namespace. Rule 2 violation. ## Thoughts on renaming - `<perflogger/NativeModulePerfLogger.h>` is too generic, and the `perflogger` namepsace is used internally within FB. - `<react/perflogger/NativeModulePerfLogger.h>` matches our fabric header format, but I'm pretty sure that slashes aren't allowed in `header_dir`: I tested this and it didn't work. IIRC, only alphanumeric and underscore are valid characters for `header_dir` or `module_name`. So, I opted to just use `reactperflogger`. Changelog: [Internal] Reviewed By: fkgozali Differential Revision: D21598852 fbshipit-source-id: 60da5d0f7758eaf13907a080b7d8756688f40723 |
||
 Keegan Mendonca
|
2b0208b399 |
Revert D21585006: Rename <ReactCommon/NativeModulePerfLogger.h> to <reactperflogger/NativeModulePerfLogger.h>
Differential Revision: D21585006 Original commit changeset: e3339273af5d fbshipit-source-id: cb4ff227edcc16842c7539bf71c912cd4ec478e0 |
||
|
Ramanpreet Nara
|
9f3c7af400 |
Rename <ReactCommon/NativeModulePerfLogger.h> to <reactperflogger/NativeModulePerfLogger.h>
Summary: ## Motivation This rename will fix the following CircleCI build failures: - [test_ios_unit_frameworks](https://circleci.com/gh/facebook/react-native/150473?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link) - [test_ios_detox_frameworks](https://circleci.com/gh/facebook/react-native/150474?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link) ## Investigation We have 4 podspec targets that map to the same header namespace (i.e: `header_dir`) `ReactCommon`: - **New:** `React-perflogger`: Directory is `ReactCommon/preflogger`, and contains `NativeModulePerfLogger.{h,cpp}`. - `React-runtimeexecutor`: Directory is `ReactCommon/runtimeexecutor`, and contains only `RuntimeExecutor.h` - `React-callinvoker`: Directory is `ReactCommon/callinvoker`, and contains only `CallInvoker.h` - `ReactCommon/turbomodule/core`: Directory is `ReactCommon/turbomodule`, and contains C++ files, as well has header files. **The problem:** We couldn't import headers from `React-perflogger` in `ReactCommon/turbomodule/core` files. **The cause:** I'm not entirely sure why, but I was able to discern the following two rules by playing around with the podspecs: 1. If your podspec target has a cpp file, it'll generate a framework when `USE_FRAMEWORKS=1`. 2. Two different frameworks cannot map to the same `module_name` or `header_dir`. (Why? No clue. But something breaks silently when this is the case). So, this is what happened when I landed `React-perflogger` (D21443610): 1. The TurboModules code generates the `ReactCommon` framework that uses the `ReactCommon` header namespace. 2. `React-runtimeexecutor` and `React-callinvoker` also used the `ReactCommon` header namespace. However, neither generate a framework because of Rule 1. 3. When I comitted `React-perflogger`, I introduced a second framework that competed with the `ReactCommon` framework (i.e: TurboModules code) for the `ReactCommon` header namespace. Rule 2 violation. ## Thoughts on renaming - `<perflogger/NativeModulePerfLogger.h>` is too generic, and the `perflogger` namepsace is used internally within FB. - `<react/perflogger/NativeModulePerfLogger.h>` matches our fabric header format, but I'm pretty sure that slashes aren't allowed in `header_dir`: I tested this and it didn't work. IIRC, only alphanumeric and underscore are valid characters for `header_dir` or `module_name`. So, I opted to just use `reactperflogger`. Changelog: [Internal] Reviewed By: fkgozali Differential Revision: D21585006 fbshipit-source-id: e3339273af5dfd65a1454d87213d1221de6a4651 |
||
|
Ramanpreet Nara
|
0486640571 |
Introduce NativeModulePerfLogger
Summary: ## Description This diff introduces `NativeModulePerfLogger`, its BUCK, Cocoapod, android-ndk targets. This diff also wires up those targets into the React Native bridge and TurboModules targets, so that we get signal on if the code compiles. This diff also introduces `TurboModulePerfLogger`, which is a namespace that holds the `NativeModulePerfLogger` that'll do perf-logging for TurboModules. ## How will perflogging work on iOS? 1. Each application will, during React Native initialization, create a NativeModule perf logger. 2. If TurboModules are enabled, we'll call `TurboModulePerfLogger::setInstance(perfLogger)`. If TurboModules are disabled, we'll call `NativeModulePerfLogger::setInstance(perfLogger)`. 3. TurboModules, when they're created and used, will log events via `TurboModulePerfLogger::getInstance()`. NativeModules (i.e: bridge modules), when they're created and used, will log events via the `NativeModulePerfLogger::getInstance()`. > **Note:** The NativeModule system will log events for non-TurboModules as well. Maybe we should log events for only NativeModules that conform to the `TurboModule` interface, when TurboModules are disabled. This'll ensure a fair comparison between the two systems. ## How will perflogging work on Android? Please see the subsequent diff. allow-large-files Changelog: [Both][Added] - Introduce `NativeModulePerfLogger` Reviewed By: PeteTheHeat Differential Revision: D21318053 fbshipit-source-id: 6ddf5b5a80bdc4076d2dd6588067e2b0ec8c2c6b |
||
 Emily Janzer
|
a4a47b9a1e |
Expose RuntimeExecutor on CatalystInstance (#28851)
Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/28851 This diff creates a RuntimeExecutor that uses the bridge and exposes it on CatalystInstanceImpl. Changelog: [Internal] Reviewed By: mdvacca, RSNara Differential Revision: D21051949 fbshipit-source-id: b3977fc14fa19089f33e297d29cedba0d067526d |
||
|
Eloy Durán
|
7bb1c4e1b8 |
Enable with CocoaPods :configuration (#28796)
Summary: ~~⚠️ Depends on https://github.com/facebook/flipper/pull/1086 and a new Flipper release.~~ Fixes https://github.com/facebook/react-native/commit/17f025bc26da13da795845a3f7daee65563420c0#commitcomment-38831234 Currently user’s are being told to add a definition of the `FB_SONARKIT_ENABLED` macro and examples, including those in stock React Native templates, set this for the user by making use of a `post_install` hook in the user’s `Podfile`. This leads to confusion, fragile code [when a user’s project dir structure deviates from vanilla], and is ultimately not necessary as CocoaPods already has dedicated mechanisms to: * specify build settings (through the `xcconfig` property); * and selectively include certain pods only in certain build configurations (e.g. debug). ## 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] [Changed] - Entirely control Flipper being enabled through inclusion in Podfile and optionally limiting to certain build configurations using the `:configuration` directive. Pull Request resolved: https://github.com/facebook/react-native/pull/28796 Test Plan: Tested using the changes of https://github.com/facebook/flipper/pull/1086 in a new app that uses RN `master`. Reviewed By: priteshrnandgaonkar Differential Revision: D21449754 Pulled By: passy fbshipit-source-id: 9ff7c7f4ffc32b364b1edd82b94e0b80c3997625 |
||
 sunnylqm
|
17f025bc26 |
Upgrade Flipper to 0.37.0 (#28545)
Summary: Bump flipper to 0.37 for both iOS and Android ## Changelog [Android] [Changed] - Upgrade Flipper to 0.37.0 [iOS] [Changed] - Upgrade Flipper to 0.37.0 Pull Request resolved: https://github.com/facebook/react-native/pull/28545 Test Plan: RNTester build pass Reviewed By: rickhanlonii Differential Revision: D20930069 Pulled By: hramos fbshipit-source-id: a7cb719da3e51e6a42d27d5e64bc664398d0d3c5 |
||
 Eli White
|
fb04237b18 |
Revert D21064653: Remove the post install step
Differential Revision: D21064653 Original commit changeset: da56d0754d91 fbshipit-source-id: 1086cfdeca9aa3830370ea115ba7b5f05d3fb124 |
||
 Pritesh Nandgaonkar
|
44beb2a685 |
Remove the post install step (#28651)
Summary: Removes the post install step for Flipper, as the latest version of YogaKit is compatible with swift 5. cc alloy ## 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 --> [Flipper] [Template] - Remove the post install step for Flipper Pull Request resolved: https://github.com/facebook/react-native/pull/28651 Test Plan: Tested a newly created RN app without post install step and it built successfully. Reviewed By: passy Differential Revision: D21064653 Pulled By: priteshrnandgaonkar fbshipit-source-id: da56d0754d918e30a0ebe480c77590f0139d48ac |
||
 Javier Cuevas
|
e5497ca8f6 |
Exclude all FlipperKit transitive dependencies from iOS Release builds (#28504)
Summary: The `:configuration` option from `pod` only affects the specified pod and not its dependencies [1]. Therefore in order to avoid all transitive dependencies being linked in the resulting Release IPA we need to list them in the `Podfile`. Note that this will still build Flipper's pods when doing a Release, but it won't link it in the resulting IPA. [1] https://guides.cocoapods.org/syntax/podfile.html#pod Fixes https://github.com/react-native-community/upgrade-support/issues/28 Related https://github.com/CocoaPods/CocoaPods/issues/9658 ## Changelog * [iOS] [Fixed] - Exclude Flipper from iOS Release builds Pull Request resolved: https://github.com/facebook/react-native/pull/28504 Test Plan: Create a new React Native 0.62 project, run `pod install`, then diff: ``` ProjectName/ios/Pods/Target Support Files/Pods-ProjectName/Pods-ProjectName.debug.xcconfig` ``` and ``` ProjectName/ios/Pods/Target Support Files/Pods-ProjectName/Pods-ProjectName.relaese.xcconfig ```  Reviewed By: passy Differential Revision: D20894406 Pulled By: priteshrnandgaonkar fbshipit-source-id: 680780f0f5a85fd8423b85a271a499bd12f06d00 |
||
|
Ramanpreet Nara
|
9b94a541d8 |
Get CallInvokers from the bridge
Summary: ## Context For now, assume TurboModules doesn't exist. **What happens when we call an async NativeModule method?** Everytime JS calls an async NativeModule method, we don't immediately execute it. The legacy infra pushes the call into some queue managed by `MessageQueue.js`. This queue is "flushed" or "emptied" by the following events: - **Flushed:** A C++ -> JS call. NativeModule async methods can called with an `onSuccess` and/or `onFail` callback(s). Calling `NativeToJsBridge::invokeCallback` to invoke one of these callbacks is one way for ObjC++/C++/Java to call into JS. Another way is via JSModule method calls, which are initiated by `NativeToJsBridge::callFunction`. - **Flushed:** When `JSIExecutor::flush` is called. Since TurboModules don't exist, this only happens when we call `JSIExecutor::loadApplicationScript`. - **Emptied:** When more than 5 ms have passed, and the queue hasn't been flushed/emptied, on the next async NativeModule method call, we add to the queue. Afterwards, we empty it, and invoke all the NativeModule method calls. **So, what's the difference between flushed and emptied?** > Note: These are two terms I just made up, but the distinction is important. If the queue was "flushed", and it contained at least one NativeModule method call, `JsToNativeBridge` dispatches the `onBatchComplete` event. On Android, the UIManager module is the only module that listens to this event. This `onBatchComplete` event doesn't fire if the queue was "emptied". **Why does any of this matter?** 1. TurboModules exist. 2. We need the TurboModules infra to have `JsToNativeBridge` dispatch `onBatchComplete`, which depends on: - **Problem 1:** The queue being flushed on calls into JS from Java/C++/ObjC++. - **Problem 2:** There being queued up NativeModule async method calls when the queue is flushed. In D14656466, fkgozali fixed Problem 1 by making every C++/Java/Obj -> JS call from TurboModules also execute `JSIExecutor::flush()`. This means that, with TurboModules, we flush the NativeModule async method call queue as often as we do without TurboModules. So far, so good. However, we still have one big problem: As we convert more NativeModules to TurboModules, the average size of the queue of NativeModule method calls will become smaller and smaller, because more NativeModule method calls will be TurboModule method calls. This queue will more often be empty than not. Therefore, we'll end up dispatching the `onBatchComplete` event less often with TurboModules enabled. So, somehow, when we're about to flush the NativeModule method call queue, we need `JsToNativeBridge` to understand that we've executed TurboModule method calls in the batch. These calls would have normally been queued, which would have led the queue size to be non-zero. So if, during a batch, some TurboModule async method calls were executed, `JsToNativeBridge` should dispatch `onBatchComplete`. **So, what does this diff do?** 1. Make `Instance` responsible for creating the JS `CallInvoker`. 2. Make `NativeToJsBridge` responsible for creating the native `CallInvoker`. `Instance` calls into `NativeToJsBridge` to get the native `CallInvoker`. 3. Hook up `CatalystInstanceImpl`, the Android bridge, with the new JS `CallInvoker`, and the new native `CallInvoker`. This fixes `onBatchComplete` on Android. iOS work is pending. Changelog: [Android][Fixed] - Ensure `onBatchComplete` is dispatched correctly with TurboModules Reviewed By: mdvacca Differential Revision: D20717931 fbshipit-source-id: bc3ccbd6c135b7f084edbc6ddb4d1e3c0c7e0875 |
||
|
Michel Weststrate
|
85a4b0f5bd |
Bump FlipperKit version on iOS to be compatible with react-native-flipper (#28277)
Summary: This pull request re-applies https://github.com/facebook/react-native/pull/28225, thereby reverting https://github.com/facebook/react-native/commit/4bb17944f18e8ecd20633e49ff143f23210cd976, this time bumping to FlipperKit 0.33.1 which is again compatible with iOS 9 (thanks to https://github.com/facebook/flipper/pull/874) This is the iOS counterpart of https://github.com/facebook/react-native/pull/28275 ## Changelog [iOS] [Changed] - Upgrade Flipper dependency to 0.33.1 Pull Request resolved: https://github.com/facebook/react-native/pull/28277 Test Plan: * Bumped the version in our Flipper / RN integration test app first, that runs on 0.62-rc.5, verified everything still works there. * CI  Reviewed By: mweststrate Differential Revision: D20369106 Pulled By: TheSavior fbshipit-source-id: dfeb0446e7f29684a266eca5d0e29ac42cef2ef3 |
||
|
Michel Weststrate
|
fbb94a30bc |
Bump FlipperKit version on iOS to be compatible with react-native-fli… (#28225)
Summary: This diff updated FlipperKit to be compatible with the latest react-native-flipper version. ## Changelog (nothing changes compared to what is already in the changelog for RN 0.62.0) [iOS][Fixed] - Upgraded FlipperKit to 0.32.2 to ensure compatibility with latest `react-native-flipper` Pull Request resolved: https://github.com/facebook/react-native/pull/28225 Test Plan: Tested by upgrading the ReactNativeFlipperExample (https://github.com/facebook/flipper/tree/master/react-native/ReactNativeFlipperExample) to RN 0.62.0-rc.3 and verified the example plugin works. (In D20221558)  Reviewed By: priteshrnandgaonkar Differential Revision: D20249666 Pulled By: mweststrate fbshipit-source-id: 71a61c4249f8b767c7767d5c6133436c9bc9cf26 |
||
|
Eloy Durán
|
4118d79826 |
Rename autolinking-ios.rb script and bring RNTester and template in line. (#28077)
Summary: Make the script ready for picking in 0.62.0-rc.3. * Rename the script to remove ambiguity. “autolinking” is a CLI feature where 3rd-party pods are automatically discovered: https://github.com/react-native-community/cli/blob/master/docs/autolinking.md * Make the Flipper version of the pods configurable, as requested [here](https://github.com/facebook/react-native/pull/28044#discussion_r378662636). * Make RNTester’s Podfile use the same form as the template–including enabling Flipper by moving the CPP define into the right place in the Xcode project and out of the Podfile. * Get rid of Podfile.lock thrashing by making the default CDN spec source explicit. ## Changelog [iOS] [Changed] - Disambiguate autolinking-ios.rb script from CLI’s “autolinking” feature and bring RNTester & template in line. Pull Request resolved: https://github.com/facebook/react-native/pull/28077 Test Plan: RNTester builds, as does a new application. Reviewed By: PeteTheHeat Differential Revision: D19956392 Pulled By: TheSavior fbshipit-source-id: 6c800ddb646b49fc45c088978e2794cd7b60ea48 |
