Facebook/react-native
1
0
Fork 0
mirror of https://github.com/facebook/react-native.git synced 2025-11-01 09:14:26 +00:00
Code Issues Packages Projects Releases Wiki Activity
20,935 Commits 541 Branches 635 Tags
c19b3ffae96ec57ae0aa143ce66e93f48c4e5301
Commit Graph

16 Commits

Author SHA1 Message Date
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
 2020-08-27 01:18:33 -07:00
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
 2020-07-29 02:51:32 -07:00
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
 2020-05-15 15:25:23 -07:00
Keegan Mendonca 2b0208b399 Revert D21585006: Rename <ReactCommon/NativeModulePerfLogger.h> to <reactperflogger/NativeModulePerfLogger.h> 
Differential Revision:
D21585006

Original commit changeset: e3339273af5d

fbshipit-source-id: cb4ff227edcc16842c7539bf71c912cd4ec478e0
 2020-05-14 21:48:44 -07:00
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
 2020-05-14 20:54:57 -07:00
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
 2020-05-13 20:28:15 -07:00
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
 2020-05-08 16:13:42 -07:00
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
 2020-05-07 08:36:55 -07:00
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
 2020-04-21 17:46:53 -07:00
Eli White fb04237b18 Revert D21064653: Remove the post install step 
Differential Revision:
D21064653

Original commit changeset: da56d0754d91

fbshipit-source-id: 1086cfdeca9aa3830370ea115ba7b5f05d3fb124
 2020-04-16 12:07:09 -07:00
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
 2020-04-16 09:34:52 -07:00
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
```

![image](https://user-images.githubusercontent.com/855995/78337679-a3fa0280-7591-11ea-8142-6f82cbc6be58.png)

Reviewed By: passy

Differential Revision: D20894406

Pulled By: priteshrnandgaonkar

fbshipit-source-id: 680780f0f5a85fd8423b85a271a499bd12f06d00
 2020-04-07 10:11:52 -07:00
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
 2020-04-01 11:39:18 -07:00
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

![Screen Shot 2020-03-10 at 12 12 46](https://user-images.githubusercontent.com/1820292/76311312-94f09f00-62c8-11ea-81db-ced6d16e096b.png)

Reviewed By: mweststrate

Differential Revision: D20369106

Pulled By: TheSavior

fbshipit-source-id: dfeb0446e7f29684a266eca5d0e29ac42cef2ef3
 2020-03-10 14:16:55 -07:00
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)

![Screen Shot 2020-03-04 at 11 26 52](https://user-images.githubusercontent.com/1820292/75875163-18167e80-5e0b-11ea-8a7d-504bb27757db.png)

Reviewed By: priteshrnandgaonkar

Differential Revision: D20249666

Pulled By: mweststrate

fbshipit-source-id: 71a61c4249f8b767c7767d5c6133436c9bc9cf26
 2020-03-04 11:06:47 -08:00
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
 2020-02-19 15:19:26 -08:00