microsoft
/
react-native-macos
зеркало из https://github.com/microsoft/react-native-macos.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
react-native-macos/RNTester/Podfile.lock

549 строки
18 KiB
Plaintext
Исходник Обычный вид История

iOS OSS: check in the Podfile.lock Summary: Should have been checked in previously. No setup change here. Reviewed By: shergin Differential Revision: D7626040 fbshipit-source-id: e7a1a9de70a40a22e39eb3777d1b62c8d7b66381
2018-04-14 03:19:01 +03:00
PODS:
- boost-for-react-native (1.63.0)
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 21:36:50 +03:00
- CocoaAsyncSocket (7.6.4)
@allow-large-files [Flipper][RN] Integrated Flipper in RNTester application Summary: Changelog: [iOS] [Fixed] Integrated Flipper in RNTester application and made sure that flipper connects with RNTester application allow-large-files Reviewed By: rickhanlonii Differential Revision: D19813213 fbshipit-source-id: f0c7a5a42ffaccd488582b0f42ce37aea946c636
2020-02-12 15:46:58 +03:00
- CocoaLibEvent (1.0.0)
Updated the glog library version from 0.3.4 to 0.3.5 (#20811) Summary: While the original reason for this change was because of an issue #20780, with further investigation I concluded that the issue is till present for this combo of versions: glog - 0.3.5 google-cast-sdk - 4.3.1 Downgrading google-cast-sdk to 4.3.0 fixed the build issue. Release Notes: -------------- Updated glog version from 0.3.4 to 0.3.5 for iOS [IOS] [ENHANCEMENT] [GLOG] Pull Request resolved: https://github.com/facebook/react-native/pull/20811 Differential Revision: D9485221 Pulled By: hramos fbshipit-source-id: 65caf0839588384a5229a6165506dc6ef62e5fc5
2018-08-24 00:09:19 +03:00
- DoubleConversion (1.1.6)
TM iOS: Set up CocoaPods specs for the TM specs Summary: This defines various sub specs to support building TurboModules that implement the codegen'ed specs. Reviewed By: PeteTheHeat Differential Revision: D16043221 fbshipit-source-id: 27ed532be929c11c8fe648632da8a72061cbc8b0
2019-07-02 01:12:56 +03:00
- FBLazyVector (1000.0.0)
- FBReactNativeSpec (1000.0.0):
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
- Folly (= 2020.01.13.00)
TM iOS: Set up CocoaPods specs for the TM specs Summary: This defines various sub specs to support building TurboModules that implement the codegen'ed specs. Reviewed By: PeteTheHeat Differential Revision: D16043221 fbshipit-source-id: 27ed532be929c11c8fe648632da8a72061cbc8b0
2019-07-02 01:12:56 +03:00
- RCTRequired (= 1000.0.0)
iOS: Use RCTTypeSafety header namespace instead of React Summary: For better compatibility re: https://github.com/facebook/react-native/pull/25393, this target should just use `RCTTypeSafety` Reviewed By: PeteTheHeat Differential Revision: D16210888 fbshipit-source-id: 6a55d631453cc420909247a7d5a64379587225b7
2019-07-13 00:24:55 +03:00
- RCTTypeSafety (= 1000.0.0)
TM iOS: Set up CocoaPods specs for the TM specs Summary: This defines various sub specs to support building TurboModules that implement the codegen'ed specs. Reviewed By: PeteTheHeat Differential Revision: D16043221 fbshipit-source-id: 27ed532be929c11c8fe648632da8a72061cbc8b0
2019-07-02 01:12:56 +03:00
- React-Core (= 1000.0.0)
iOS: Added missing React-jsi dep for FBReactNativeSpec target Summary: Added missing React-jsi dep for FBReactNativeSpec target. Reviewed By: hramos Differential Revision: D16231696 fbshipit-source-id: 66b051ab54f97da9b71f9479ccd5d59f757d524c
2019-07-13 08:34:14 +03:00
- React-jsi (= 1000.0.0)
TM iOS: refactor header dir for TM Summary: For better cocoapods compatibility, refactored TM podspec to be a subspec of ReactCommon, then use `<ReactCommon/` header prefix for all TM files. Relevant efforts: https://github.com/facebook/react-native/pull/25619 https://github.com/facebook/react-native/pull/25393 Reviewed By: hramos Differential Revision: D16231697 fbshipit-source-id: 38d3418b19978ff54aa0c61b064ac45ac0e1c36c
2019-07-13 08:34:14 +03:00
- ReactCommon/turbomodule/core (= 1000.0.0)
iOS: Fix Animated image crash when CADisplayLink target in RCTWeakProxy is nil Summary: ## Problem When self is nil, this may crash in RCTUIImageViewAnimated.m. ``` _displayLink = [CADisplayLink displayLinkWithTarget:[RCTWeakProxy weakProxyWithTarget:self] selector:selector(displayDidRefresh:)]; ``` ## Fix Replace `RCTWeakProxy` with a concrete class `RCTDisplayWeakRefreshable` that has the displayDidRefresh method, that calls the displayDidRefresh method in its weak target. ### Original Github Issue https://github.com/facebook/react-native/pull/28070#issuecomment-619295254 Changelog: [iOS] [Fixed] - Fix Animated image crash when CADisplayLink target in RCTWeakProxy is nil Reviewed By: shergin Differential Revision: D21419385 fbshipit-source-id: da7c3c38f81ea54f633da7f59359e07680ea2faf
2020-05-13 03:06:24 +03:00
- Flipper (0.41.5):
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-22 03:43:59 +03:00
- Flipper-Folly (~> 2.2)
- Flipper-RSocket (~> 1.1)
@allow-large-files [Flipper][RN] Integrated Flipper in RNTester application Summary: Changelog: [iOS] [Fixed] Integrated Flipper in RNTester application and made sure that flipper connects with RNTester application allow-large-files Reviewed By: rickhanlonii Differential Revision: D19813213 fbshipit-source-id: f0c7a5a42ffaccd488582b0f42ce37aea946c636
2020-02-12 15:46:58 +03:00
- Flipper-DoubleConversion (1.1.7)
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-22 03:43:59 +03:00
- Flipper-Folly (2.2.0):
@allow-large-files [Flipper][RN] Integrated Flipper in RNTester application Summary: Changelog: [iOS] [Fixed] Integrated Flipper in RNTester application and made sure that flipper connects with RNTester application allow-large-files Reviewed By: rickhanlonii Differential Revision: D19813213 fbshipit-source-id: f0c7a5a42ffaccd488582b0f42ce37aea946c636
2020-02-12 15:46:58 +03:00
- boost-for-react-native
- CocoaLibEvent (~> 1.0)
- Flipper-DoubleConversion
- Flipper-Glog
- OpenSSL-Universal (= 1.0.2.19)
- Flipper-Glog (0.3.6)
- Flipper-PeerTalk (0.0.4)
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-22 03:43:59 +03:00
- Flipper-RSocket (1.1.0):
- Flipper-Folly (~> 2.2)
iOS: Fix Animated image crash when CADisplayLink target in RCTWeakProxy is nil Summary: ## Problem When self is nil, this may crash in RCTUIImageViewAnimated.m. ``` _displayLink = [CADisplayLink displayLinkWithTarget:[RCTWeakProxy weakProxyWithTarget:self] selector:selector(displayDidRefresh:)]; ``` ## Fix Replace `RCTWeakProxy` with a concrete class `RCTDisplayWeakRefreshable` that has the displayDidRefresh method, that calls the displayDidRefresh method in its weak target. ### Original Github Issue https://github.com/facebook/react-native/pull/28070#issuecomment-619295254 Changelog: [iOS] [Fixed] - Fix Animated image crash when CADisplayLink target in RCTWeakProxy is nil Reviewed By: shergin Differential Revision: D21419385 fbshipit-source-id: da7c3c38f81ea54f633da7f59359e07680ea2faf
2020-05-13 03:06:24 +03:00
- FlipperKit (0.41.5):
- FlipperKit/Core (= 0.41.5)
- FlipperKit/Core (0.41.5):
- Flipper (~> 0.41.5)
@allow-large-files [Flipper][RN] Integrated Flipper in RNTester application Summary: Changelog: [iOS] [Fixed] Integrated Flipper in RNTester application and made sure that flipper connects with RNTester application allow-large-files Reviewed By: rickhanlonii Differential Revision: D19813213 fbshipit-source-id: f0c7a5a42ffaccd488582b0f42ce37aea946c636
2020-02-12 15:46:58 +03:00
- FlipperKit/CppBridge
- FlipperKit/FBCxxFollyDynamicConvert
- FlipperKit/FBDefines
- FlipperKit/FKPortForwarding
iOS: Fix Animated image crash when CADisplayLink target in RCTWeakProxy is nil Summary: ## Problem When self is nil, this may crash in RCTUIImageViewAnimated.m. ``` _displayLink = [CADisplayLink displayLinkWithTarget:[RCTWeakProxy weakProxyWithTarget:self] selector:selector(displayDidRefresh:)]; ``` ## Fix Replace `RCTWeakProxy` with a concrete class `RCTDisplayWeakRefreshable` that has the displayDidRefresh method, that calls the displayDidRefresh method in its weak target. ### Original Github Issue https://github.com/facebook/react-native/pull/28070#issuecomment-619295254 Changelog: [iOS] [Fixed] - Fix Animated image crash when CADisplayLink target in RCTWeakProxy is nil Reviewed By: shergin Differential Revision: D21419385 fbshipit-source-id: da7c3c38f81ea54f633da7f59359e07680ea2faf
2020-05-13 03:06:24 +03:00
- FlipperKit/CppBridge (0.41.5):
- Flipper (~> 0.41.5)
- FlipperKit/FBCxxFollyDynamicConvert (0.41.5):
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-22 03:43:59 +03:00
- Flipper-Folly (~> 2.2)
iOS: Fix Animated image crash when CADisplayLink target in RCTWeakProxy is nil Summary: ## Problem When self is nil, this may crash in RCTUIImageViewAnimated.m. ``` _displayLink = [CADisplayLink displayLinkWithTarget:[RCTWeakProxy weakProxyWithTarget:self] selector:selector(displayDidRefresh:)]; ``` ## Fix Replace `RCTWeakProxy` with a concrete class `RCTDisplayWeakRefreshable` that has the displayDidRefresh method, that calls the displayDidRefresh method in its weak target. ### Original Github Issue https://github.com/facebook/react-native/pull/28070#issuecomment-619295254 Changelog: [iOS] [Fixed] - Fix Animated image crash when CADisplayLink target in RCTWeakProxy is nil Reviewed By: shergin Differential Revision: D21419385 fbshipit-source-id: da7c3c38f81ea54f633da7f59359e07680ea2faf
2020-05-13 03:06:24 +03:00
- FlipperKit/FBDefines (0.41.5)
- FlipperKit/FKPortForwarding (0.41.5):
@allow-large-files [Flipper][RN] Integrated Flipper in RNTester application Summary: Changelog: [iOS] [Fixed] Integrated Flipper in RNTester application and made sure that flipper connects with RNTester application allow-large-files Reviewed By: rickhanlonii Differential Revision: D19813213 fbshipit-source-id: f0c7a5a42ffaccd488582b0f42ce37aea946c636
2020-02-12 15:46:58 +03:00
- CocoaAsyncSocket (~> 7.6)
- Flipper-PeerTalk (~> 0.0.4)
iOS: Fix Animated image crash when CADisplayLink target in RCTWeakProxy is nil Summary: ## Problem When self is nil, this may crash in RCTUIImageViewAnimated.m. ``` _displayLink = [CADisplayLink displayLinkWithTarget:[RCTWeakProxy weakProxyWithTarget:self] selector:selector(displayDidRefresh:)]; ``` ## Fix Replace `RCTWeakProxy` with a concrete class `RCTDisplayWeakRefreshable` that has the displayDidRefresh method, that calls the displayDidRefresh method in its weak target. ### Original Github Issue https://github.com/facebook/react-native/pull/28070#issuecomment-619295254 Changelog: [iOS] [Fixed] - Fix Animated image crash when CADisplayLink target in RCTWeakProxy is nil Reviewed By: shergin Differential Revision: D21419385 fbshipit-source-id: da7c3c38f81ea54f633da7f59359e07680ea2faf
2020-05-13 03:06:24 +03:00
- FlipperKit/FlipperKitHighlightOverlay (0.41.5)
- FlipperKit/FlipperKitLayoutPlugin (0.41.5):
@allow-large-files [Flipper][RN] Integrated Flipper in RNTester application Summary: Changelog: [iOS] [Fixed] Integrated Flipper in RNTester application and made sure that flipper connects with RNTester application allow-large-files Reviewed By: rickhanlonii Differential Revision: D19813213 fbshipit-source-id: f0c7a5a42ffaccd488582b0f42ce37aea946c636
2020-02-12 15:46:58 +03:00
- FlipperKit/Core
- FlipperKit/FlipperKitHighlightOverlay
- FlipperKit/FlipperKitLayoutTextSearchable
- YogaKit (~> 1.18)
iOS: Fix Animated image crash when CADisplayLink target in RCTWeakProxy is nil Summary: ## Problem When self is nil, this may crash in RCTUIImageViewAnimated.m. ``` _displayLink = [CADisplayLink displayLinkWithTarget:[RCTWeakProxy weakProxyWithTarget:self] selector:selector(displayDidRefresh:)]; ``` ## Fix Replace `RCTWeakProxy` with a concrete class `RCTDisplayWeakRefreshable` that has the displayDidRefresh method, that calls the displayDidRefresh method in its weak target. ### Original Github Issue https://github.com/facebook/react-native/pull/28070#issuecomment-619295254 Changelog: [iOS] [Fixed] - Fix Animated image crash when CADisplayLink target in RCTWeakProxy is nil Reviewed By: shergin Differential Revision: D21419385 fbshipit-source-id: da7c3c38f81ea54f633da7f59359e07680ea2faf
2020-05-13 03:06:24 +03:00
- FlipperKit/FlipperKitLayoutTextSearchable (0.41.5)
- FlipperKit/FlipperKitNetworkPlugin (0.41.5):
@allow-large-files [Flipper][RN] Integrated Flipper in RNTester application Summary: Changelog: [iOS] [Fixed] Integrated Flipper in RNTester application and made sure that flipper connects with RNTester application allow-large-files Reviewed By: rickhanlonii Differential Revision: D19813213 fbshipit-source-id: f0c7a5a42ffaccd488582b0f42ce37aea946c636
2020-02-12 15:46:58 +03:00
- FlipperKit/Core
iOS: Fix Animated image crash when CADisplayLink target in RCTWeakProxy is nil Summary: ## Problem When self is nil, this may crash in RCTUIImageViewAnimated.m. ``` _displayLink = [CADisplayLink displayLinkWithTarget:[RCTWeakProxy weakProxyWithTarget:self] selector:selector(displayDidRefresh:)]; ``` ## Fix Replace `RCTWeakProxy` with a concrete class `RCTDisplayWeakRefreshable` that has the displayDidRefresh method, that calls the displayDidRefresh method in its weak target. ### Original Github Issue https://github.com/facebook/react-native/pull/28070#issuecomment-619295254 Changelog: [iOS] [Fixed] - Fix Animated image crash when CADisplayLink target in RCTWeakProxy is nil Reviewed By: shergin Differential Revision: D21419385 fbshipit-source-id: da7c3c38f81ea54f633da7f59359e07680ea2faf
2020-05-13 03:06:24 +03:00
- FlipperKit/FlipperKitReactPlugin (0.41.5):
@allow-large-files [Flipper][RN] Integrated Flipper in RNTester application Summary: Changelog: [iOS] [Fixed] Integrated Flipper in RNTester application and made sure that flipper connects with RNTester application allow-large-files Reviewed By: rickhanlonii Differential Revision: D19813213 fbshipit-source-id: f0c7a5a42ffaccd488582b0f42ce37aea946c636
2020-02-12 15:46:58 +03:00
- FlipperKit/Core
iOS: Fix Animated image crash when CADisplayLink target in RCTWeakProxy is nil Summary: ## Problem When self is nil, this may crash in RCTUIImageViewAnimated.m. ``` _displayLink = [CADisplayLink displayLinkWithTarget:[RCTWeakProxy weakProxyWithTarget:self] selector:selector(displayDidRefresh:)]; ``` ## Fix Replace `RCTWeakProxy` with a concrete class `RCTDisplayWeakRefreshable` that has the displayDidRefresh method, that calls the displayDidRefresh method in its weak target. ### Original Github Issue https://github.com/facebook/react-native/pull/28070#issuecomment-619295254 Changelog: [iOS] [Fixed] - Fix Animated image crash when CADisplayLink target in RCTWeakProxy is nil Reviewed By: shergin Differential Revision: D21419385 fbshipit-source-id: da7c3c38f81ea54f633da7f59359e07680ea2faf
2020-05-13 03:06:24 +03:00
- FlipperKit/FlipperKitUserDefaultsPlugin (0.41.5):
@allow-large-files [Flipper][RN] Integrated Flipper in RNTester application Summary: Changelog: [iOS] [Fixed] Integrated Flipper in RNTester application and made sure that flipper connects with RNTester application allow-large-files Reviewed By: rickhanlonii Differential Revision: D19813213 fbshipit-source-id: f0c7a5a42ffaccd488582b0f42ce37aea946c636
2020-02-12 15:46:58 +03:00
- FlipperKit/Core
iOS: Fix Animated image crash when CADisplayLink target in RCTWeakProxy is nil Summary: ## Problem When self is nil, this may crash in RCTUIImageViewAnimated.m. ``` _displayLink = [CADisplayLink displayLinkWithTarget:[RCTWeakProxy weakProxyWithTarget:self] selector:selector(displayDidRefresh:)]; ``` ## Fix Replace `RCTWeakProxy` with a concrete class `RCTDisplayWeakRefreshable` that has the displayDidRefresh method, that calls the displayDidRefresh method in its weak target. ### Original Github Issue https://github.com/facebook/react-native/pull/28070#issuecomment-619295254 Changelog: [iOS] [Fixed] - Fix Animated image crash when CADisplayLink target in RCTWeakProxy is nil Reviewed By: shergin Differential Revision: D21419385 fbshipit-source-id: da7c3c38f81ea54f633da7f59359e07680ea2faf
2020-05-13 03:06:24 +03:00
- FlipperKit/SKIOSNetworkPlugin (0.41.5):
@allow-large-files [Flipper][RN] Integrated Flipper in RNTester application Summary: Changelog: [iOS] [Fixed] Integrated Flipper in RNTester application and made sure that flipper connects with RNTester application allow-large-files Reviewed By: rickhanlonii Differential Revision: D19813213 fbshipit-source-id: f0c7a5a42ffaccd488582b0f42ce37aea946c636
2020-02-12 15:46:58 +03:00
- FlipperKit/Core
- FlipperKit/FlipperKitNetworkPlugin
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
- Folly (2020.01.13.00):
Fabric: working podspecs & works in RNTester (#23803) Summary: This is the couple of hacks I used after I finished #23802 in order to get fabric working on RNTester. This is inspired from prior work by kmagiera. The goal of this PR is to show others what I’m struggling with, and to eventually merge it sans hacks. - Yarn Install - Uncomment the commented out pods in RNTester's pod file - Open RNTesterPods workspace - Run App - this is only for pods, the non-pod RNTester will no longer work until updated with fabric too. - `SurfaceHostingView` & `SurfaceHostingProxyRootView` both try to start the surface immediately, this leads to a race condition due to the javascript not having loaded yet, the hack here is: 1. Swizzle the `start` method on `RCTFabricSurface` to no-op when called. 2. Add observer for `RCTJavaScriptDidLoadNotification` 3. Call private method `_startAllSurfaces` on `_surfacePresenter` in AppDelegate when we receive `RCTJavaScriptDidLoadNotification`. [General] [Added] - Use Fabric in RNTester Pull Request resolved: https://github.com/facebook/react-native/pull/23803 Reviewed By: shergin, mdvacca Differential Revision: D14450726 Pulled By: fkgozali fbshipit-source-id: 8ae2d48634fecb60db539aaf0a2c89ba1f572c27
2019-03-16 09:56:17 +03:00
- boost-for-react-native
- DoubleConversion
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
- Folly/Default (= 2020.01.13.00)
Fabric: working podspecs & works in RNTester (#23803) Summary: This is the couple of hacks I used after I finished #23802 in order to get fabric working on RNTester. This is inspired from prior work by kmagiera. The goal of this PR is to show others what I’m struggling with, and to eventually merge it sans hacks. - Yarn Install - Uncomment the commented out pods in RNTester's pod file - Open RNTesterPods workspace - Run App - this is only for pods, the non-pod RNTester will no longer work until updated with fabric too. - `SurfaceHostingView` & `SurfaceHostingProxyRootView` both try to start the surface immediately, this leads to a race condition due to the javascript not having loaded yet, the hack here is: 1. Swizzle the `start` method on `RCTFabricSurface` to no-op when called. 2. Add observer for `RCTJavaScriptDidLoadNotification` 3. Call private method `_startAllSurfaces` on `_surfacePresenter` in AppDelegate when we receive `RCTJavaScriptDidLoadNotification`. [General] [Added] - Use Fabric in RNTester Pull Request resolved: https://github.com/facebook/react-native/pull/23803 Reviewed By: shergin, mdvacca Differential Revision: D14450726 Pulled By: fkgozali fbshipit-source-id: 8ae2d48634fecb60db539aaf0a2c89ba1f572c27
2019-03-16 09:56:17 +03:00
- glog
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
- Folly/Default (2020.01.13.00):
iOS OSS: check in the Podfile.lock Summary: Should have been checked in previously. No setup change here. Reviewed By: shergin Differential Revision: D7626040 fbshipit-source-id: e7a1a9de70a40a22e39eb3777d1b62c8d7b66381
2018-04-14 03:19:01 +03:00
- boost-for-react-native
- DoubleConversion
- glog
Updated the glog library version from 0.3.4 to 0.3.5 (#20811) Summary: While the original reason for this change was because of an issue #20780, with further investigation I concluded that the issue is till present for this combo of versions: glog - 0.3.5 google-cast-sdk - 4.3.1 Downgrading google-cast-sdk to 4.3.0 fixed the build issue. Release Notes: -------------- Updated glog version from 0.3.4 to 0.3.5 for iOS [IOS] [ENHANCEMENT] [GLOG] Pull Request resolved: https://github.com/facebook/react-native/pull/20811 Differential Revision: D9485221 Pulled By: hramos fbshipit-source-id: 65caf0839588384a5229a6165506dc6ef62e5fc5
2018-08-24 00:09:19 +03:00
- glog (0.3.5)
@allow-large-files [Flipper][RN] Integrated Flipper in RNTester application Summary: Changelog: [iOS] [Fixed] Integrated Flipper in RNTester application and made sure that flipper connects with RNTester application allow-large-files Reviewed By: rickhanlonii Differential Revision: D19813213 fbshipit-source-id: f0c7a5a42ffaccd488582b0f42ce37aea946c636
2020-02-12 15:46:58 +03:00
- OpenSSL-Universal (1.0.2.19):
- OpenSSL-Universal/Static (= 1.0.2.19)
- OpenSSL-Universal/Static (1.0.2.19)
TM iOS: Set up CocoaPods specs for the TM specs Summary: This defines various sub specs to support building TurboModules that implement the codegen'ed specs. Reviewed By: PeteTheHeat Differential Revision: D16043221 fbshipit-source-id: 27ed532be929c11c8fe648632da8a72061cbc8b0
2019-07-02 01:12:56 +03:00
- RCTRequired (1000.0.0)
iOS: Use RCTTypeSafety header namespace instead of React Summary: For better compatibility re: https://github.com/facebook/react-native/pull/25393, this target should just use `RCTTypeSafety` Reviewed By: PeteTheHeat Differential Revision: D16210888 fbshipit-source-id: 6a55d631453cc420909247a7d5a64379587225b7
2019-07-13 00:24:55 +03:00
- RCTTypeSafety (1000.0.0):
- FBLazyVector (= 1000.0.0)
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
- Folly (= 2020.01.13.00)
iOS: Use RCTTypeSafety header namespace instead of React Summary: For better compatibility re: https://github.com/facebook/react-native/pull/25393, this target should just use `RCTTypeSafety` Reviewed By: PeteTheHeat Differential Revision: D16210888 fbshipit-source-id: 6a55d631453cc420909247a7d5a64379587225b7
2019-07-13 00:24:55 +03:00
- RCTRequired (= 1000.0.0)
- React-Core (= 1000.0.0)
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
- React (1000.0.0):
- React-Core (= 1000.0.0)
Remove 's.static_framework = true' requirement for podspec (#25816) Summary: As part of the fix for https://github.com/facebook/react-native/issues/25349 I added `s.static_framework = true` to each podspec in repo (see https://github.com/facebook/react-native/pull/25619#discussion_r306993309 for more context). This was required to ensure the existing conditional compilation with `#if RCT_DEV` and `__has_include` still worked correctly when `use_frameworks!` is enabled. However, fkgozali pointed out that it would be ideal if we didn't have this requirement as it could make life difficult for third-party libraries. This removes the requirement by moving `React-DevSupport.podspec` and `React-RCTWebSocket.podspec` into `React-Core.podspec` as subspecs. This means the symbols are present when `React-Core.podspec` is built dynamically so `s.static_framework = true` isn't required. This means that any `Podfile` that refers to `React-DevSupport` or `React-RCTWebSocket` will need to be updated to avoid errors. ## Changelog I don't think this needs a changelog entry since its just a refinement of https://github.com/facebook/react-native/pull/25619. Pull Request resolved: https://github.com/facebook/react-native/pull/25816 Test Plan: Check `RNTesterPods` still works both with and without `use_frameworks!`: 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: hramos Differential Revision: D16495030 Pulled By: fkgozali fbshipit-source-id: 2708ac9fd20cd04cb0aea61b2e8ab0d931dfb6d5
2019-07-25 21:42:49 +03:00
- React-Core/DevSupport (= 1000.0.0)
- React-Core/RCTWebSocket (= 1000.0.0)
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
- React-RCTActionSheet (= 1000.0.0)
- React-RCTAnimation (= 1000.0.0)
- React-RCTBlob (= 1000.0.0)
- React-RCTImage (= 1000.0.0)
- React-RCTLinking (= 1000.0.0)
- React-RCTNetwork (= 1000.0.0)
- React-RCTSettings (= 1000.0.0)
- React-RCTText (= 1000.0.0)
- React-RCTVibration (= 1000.0.0)
- React-ART (1000.0.0):
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- React-Core/ARTHeaders (= 1000.0.0)
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 21:36:50 +03:00
- React-callinvoker (1000.0.0)
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
- React-Core (1000.0.0):
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
- Folly (= 2020.01.13.00)
CocoaPods frameworks compatibility: Step 1 (#25496) Summary: This is the first step towards fixing https://github.com/facebook/react-native/issues/25349. These are the changes to the podspec to correctly update dependencies and build config that will cause any breaking change for users or libraries. I am breaking these changes out from https://github.com/facebook/react-native/pull/25393 as suggested by fkgozali in https://github.com/facebook/react-native/pull/25393#issuecomment-508322884. These are the changes: - Made C++ headers in `React-Core` private by default so that ObjC files can import the module without failures. - Reduced the number of `yoga` headers that are exposed for the same reason as above. As far as I can see this doesn't cause issues but we can find another solution if it does. - Adding some missing dependencies to fix undefined symbols errors. - Added `DoubleConversion` to `HEADER_SEARCH_PATHS` where it was missing. ## Changelog [iOS] [Fixed] - Updated podspecs for improved compatibility with different install types. Pull Request resolved: https://github.com/facebook/react-native/pull/25496 Test Plan: Everything should work exactly as before. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which points at this branch to show that it is still working `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout podspec-updates` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. Reviewed By: mmmulani Differential Revision: D16167346 Pulled By: fkgozali fbshipit-source-id: 1917b2f8779cb172362a457fb3fce686c55056d3
2019-07-10 20:18:03 +03:00
- glog
- React-Core/Default (= 1000.0.0)
- React-cxxreact (= 1000.0.0)
- React-jsi (= 1000.0.0)
- React-jsiexecutor (= 1000.0.0)
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-14 06:24:37 +03:00
- React-perflogger (= 1000.0.0)
Change podspec name of yoga to Yoga Summary: Needed to capitalize the name, since this is the convention used elsewhere too ## Changelog: [iOS] [Changed] - Renamed yoga podspec to Yoga Reviewed By: shergin Differential Revision: D17127104 fbshipit-source-id: 14047bf452edda000037701f4ba7f4a02a0e717b
2019-08-30 17:10:51 +03:00
- Yoga
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- React-Core/ARTHeaders (1000.0.0):
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
- Folly (= 2020.01.13.00)
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- glog
- React-Core/Default
- React-cxxreact (= 1000.0.0)
- React-jsi (= 1000.0.0)
- React-jsiexecutor (= 1000.0.0)
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-14 06:24:37 +03:00
- React-perflogger (= 1000.0.0)
Change podspec name of yoga to Yoga Summary: Needed to capitalize the name, since this is the convention used elsewhere too ## Changelog: [iOS] [Changed] - Renamed yoga podspec to Yoga Reviewed By: shergin Differential Revision: D17127104 fbshipit-source-id: 14047bf452edda000037701f4ba7f4a02a0e717b
2019-08-30 17:10:51 +03:00
- Yoga
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- React-Core/CoreModulesHeaders (1000.0.0):
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
- Folly (= 2020.01.13.00)
CocoaPods frameworks compatibility: Step 1 (#25496) Summary: This is the first step towards fixing https://github.com/facebook/react-native/issues/25349. These are the changes to the podspec to correctly update dependencies and build config that will cause any breaking change for users or libraries. I am breaking these changes out from https://github.com/facebook/react-native/pull/25393 as suggested by fkgozali in https://github.com/facebook/react-native/pull/25393#issuecomment-508322884. These are the changes: - Made C++ headers in `React-Core` private by default so that ObjC files can import the module without failures. - Reduced the number of `yoga` headers that are exposed for the same reason as above. As far as I can see this doesn't cause issues but we can find another solution if it does. - Adding some missing dependencies to fix undefined symbols errors. - Added `DoubleConversion` to `HEADER_SEARCH_PATHS` where it was missing. ## Changelog [iOS] [Fixed] - Updated podspecs for improved compatibility with different install types. Pull Request resolved: https://github.com/facebook/react-native/pull/25496 Test Plan: Everything should work exactly as before. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which points at this branch to show that it is still working `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout podspec-updates` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. Reviewed By: mmmulani Differential Revision: D16167346 Pulled By: fkgozali fbshipit-source-id: 1917b2f8779cb172362a457fb3fce686c55056d3
2019-07-10 20:18:03 +03:00
- glog
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- React-Core/Default
CocoaPods frameworks compatibility: Step 1 (#25496) Summary: This is the first step towards fixing https://github.com/facebook/react-native/issues/25349. These are the changes to the podspec to correctly update dependencies and build config that will cause any breaking change for users or libraries. I am breaking these changes out from https://github.com/facebook/react-native/pull/25393 as suggested by fkgozali in https://github.com/facebook/react-native/pull/25393#issuecomment-508322884. These are the changes: - Made C++ headers in `React-Core` private by default so that ObjC files can import the module without failures. - Reduced the number of `yoga` headers that are exposed for the same reason as above. As far as I can see this doesn't cause issues but we can find another solution if it does. - Adding some missing dependencies to fix undefined symbols errors. - Added `DoubleConversion` to `HEADER_SEARCH_PATHS` where it was missing. ## Changelog [iOS] [Fixed] - Updated podspecs for improved compatibility with different install types. Pull Request resolved: https://github.com/facebook/react-native/pull/25496 Test Plan: Everything should work exactly as before. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which points at this branch to show that it is still working `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout podspec-updates` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. Reviewed By: mmmulani Differential Revision: D16167346 Pulled By: fkgozali fbshipit-source-id: 1917b2f8779cb172362a457fb3fce686c55056d3
2019-07-10 20:18:03 +03:00
- React-cxxreact (= 1000.0.0)
- React-jsi (= 1000.0.0)
- React-jsiexecutor (= 1000.0.0)
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-14 06:24:37 +03:00
- React-perflogger (= 1000.0.0)
Change podspec name of yoga to Yoga Summary: Needed to capitalize the name, since this is the convention used elsewhere too ## Changelog: [iOS] [Changed] - Renamed yoga podspec to Yoga Reviewed By: shergin Differential Revision: D17127104 fbshipit-source-id: 14047bf452edda000037701f4ba7f4a02a0e717b
2019-08-30 17:10:51 +03:00
- Yoga
CocoaPods frameworks compatibility: Step 1 (#25496) Summary: This is the first step towards fixing https://github.com/facebook/react-native/issues/25349. These are the changes to the podspec to correctly update dependencies and build config that will cause any breaking change for users or libraries. I am breaking these changes out from https://github.com/facebook/react-native/pull/25393 as suggested by fkgozali in https://github.com/facebook/react-native/pull/25393#issuecomment-508322884. These are the changes: - Made C++ headers in `React-Core` private by default so that ObjC files can import the module without failures. - Reduced the number of `yoga` headers that are exposed for the same reason as above. As far as I can see this doesn't cause issues but we can find another solution if it does. - Adding some missing dependencies to fix undefined symbols errors. - Added `DoubleConversion` to `HEADER_SEARCH_PATHS` where it was missing. ## Changelog [iOS] [Fixed] - Updated podspecs for improved compatibility with different install types. Pull Request resolved: https://github.com/facebook/react-native/pull/25496 Test Plan: Everything should work exactly as before. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which points at this branch to show that it is still working `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout podspec-updates` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. Reviewed By: mmmulani Differential Revision: D16167346 Pulled By: fkgozali fbshipit-source-id: 1917b2f8779cb172362a457fb3fce686c55056d3
2019-07-10 20:18:03 +03:00
- React-Core/Default (1000.0.0):
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
- Folly (= 2020.01.13.00)
CocoaPods frameworks compatibility: Step 1 (#25496) Summary: This is the first step towards fixing https://github.com/facebook/react-native/issues/25349. These are the changes to the podspec to correctly update dependencies and build config that will cause any breaking change for users or libraries. I am breaking these changes out from https://github.com/facebook/react-native/pull/25393 as suggested by fkgozali in https://github.com/facebook/react-native/pull/25393#issuecomment-508322884. These are the changes: - Made C++ headers in `React-Core` private by default so that ObjC files can import the module without failures. - Reduced the number of `yoga` headers that are exposed for the same reason as above. As far as I can see this doesn't cause issues but we can find another solution if it does. - Adding some missing dependencies to fix undefined symbols errors. - Added `DoubleConversion` to `HEADER_SEARCH_PATHS` where it was missing. ## Changelog [iOS] [Fixed] - Updated podspecs for improved compatibility with different install types. Pull Request resolved: https://github.com/facebook/react-native/pull/25496 Test Plan: Everything should work exactly as before. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which points at this branch to show that it is still working `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout podspec-updates` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. Reviewed By: mmmulani Differential Revision: D16167346 Pulled By: fkgozali fbshipit-source-id: 1917b2f8779cb172362a457fb3fce686c55056d3
2019-07-10 20:18:03 +03:00
- glog
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
- React-cxxreact (= 1000.0.0)
CocoaPods frameworks compatibility: Step 1 (#25496) Summary: This is the first step towards fixing https://github.com/facebook/react-native/issues/25349. These are the changes to the podspec to correctly update dependencies and build config that will cause any breaking change for users or libraries. I am breaking these changes out from https://github.com/facebook/react-native/pull/25393 as suggested by fkgozali in https://github.com/facebook/react-native/pull/25393#issuecomment-508322884. These are the changes: - Made C++ headers in `React-Core` private by default so that ObjC files can import the module without failures. - Reduced the number of `yoga` headers that are exposed for the same reason as above. As far as I can see this doesn't cause issues but we can find another solution if it does. - Adding some missing dependencies to fix undefined symbols errors. - Added `DoubleConversion` to `HEADER_SEARCH_PATHS` where it was missing. ## Changelog [iOS] [Fixed] - Updated podspecs for improved compatibility with different install types. Pull Request resolved: https://github.com/facebook/react-native/pull/25496 Test Plan: Everything should work exactly as before. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which points at this branch to show that it is still working `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout podspec-updates` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. Reviewed By: mmmulani Differential Revision: D16167346 Pulled By: fkgozali fbshipit-source-id: 1917b2f8779cb172362a457fb3fce686c55056d3
2019-07-10 20:18:03 +03:00
- React-jsi (= 1000.0.0)
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
- React-jsiexecutor (= 1000.0.0)
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-14 06:24:37 +03:00
- React-perflogger (= 1000.0.0)
Change podspec name of yoga to Yoga Summary: Needed to capitalize the name, since this is the convention used elsewhere too ## Changelog: [iOS] [Changed] - Renamed yoga podspec to Yoga Reviewed By: shergin Differential Revision: D17127104 fbshipit-source-id: 14047bf452edda000037701f4ba7f4a02a0e717b
2019-08-30 17:10:51 +03:00
- Yoga
Remove 's.static_framework = true' requirement for podspec (#25816) Summary: As part of the fix for https://github.com/facebook/react-native/issues/25349 I added `s.static_framework = true` to each podspec in repo (see https://github.com/facebook/react-native/pull/25619#discussion_r306993309 for more context). This was required to ensure the existing conditional compilation with `#if RCT_DEV` and `__has_include` still worked correctly when `use_frameworks!` is enabled. However, fkgozali pointed out that it would be ideal if we didn't have this requirement as it could make life difficult for third-party libraries. This removes the requirement by moving `React-DevSupport.podspec` and `React-RCTWebSocket.podspec` into `React-Core.podspec` as subspecs. This means the symbols are present when `React-Core.podspec` is built dynamically so `s.static_framework = true` isn't required. This means that any `Podfile` that refers to `React-DevSupport` or `React-RCTWebSocket` will need to be updated to avoid errors. ## Changelog I don't think this needs a changelog entry since its just a refinement of https://github.com/facebook/react-native/pull/25619. Pull Request resolved: https://github.com/facebook/react-native/pull/25816 Test Plan: Check `RNTesterPods` still works both with and without `use_frameworks!`: 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: hramos Differential Revision: D16495030 Pulled By: fkgozali fbshipit-source-id: 2708ac9fd20cd04cb0aea61b2e8ab0d931dfb6d5
2019-07-25 21:42:49 +03:00
- React-Core/DevSupport (1000.0.0):
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
- Folly (= 2020.01.13.00)
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- glog
Remove 's.static_framework = true' requirement for podspec (#25816) Summary: As part of the fix for https://github.com/facebook/react-native/issues/25349 I added `s.static_framework = true` to each podspec in repo (see https://github.com/facebook/react-native/pull/25619#discussion_r306993309 for more context). This was required to ensure the existing conditional compilation with `#if RCT_DEV` and `__has_include` still worked correctly when `use_frameworks!` is enabled. However, fkgozali pointed out that it would be ideal if we didn't have this requirement as it could make life difficult for third-party libraries. This removes the requirement by moving `React-DevSupport.podspec` and `React-RCTWebSocket.podspec` into `React-Core.podspec` as subspecs. This means the symbols are present when `React-Core.podspec` is built dynamically so `s.static_framework = true` isn't required. This means that any `Podfile` that refers to `React-DevSupport` or `React-RCTWebSocket` will need to be updated to avoid errors. ## Changelog I don't think this needs a changelog entry since its just a refinement of https://github.com/facebook/react-native/pull/25619. Pull Request resolved: https://github.com/facebook/react-native/pull/25816 Test Plan: Check `RNTesterPods` still works both with and without `use_frameworks!`: 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: hramos Differential Revision: D16495030 Pulled By: fkgozali fbshipit-source-id: 2708ac9fd20cd04cb0aea61b2e8ab0d931dfb6d5
2019-07-25 21:42:49 +03:00
- React-Core/Default (= 1000.0.0)
- React-Core/RCTWebSocket (= 1000.0.0)
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- React-cxxreact (= 1000.0.0)
- React-jsi (= 1000.0.0)
- React-jsiexecutor (= 1000.0.0)
Remove 's.static_framework = true' requirement for podspec (#25816) Summary: As part of the fix for https://github.com/facebook/react-native/issues/25349 I added `s.static_framework = true` to each podspec in repo (see https://github.com/facebook/react-native/pull/25619#discussion_r306993309 for more context). This was required to ensure the existing conditional compilation with `#if RCT_DEV` and `__has_include` still worked correctly when `use_frameworks!` is enabled. However, fkgozali pointed out that it would be ideal if we didn't have this requirement as it could make life difficult for third-party libraries. This removes the requirement by moving `React-DevSupport.podspec` and `React-RCTWebSocket.podspec` into `React-Core.podspec` as subspecs. This means the symbols are present when `React-Core.podspec` is built dynamically so `s.static_framework = true` isn't required. This means that any `Podfile` that refers to `React-DevSupport` or `React-RCTWebSocket` will need to be updated to avoid errors. ## Changelog I don't think this needs a changelog entry since its just a refinement of https://github.com/facebook/react-native/pull/25619. Pull Request resolved: https://github.com/facebook/react-native/pull/25816 Test Plan: Check `RNTesterPods` still works both with and without `use_frameworks!`: 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: hramos Differential Revision: D16495030 Pulled By: fkgozali fbshipit-source-id: 2708ac9fd20cd04cb0aea61b2e8ab0d931dfb6d5
2019-07-25 21:42:49 +03:00
- React-jsinspector (= 1000.0.0)
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-14 06:24:37 +03:00
- React-perflogger (= 1000.0.0)
Change podspec name of yoga to Yoga Summary: Needed to capitalize the name, since this is the convention used elsewhere too ## Changelog: [iOS] [Changed] - Renamed yoga podspec to Yoga Reviewed By: shergin Differential Revision: D17127104 fbshipit-source-id: 14047bf452edda000037701f4ba7f4a02a0e717b
2019-08-30 17:10:51 +03:00
- Yoga
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- React-Core/RCTActionSheetHeaders (1000.0.0):
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
- Folly (= 2020.01.13.00)
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- glog
- React-Core/Default
- React-cxxreact (= 1000.0.0)
- React-jsi (= 1000.0.0)
- React-jsiexecutor (= 1000.0.0)
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-14 06:24:37 +03:00
- React-perflogger (= 1000.0.0)
Change podspec name of yoga to Yoga Summary: Needed to capitalize the name, since this is the convention used elsewhere too ## Changelog: [iOS] [Changed] - Renamed yoga podspec to Yoga Reviewed By: shergin Differential Revision: D17127104 fbshipit-source-id: 14047bf452edda000037701f4ba7f4a02a0e717b
2019-08-30 17:10:51 +03:00
- Yoga
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- React-Core/RCTAnimationHeaders (1000.0.0):
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
- Folly (= 2020.01.13.00)
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- glog
- React-Core/Default
- React-cxxreact (= 1000.0.0)
- React-jsi (= 1000.0.0)
- React-jsiexecutor (= 1000.0.0)
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-14 06:24:37 +03:00
- React-perflogger (= 1000.0.0)
Change podspec name of yoga to Yoga Summary: Needed to capitalize the name, since this is the convention used elsewhere too ## Changelog: [iOS] [Changed] - Renamed yoga podspec to Yoga Reviewed By: shergin Differential Revision: D17127104 fbshipit-source-id: 14047bf452edda000037701f4ba7f4a02a0e717b
2019-08-30 17:10:51 +03:00
- Yoga
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- React-Core/RCTBlobHeaders (1000.0.0):
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
- Folly (= 2020.01.13.00)
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- glog
- React-Core/Default
- React-cxxreact (= 1000.0.0)
- React-jsi (= 1000.0.0)
- React-jsiexecutor (= 1000.0.0)
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-14 06:24:37 +03:00
- React-perflogger (= 1000.0.0)
Change podspec name of yoga to Yoga Summary: Needed to capitalize the name, since this is the convention used elsewhere too ## Changelog: [iOS] [Changed] - Renamed yoga podspec to Yoga Reviewed By: shergin Differential Revision: D17127104 fbshipit-source-id: 14047bf452edda000037701f4ba7f4a02a0e717b
2019-08-30 17:10:51 +03:00
- Yoga
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- React-Core/RCTImageHeaders (1000.0.0):
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
- Folly (= 2020.01.13.00)
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- glog
- React-Core/Default
- React-cxxreact (= 1000.0.0)
- React-jsi (= 1000.0.0)
- React-jsiexecutor (= 1000.0.0)
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-14 06:24:37 +03:00
- React-perflogger (= 1000.0.0)
Change podspec name of yoga to Yoga Summary: Needed to capitalize the name, since this is the convention used elsewhere too ## Changelog: [iOS] [Changed] - Renamed yoga podspec to Yoga Reviewed By: shergin Differential Revision: D17127104 fbshipit-source-id: 14047bf452edda000037701f4ba7f4a02a0e717b
2019-08-30 17:10:51 +03:00
- Yoga
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- React-Core/RCTLinkingHeaders (1000.0.0):
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
- Folly (= 2020.01.13.00)
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- glog
- React-Core/Default
- React-cxxreact (= 1000.0.0)
- React-jsi (= 1000.0.0)
- React-jsiexecutor (= 1000.0.0)
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-14 06:24:37 +03:00
- React-perflogger (= 1000.0.0)
Change podspec name of yoga to Yoga Summary: Needed to capitalize the name, since this is the convention used elsewhere too ## Changelog: [iOS] [Changed] - Renamed yoga podspec to Yoga Reviewed By: shergin Differential Revision: D17127104 fbshipit-source-id: 14047bf452edda000037701f4ba7f4a02a0e717b
2019-08-30 17:10:51 +03:00
- Yoga
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- React-Core/RCTNetworkHeaders (1000.0.0):
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
- Folly (= 2020.01.13.00)
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- glog
- React-Core/Default
- React-cxxreact (= 1000.0.0)
- React-jsi (= 1000.0.0)
- React-jsiexecutor (= 1000.0.0)
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-14 06:24:37 +03:00
- React-perflogger (= 1000.0.0)
Change podspec name of yoga to Yoga Summary: Needed to capitalize the name, since this is the convention used elsewhere too ## Changelog: [iOS] [Changed] - Renamed yoga podspec to Yoga Reviewed By: shergin Differential Revision: D17127104 fbshipit-source-id: 14047bf452edda000037701f4ba7f4a02a0e717b
2019-08-30 17:10:51 +03:00
- Yoga
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- React-Core/RCTPushNotificationHeaders (1000.0.0):
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
- Folly (= 2020.01.13.00)
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- glog
- React-Core/Default
- React-cxxreact (= 1000.0.0)
- React-jsi (= 1000.0.0)
- React-jsiexecutor (= 1000.0.0)
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-14 06:24:37 +03:00
- React-perflogger (= 1000.0.0)
Change podspec name of yoga to Yoga Summary: Needed to capitalize the name, since this is the convention used elsewhere too ## Changelog: [iOS] [Changed] - Renamed yoga podspec to Yoga Reviewed By: shergin Differential Revision: D17127104 fbshipit-source-id: 14047bf452edda000037701f4ba7f4a02a0e717b
2019-08-30 17:10:51 +03:00
- Yoga
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- React-Core/RCTSettingsHeaders (1000.0.0):
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
- Folly (= 2020.01.13.00)
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- glog
- React-Core/Default
- React-cxxreact (= 1000.0.0)
- React-jsi (= 1000.0.0)
- React-jsiexecutor (= 1000.0.0)
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-14 06:24:37 +03:00
- React-perflogger (= 1000.0.0)
Change podspec name of yoga to Yoga Summary: Needed to capitalize the name, since this is the convention used elsewhere too ## Changelog: [iOS] [Changed] - Renamed yoga podspec to Yoga Reviewed By: shergin Differential Revision: D17127104 fbshipit-source-id: 14047bf452edda000037701f4ba7f4a02a0e717b
2019-08-30 17:10:51 +03:00
- Yoga
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- React-Core/RCTTextHeaders (1000.0.0):
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
- Folly (= 2020.01.13.00)
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- glog
- React-Core/Default
- React-cxxreact (= 1000.0.0)
- React-jsi (= 1000.0.0)
- React-jsiexecutor (= 1000.0.0)
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-14 06:24:37 +03:00
- React-perflogger (= 1000.0.0)
Change podspec name of yoga to Yoga Summary: Needed to capitalize the name, since this is the convention used elsewhere too ## Changelog: [iOS] [Changed] - Renamed yoga podspec to Yoga Reviewed By: shergin Differential Revision: D17127104 fbshipit-source-id: 14047bf452edda000037701f4ba7f4a02a0e717b
2019-08-30 17:10:51 +03:00
- Yoga
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- React-Core/RCTVibrationHeaders (1000.0.0):
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
- Folly (= 2020.01.13.00)
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- glog
- React-Core/Default
- React-cxxreact (= 1000.0.0)
- React-jsi (= 1000.0.0)
- React-jsiexecutor (= 1000.0.0)
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-14 06:24:37 +03:00
- React-perflogger (= 1000.0.0)
Change podspec name of yoga to Yoga Summary: Needed to capitalize the name, since this is the convention used elsewhere too ## Changelog: [iOS] [Changed] - Renamed yoga podspec to Yoga Reviewed By: shergin Differential Revision: D17127104 fbshipit-source-id: 14047bf452edda000037701f4ba7f4a02a0e717b
2019-08-30 17:10:51 +03:00
- Yoga
Remove 's.static_framework = true' requirement for podspec (#25816) Summary: As part of the fix for https://github.com/facebook/react-native/issues/25349 I added `s.static_framework = true` to each podspec in repo (see https://github.com/facebook/react-native/pull/25619#discussion_r306993309 for more context). This was required to ensure the existing conditional compilation with `#if RCT_DEV` and `__has_include` still worked correctly when `use_frameworks!` is enabled. However, fkgozali pointed out that it would be ideal if we didn't have this requirement as it could make life difficult for third-party libraries. This removes the requirement by moving `React-DevSupport.podspec` and `React-RCTWebSocket.podspec` into `React-Core.podspec` as subspecs. This means the symbols are present when `React-Core.podspec` is built dynamically so `s.static_framework = true` isn't required. This means that any `Podfile` that refers to `React-DevSupport` or `React-RCTWebSocket` will need to be updated to avoid errors. ## Changelog I don't think this needs a changelog entry since its just a refinement of https://github.com/facebook/react-native/pull/25619. Pull Request resolved: https://github.com/facebook/react-native/pull/25816 Test Plan: Check `RNTesterPods` still works both with and without `use_frameworks!`: 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: hramos Differential Revision: D16495030 Pulled By: fkgozali fbshipit-source-id: 2708ac9fd20cd04cb0aea61b2e8ab0d931dfb6d5
2019-07-25 21:42:49 +03:00
- React-Core/RCTWebSocket (1000.0.0):
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
- Folly (= 2020.01.13.00)
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- glog
Remove 's.static_framework = true' requirement for podspec (#25816) Summary: As part of the fix for https://github.com/facebook/react-native/issues/25349 I added `s.static_framework = true` to each podspec in repo (see https://github.com/facebook/react-native/pull/25619#discussion_r306993309 for more context). This was required to ensure the existing conditional compilation with `#if RCT_DEV` and `__has_include` still worked correctly when `use_frameworks!` is enabled. However, fkgozali pointed out that it would be ideal if we didn't have this requirement as it could make life difficult for third-party libraries. This removes the requirement by moving `React-DevSupport.podspec` and `React-RCTWebSocket.podspec` into `React-Core.podspec` as subspecs. This means the symbols are present when `React-Core.podspec` is built dynamically so `s.static_framework = true` isn't required. This means that any `Podfile` that refers to `React-DevSupport` or `React-RCTWebSocket` will need to be updated to avoid errors. ## Changelog I don't think this needs a changelog entry since its just a refinement of https://github.com/facebook/react-native/pull/25619. Pull Request resolved: https://github.com/facebook/react-native/pull/25816 Test Plan: Check `RNTesterPods` still works both with and without `use_frameworks!`: 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: hramos Differential Revision: D16495030 Pulled By: fkgozali fbshipit-source-id: 2708ac9fd20cd04cb0aea61b2e8ab0d931dfb6d5
2019-07-25 21:42:49 +03:00
- React-Core/Default (= 1000.0.0)
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- React-cxxreact (= 1000.0.0)
- React-jsi (= 1000.0.0)
- React-jsiexecutor (= 1000.0.0)
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-14 06:24:37 +03:00
- React-perflogger (= 1000.0.0)
Change podspec name of yoga to Yoga Summary: Needed to capitalize the name, since this is the convention used elsewhere too ## Changelog: [iOS] [Changed] - Renamed yoga podspec to Yoga Reviewed By: shergin Differential Revision: D17127104 fbshipit-source-id: 14047bf452edda000037701f4ba7f4a02a0e717b
2019-08-30 17:10:51 +03:00
- Yoga
TM iOS: Set up CocoaPods specs for the TM specs Summary: This defines various sub specs to support building TurboModules that implement the codegen'ed specs. Reviewed By: PeteTheHeat Differential Revision: D16043221 fbshipit-source-id: 27ed532be929c11c8fe648632da8a72061cbc8b0
2019-07-02 01:12:56 +03:00
- React-CoreModules (1000.0.0):
- FBReactNativeSpec (= 1000.0.0)
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
- Folly (= 2020.01.13.00)
iOS Pods: added missing deps for React-CoreModules Summary: This is needed for use_frameworks! support with CocoaPods. Also, with recent changes to RCTImageLoader etc (moved to CoreModules), we need to add a dep to `React-RCTImage` pod. If this approach works for 0.61 branch as well, it should be beneficial to pick. Note that https://github.com/facebook/react-native/pull/26151 attempts to fix similar things, but in 0.61 branch, not master. Reviewed By: axe-fb Differential Revision: D17120352 fbshipit-source-id: ca96a7a61a6422a6f9fc3a4bf3add51e6f33f4f1
2019-08-30 00:28:51 +03:00
- RCTTypeSafety (= 1000.0.0)
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- React-Core/CoreModulesHeaders (= 1000.0.0)
Fix Cocoapods builds Summary: ## Problem For some reason, D20831545 broke the `use_frameworks!` build of RNTester. ## Building RNTester ``` pushd ~/fbsource/xplat/js/react-native-github/RNTester && USE_FRAMEWORKS=1 pod install && open RNTesterPods.xcworkspace && popd; ``` ## Error I built RNTester locally, and the error was this: ``` Undefined symbols for architecture x86_64: "facebook::jsi::HostObject::set(facebook::jsi::Runtime&, facebook::jsi::PropNameID const&, facebook::jsi::Value const&)", referenced from: vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o "facebook::jsi::HostObject::getPropertyNames(facebook::jsi::Runtime&)", referenced from: vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o ld: symbol(s) not found for architecture x86_64 ``` ## Fix It looked like libraries that depend on "ReactCommon/turbomodule/core" weren't linking to JSI correctly. So, I modified all such Podspecs to also depend on "React-jsi": ``` arc rfr ' s.dependency "ReactCommon/turbomodule/core", version' ' s.dependency "ReactCommon/turbomodule/core", version\n s.dependency "React-jsi", version' ``` This seemed to do the trick. In buck, we'd fix this problem using exported_dependencies. I skimmed through cocoapods, and couldn't find such a configuration option there. So, I guess this will have to do? Changelog: [iOS][Fixed] - Fix Cocoapods builds of RNTester Reviewed By: fkgozali, hramos Differential Revision: D20905465 fbshipit-source-id: 60218c8274ec165752a428f2a7a9a546607c8fec
2020-04-08 05:04:25 +03:00
- React-jsi (= 1000.0.0)
iOS Pods: added missing deps for React-CoreModules Summary: This is needed for use_frameworks! support with CocoaPods. Also, with recent changes to RCTImageLoader etc (moved to CoreModules), we need to add a dep to `React-RCTImage` pod. If this approach works for 0.61 branch as well, it should be beneficial to pick. Note that https://github.com/facebook/react-native/pull/26151 attempts to fix similar things, but in 0.61 branch, not master. Reviewed By: axe-fb Differential Revision: D17120352 fbshipit-source-id: ca96a7a61a6422a6f9fc3a4bf3add51e6f33f4f1
2019-08-30 00:28:51 +03:00
- React-RCTImage (= 1000.0.0)
Remove 's.static_framework = true' requirement for podspec (#25816) Summary: As part of the fix for https://github.com/facebook/react-native/issues/25349 I added `s.static_framework = true` to each podspec in repo (see https://github.com/facebook/react-native/pull/25619#discussion_r306993309 for more context). This was required to ensure the existing conditional compilation with `#if RCT_DEV` and `__has_include` still worked correctly when `use_frameworks!` is enabled. However, fkgozali pointed out that it would be ideal if we didn't have this requirement as it could make life difficult for third-party libraries. This removes the requirement by moving `React-DevSupport.podspec` and `React-RCTWebSocket.podspec` into `React-Core.podspec` as subspecs. This means the symbols are present when `React-Core.podspec` is built dynamically so `s.static_framework = true` isn't required. This means that any `Podfile` that refers to `React-DevSupport` or `React-RCTWebSocket` will need to be updated to avoid errors. ## Changelog I don't think this needs a changelog entry since its just a refinement of https://github.com/facebook/react-native/pull/25619. Pull Request resolved: https://github.com/facebook/react-native/pull/25816 Test Plan: Check `RNTesterPods` still works both with and without `use_frameworks!`: 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: hramos Differential Revision: D16495030 Pulled By: fkgozali fbshipit-source-id: 2708ac9fd20cd04cb0aea61b2e8ab0d931dfb6d5
2019-07-25 21:42:49 +03:00
- ReactCommon/turbomodule/core (= 1000.0.0)
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
- React-cxxreact (1000.0.0):
iOS OSS: check in the Podfile.lock Summary: Should have been checked in previously. No setup change here. Reviewed By: shergin Differential Revision: D7626040 fbshipit-source-id: e7a1a9de70a40a22e39eb3777d1b62c8d7b66381
2018-04-14 03:19:01 +03:00
- boost-for-react-native (= 1.63.0)
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
- DoubleConversion
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
- Folly (= 2020.01.13.00)
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
- glog
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 21:36:50 +03:00
- React-callinvoker (= 1000.0.0)
Fix CircleCI by adding dependency on JSI to cxxreact (#29087) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/29087 D21908523 added an implicit dependency on `jsi.h` to use functions like `asObject`, etc. For some reason this doesn't break the build with BUCK (??) but it does with cocoapods. Adding the dep to the cxxreact podspec and regenerating offline mirrors to unbreak CircleCI. Also adding the BUCK dep and include statement for good measure. Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D21924592 fbshipit-source-id: 295c0670c6499e1195ba3c3a3320c6aee13bc025
2020-06-08 03:53:07 +03:00
- React-jsi (= 1000.0.0)
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
- React-jsinspector (= 1000.0.0)
Instrument JS requires Summary: This diff instruments two markers: - JSRequireBeginning: From the start of the JS require to when we start creating the platform NativeModule - JSRequireEnding: From the end of platform NativeModule create to the end of the JS require In order to accomplish this, I had modify `ModuleRegistry::ModuleRegistry()` to accept a `std::shared_ptr<NativeModulePerfLogger>`. I also had to implement the public method `ModuleRegistry::getNativeModulePerfLogger()` so that `JSINativeModules` could start logging the JS require beginning and ending. Changelog: [Internal] Reviewed By: PeteTheHeat Differential Revision: D21418803 fbshipit-source-id: 53828817ae41f23f3f04a95b1d3ac0012735da48
2020-05-14 06:24:37 +03:00
- React-perflogger (= 1000.0.0)
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-09 02:10:38 +03:00
- React-runtimeexecutor (= 1000.0.0)
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
- React-jsi (1000.0.0):
- boost-for-react-native (= 1.63.0)
- DoubleConversion
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
- Folly (= 2020.01.13.00)
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
- glog
Fabric: working podspecs & works in RNTester (#23803) Summary: This is the couple of hacks I used after I finished #23802 in order to get fabric working on RNTester. This is inspired from prior work by kmagiera. The goal of this PR is to show others what I’m struggling with, and to eventually merge it sans hacks. - Yarn Install - Uncomment the commented out pods in RNTester's pod file - Open RNTesterPods workspace - Run App - this is only for pods, the non-pod RNTester will no longer work until updated with fabric too. - `SurfaceHostingView` & `SurfaceHostingProxyRootView` both try to start the surface immediately, this leads to a race condition due to the javascript not having loaded yet, the hack here is: 1. Swizzle the `start` method on `RCTFabricSurface` to no-op when called. 2. Add observer for `RCTJavaScriptDidLoadNotification` 3. Call private method `_startAllSurfaces` on `_surfacePresenter` in AppDelegate when we receive `RCTJavaScriptDidLoadNotification`. [General] [Added] - Use Fabric in RNTester Pull Request resolved: https://github.com/facebook/react-native/pull/23803 Reviewed By: shergin, mdvacca Differential Revision: D14450726 Pulled By: fkgozali fbshipit-source-id: 8ae2d48634fecb60db539aaf0a2c89ba1f572c27
2019-03-16 09:56:17 +03:00
- React-jsi/Default (= 1000.0.0)
- React-jsi/Default (1000.0.0):
- boost-for-react-native (= 1.63.0)
- DoubleConversion
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
- Folly (= 2020.01.13.00)
Fabric: working podspecs & works in RNTester (#23803) Summary: This is the couple of hacks I used after I finished #23802 in order to get fabric working on RNTester. This is inspired from prior work by kmagiera. The goal of this PR is to show others what I’m struggling with, and to eventually merge it sans hacks. - Yarn Install - Uncomment the commented out pods in RNTester's pod file - Open RNTesterPods workspace - Run App - this is only for pods, the non-pod RNTester will no longer work until updated with fabric too. - `SurfaceHostingView` & `SurfaceHostingProxyRootView` both try to start the surface immediately, this leads to a race condition due to the javascript not having loaded yet, the hack here is: 1. Swizzle the `start` method on `RCTFabricSurface` to no-op when called. 2. Add observer for `RCTJavaScriptDidLoadNotification` 3. Call private method `_startAllSurfaces` on `_surfacePresenter` in AppDelegate when we receive `RCTJavaScriptDidLoadNotification`. [General] [Added] - Use Fabric in RNTester Pull Request resolved: https://github.com/facebook/react-native/pull/23803 Reviewed By: shergin, mdvacca Differential Revision: D14450726 Pulled By: fkgozali fbshipit-source-id: 8ae2d48634fecb60db539aaf0a2c89ba1f572c27
2019-03-16 09:56:17 +03:00
- glog
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
- React-jsiexecutor (1000.0.0):
- DoubleConversion
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
- Folly (= 2020.01.13.00)
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
- glog
- React-cxxreact (= 1000.0.0)
- React-jsi (= 1000.0.0)
Instrument JS requires Summary: This diff instruments two markers: - JSRequireBeginning: From the start of the JS require to when we start creating the platform NativeModule - JSRequireEnding: From the end of platform NativeModule create to the end of the JS require In order to accomplish this, I had modify `ModuleRegistry::ModuleRegistry()` to accept a `std::shared_ptr<NativeModulePerfLogger>`. I also had to implement the public method `ModuleRegistry::getNativeModulePerfLogger()` so that `JSINativeModules` could start logging the JS require beginning and ending. Changelog: [Internal] Reviewed By: PeteTheHeat Differential Revision: D21418803 fbshipit-source-id: 53828817ae41f23f3f04a95b1d3ac0012735da48
2020-05-14 06:24:37 +03:00
- React-perflogger (= 1000.0.0)
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
- React-jsinspector (1000.0.0)
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-14 06:24:37 +03:00
- React-perflogger (1000.0.0)
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
- React-RCTActionSheet (1000.0.0):
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- React-Core/RCTActionSheetHeaders (= 1000.0.0)
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
- React-RCTAnimation (1000.0.0):
Split NativeStatusBarManager into NativeStatusBarManager{Android,IOS} Summary: The `StatusBarManager` NativeModule does not have a uniform API on iOS and Android. In particular, the `setStyle` and the `setHidden` methods have an additional parameter on iOS: ``` /** * - statusBarStyles can be: * - 'default' * - 'dark-content' * - 'light-content' */ +setStyle: (statusBarStyle?: ?string, animated: boolean) => void; /** * - withAnimation can be: 'none' | 'fade' | 'slide' */ +setHidden: (hidden: boolean, withAnimation: string) => void; ``` If we keep the NativeModule spec the same between the two platforms, we'd have to keep the second parameter optional for both methods. This works for `setHidden`, because the second parameter is a string, and optional strings are allowed. However, for `setStyle`, the second parameter is a number, and we don't support optional numbers/booleans on Android in the NativeModule system. If we keep the optional number, then the following check triggers in our RedBox tests on iOS, which makes them fail: https://fburl.com/diffusion/b7adezd9. So, since the two specs are sufficiently different, I figured that the easiest path forward is to split them apart. Changelog: [iOS][Changed] - Separated NativeStatusBarManager into NativeStatusBarManager{IOS,Android} Reviewed By: PeteTheHeat Differential Revision: D18214161 fbshipit-source-id: 6fd8b8c5f576244b5b90ee47faa7f50508c5e1d3
2019-11-01 21:54:44 +03:00
- FBReactNativeSpec (= 1000.0.0)
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
- Folly (= 2020.01.13.00)
Fix podspecs Summary: I kept on running `USE_FRAMEWORKS=1 update-pods && open RNTesterPods.xcworkspace` and adding missing dependencies until `RNTesterPods` started compiling without failure. **Note:** I made sure to only commit the podfile changes from `update-pods`, **without** `USE_FRAMEWORKS=1`. Changelog: [iOS][Fixed] - Fix all RN Podspecs Reviewed By: fkgozali Differential Revision: D18284535 fbshipit-source-id: 44d288ae0e52dd2cbbe26bebe7df73ce05644b5d
2019-11-02 05:32:48 +03:00
- RCTTypeSafety (= 1000.0.0)
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- React-Core/RCTAnimationHeaders (= 1000.0.0)
Fix Cocoapods builds Summary: ## Problem For some reason, D20831545 broke the `use_frameworks!` build of RNTester. ## Building RNTester ``` pushd ~/fbsource/xplat/js/react-native-github/RNTester && USE_FRAMEWORKS=1 pod install && open RNTesterPods.xcworkspace && popd; ``` ## Error I built RNTester locally, and the error was this: ``` Undefined symbols for architecture x86_64: "facebook::jsi::HostObject::set(facebook::jsi::Runtime&, facebook::jsi::PropNameID const&, facebook::jsi::Value const&)", referenced from: vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o "facebook::jsi::HostObject::getPropertyNames(facebook::jsi::Runtime&)", referenced from: vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o ld: symbol(s) not found for architecture x86_64 ``` ## Fix It looked like libraries that depend on "ReactCommon/turbomodule/core" weren't linking to JSI correctly. So, I modified all such Podspecs to also depend on "React-jsi": ``` arc rfr ' s.dependency "ReactCommon/turbomodule/core", version' ' s.dependency "ReactCommon/turbomodule/core", version\n s.dependency "React-jsi", version' ``` This seemed to do the trick. In buck, we'd fix this problem using exported_dependencies. I skimmed through cocoapods, and couldn't find such a configuration option there. So, I guess this will have to do? Changelog: [iOS][Fixed] - Fix Cocoapods builds of RNTester Reviewed By: fkgozali, hramos Differential Revision: D20905465 fbshipit-source-id: 60218c8274ec165752a428f2a7a9a546607c8fec
2020-04-08 05:04:25 +03:00
- React-jsi (= 1000.0.0)
Fix podspecs Summary: I kept on running `USE_FRAMEWORKS=1 update-pods && open RNTesterPods.xcworkspace` and adding missing dependencies until `RNTesterPods` started compiling without failure. **Note:** I made sure to only commit the podfile changes from `update-pods`, **without** `USE_FRAMEWORKS=1`. Changelog: [iOS][Fixed] - Fix all RN Podspecs Reviewed By: fkgozali Differential Revision: D18284535 fbshipit-source-id: 44d288ae0e52dd2cbbe26bebe7df73ce05644b5d
2019-11-02 05:32:48 +03:00
- ReactCommon/turbomodule/core (= 1000.0.0)
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
- React-RCTBlob (1000.0.0):
Make RCTFileReaderModule and RCTBlobManager TurboModule-compatible Summary: Make RCTFileReaderModule and RCTBlobModule TurboModule-compatible Reviewed By: PeteTheHeat Differential Revision: D17583286 fbshipit-source-id: 4cab350aadce00c03a6c631a6b57e86f35484d2f
2019-10-01 21:07:08 +03:00
- FBReactNativeSpec (= 1000.0.0)
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
- Folly (= 2020.01.13.00)
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- React-Core/RCTBlobHeaders (= 1000.0.0)
Remove 's.static_framework = true' requirement for podspec (#25816) Summary: As part of the fix for https://github.com/facebook/react-native/issues/25349 I added `s.static_framework = true` to each podspec in repo (see https://github.com/facebook/react-native/pull/25619#discussion_r306993309 for more context). This was required to ensure the existing conditional compilation with `#if RCT_DEV` and `__has_include` still worked correctly when `use_frameworks!` is enabled. However, fkgozali pointed out that it would be ideal if we didn't have this requirement as it could make life difficult for third-party libraries. This removes the requirement by moving `React-DevSupport.podspec` and `React-RCTWebSocket.podspec` into `React-Core.podspec` as subspecs. This means the symbols are present when `React-Core.podspec` is built dynamically so `s.static_framework = true` isn't required. This means that any `Podfile` that refers to `React-DevSupport` or `React-RCTWebSocket` will need to be updated to avoid errors. ## Changelog I don't think this needs a changelog entry since its just a refinement of https://github.com/facebook/react-native/pull/25619. Pull Request resolved: https://github.com/facebook/react-native/pull/25816 Test Plan: Check `RNTesterPods` still works both with and without `use_frameworks!`: 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: hramos Differential Revision: D16495030 Pulled By: fkgozali fbshipit-source-id: 2708ac9fd20cd04cb0aea61b2e8ab0d931dfb6d5
2019-07-25 21:42:49 +03:00
- React-Core/RCTWebSocket (= 1000.0.0)
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- React-jsi (= 1000.0.0)
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
- React-RCTNetwork (= 1000.0.0)
Fix podspecs Summary: I kept on running `USE_FRAMEWORKS=1 update-pods && open RNTesterPods.xcworkspace` and adding missing dependencies until `RNTesterPods` started compiling without failure. **Note:** I made sure to only commit the podfile changes from `update-pods`, **without** `USE_FRAMEWORKS=1`. Changelog: [iOS][Fixed] - Fix all RN Podspecs Reviewed By: fkgozali Differential Revision: D18284535 fbshipit-source-id: 44d288ae0e52dd2cbbe26bebe7df73ce05644b5d
2019-11-02 05:32:48 +03:00
- ReactCommon/turbomodule/core (= 1000.0.0)
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
- React-RCTImage (1000.0.0):
Move RCTImage NativeModules back to RCTImage Summary: In D16805827, I moved `RCTImageLoader`, `RCTImageStoreManager`, and `RCTImageEditingManager` to `CoreModules`. This was necessary to turn `RCTImageLoader` into a TurboModule. However, after D17671288 landed, it's no longer necessary to have OSS NativeModules in `CoreModules`. Therefore, I'm moving these NativeModules back to `RCTImage`. Changelog: [iOS][Fixed] Move RCTImage NativeModules back to RCTImage Reviewed By: shergin Differential Revision: D17921612 fbshipit-source-id: 8ae36d2dc8deaf704313cbe2479bfa011ebcbfbc
2019-10-22 02:57:38 +03:00
- FBReactNativeSpec (= 1000.0.0)
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
- Folly (= 2020.01.13.00)
Fix podspecs Summary: I kept on running `USE_FRAMEWORKS=1 update-pods && open RNTesterPods.xcworkspace` and adding missing dependencies until `RNTesterPods` started compiling without failure. **Note:** I made sure to only commit the podfile changes from `update-pods`, **without** `USE_FRAMEWORKS=1`. Changelog: [iOS][Fixed] - Fix all RN Podspecs Reviewed By: fkgozali Differential Revision: D18284535 fbshipit-source-id: 44d288ae0e52dd2cbbe26bebe7df73ce05644b5d
2019-11-02 05:32:48 +03:00
- RCTTypeSafety (= 1000.0.0)
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- React-Core/RCTImageHeaders (= 1000.0.0)
Fix Cocoapods builds Summary: ## Problem For some reason, D20831545 broke the `use_frameworks!` build of RNTester. ## Building RNTester ``` pushd ~/fbsource/xplat/js/react-native-github/RNTester && USE_FRAMEWORKS=1 pod install && open RNTesterPods.xcworkspace && popd; ``` ## Error I built RNTester locally, and the error was this: ``` Undefined symbols for architecture x86_64: "facebook::jsi::HostObject::set(facebook::jsi::Runtime&, facebook::jsi::PropNameID const&, facebook::jsi::Value const&)", referenced from: vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o "facebook::jsi::HostObject::getPropertyNames(facebook::jsi::Runtime&)", referenced from: vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o ld: symbol(s) not found for architecture x86_64 ``` ## Fix It looked like libraries that depend on "ReactCommon/turbomodule/core" weren't linking to JSI correctly. So, I modified all such Podspecs to also depend on "React-jsi": ``` arc rfr ' s.dependency "ReactCommon/turbomodule/core", version' ' s.dependency "ReactCommon/turbomodule/core", version\n s.dependency "React-jsi", version' ``` This seemed to do the trick. In buck, we'd fix this problem using exported_dependencies. I skimmed through cocoapods, and couldn't find such a configuration option there. So, I guess this will have to do? Changelog: [iOS][Fixed] - Fix Cocoapods builds of RNTester Reviewed By: fkgozali, hramos Differential Revision: D20905465 fbshipit-source-id: 60218c8274ec165752a428f2a7a9a546607c8fec
2020-04-08 05:04:25 +03:00
- React-jsi (= 1000.0.0)
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
- React-RCTNetwork (= 1000.0.0)
Fix podspecs Summary: I kept on running `USE_FRAMEWORKS=1 update-pods && open RNTesterPods.xcworkspace` and adding missing dependencies until `RNTesterPods` started compiling without failure. **Note:** I made sure to only commit the podfile changes from `update-pods`, **without** `USE_FRAMEWORKS=1`. Changelog: [iOS][Fixed] - Fix all RN Podspecs Reviewed By: fkgozali Differential Revision: D18284535 fbshipit-source-id: 44d288ae0e52dd2cbbe26bebe7df73ce05644b5d
2019-11-02 05:32:48 +03:00
- ReactCommon/turbomodule/core (= 1000.0.0)
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
- React-RCTLinking (1000.0.0):
Make RCTLinkingManager TurboModule-compatible Summary: See title. Changelog: [iOS][Added] - Make RCTLinkingManager TurboModule-compatible Reviewed By: PeteTheHeat Differential Revision: D18331085 fbshipit-source-id: 5b4482affbf647bd96043ef9a27e715856bc25f1
2019-11-09 01:08:11 +03:00
- FBReactNativeSpec (= 1000.0.0)
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- React-Core/RCTLinkingHeaders (= 1000.0.0)
Fix Cocoapods builds Summary: ## Problem For some reason, D20831545 broke the `use_frameworks!` build of RNTester. ## Building RNTester ``` pushd ~/fbsource/xplat/js/react-native-github/RNTester && USE_FRAMEWORKS=1 pod install && open RNTesterPods.xcworkspace && popd; ``` ## Error I built RNTester locally, and the error was this: ``` Undefined symbols for architecture x86_64: "facebook::jsi::HostObject::set(facebook::jsi::Runtime&, facebook::jsi::PropNameID const&, facebook::jsi::Value const&)", referenced from: vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o "facebook::jsi::HostObject::getPropertyNames(facebook::jsi::Runtime&)", referenced from: vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o ld: symbol(s) not found for architecture x86_64 ``` ## Fix It looked like libraries that depend on "ReactCommon/turbomodule/core" weren't linking to JSI correctly. So, I modified all such Podspecs to also depend on "React-jsi": ``` arc rfr ' s.dependency "ReactCommon/turbomodule/core", version' ' s.dependency "ReactCommon/turbomodule/core", version\n s.dependency "React-jsi", version' ``` This seemed to do the trick. In buck, we'd fix this problem using exported_dependencies. I skimmed through cocoapods, and couldn't find such a configuration option there. So, I guess this will have to do? Changelog: [iOS][Fixed] - Fix Cocoapods builds of RNTester Reviewed By: fkgozali, hramos Differential Revision: D20905465 fbshipit-source-id: 60218c8274ec165752a428f2a7a9a546607c8fec
2020-04-08 05:04:25 +03:00
- React-jsi (= 1000.0.0)
Make RCTLinkingManager TurboModule-compatible Summary: See title. Changelog: [iOS][Added] - Make RCTLinkingManager TurboModule-compatible Reviewed By: PeteTheHeat Differential Revision: D18331085 fbshipit-source-id: 5b4482affbf647bd96043ef9a27e715856bc25f1
2019-11-09 01:08:11 +03:00
- ReactCommon/turbomodule/core (= 1000.0.0)
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
- React-RCTNetwork (1000.0.0):
Make RCTNetworking TurboModule-compatible Summary: See title. Changelog: [iOS][Added] - Make RCTNetworking TurboModule-compatible Reviewed By: PeteTheHeat Differential Revision: D18087243 fbshipit-source-id: 81bbf77d603e96fa94ad219e5ed68f42bb7e7dc5
2019-11-05 02:58:49 +03:00
- FBReactNativeSpec (= 1000.0.0)
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
- Folly (= 2020.01.13.00)
Make RCTNetworking TurboModule-compatible Summary: See title. Changelog: [iOS][Added] - Make RCTNetworking TurboModule-compatible Reviewed By: PeteTheHeat Differential Revision: D18087243 fbshipit-source-id: 81bbf77d603e96fa94ad219e5ed68f42bb7e7dc5
2019-11-05 02:58:49 +03:00
- RCTTypeSafety (= 1000.0.0)
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- React-Core/RCTNetworkHeaders (= 1000.0.0)
Fix Cocoapods builds Summary: ## Problem For some reason, D20831545 broke the `use_frameworks!` build of RNTester. ## Building RNTester ``` pushd ~/fbsource/xplat/js/react-native-github/RNTester && USE_FRAMEWORKS=1 pod install && open RNTesterPods.xcworkspace && popd; ``` ## Error I built RNTester locally, and the error was this: ``` Undefined symbols for architecture x86_64: "facebook::jsi::HostObject::set(facebook::jsi::Runtime&, facebook::jsi::PropNameID const&, facebook::jsi::Value const&)", referenced from: vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o "facebook::jsi::HostObject::getPropertyNames(facebook::jsi::Runtime&)", referenced from: vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o ld: symbol(s) not found for architecture x86_64 ``` ## Fix It looked like libraries that depend on "ReactCommon/turbomodule/core" weren't linking to JSI correctly. So, I modified all such Podspecs to also depend on "React-jsi": ``` arc rfr ' s.dependency "ReactCommon/turbomodule/core", version' ' s.dependency "ReactCommon/turbomodule/core", version\n s.dependency "React-jsi", version' ``` This seemed to do the trick. In buck, we'd fix this problem using exported_dependencies. I skimmed through cocoapods, and couldn't find such a configuration option there. So, I guess this will have to do? Changelog: [iOS][Fixed] - Fix Cocoapods builds of RNTester Reviewed By: fkgozali, hramos Differential Revision: D20905465 fbshipit-source-id: 60218c8274ec165752a428f2a7a9a546607c8fec
2020-04-08 05:04:25 +03:00
- React-jsi (= 1000.0.0)
Make RCTNetworking TurboModule-compatible Summary: See title. Changelog: [iOS][Added] - Make RCTNetworking TurboModule-compatible Reviewed By: PeteTheHeat Differential Revision: D18087243 fbshipit-source-id: 81bbf77d603e96fa94ad219e5ed68f42bb7e7dc5
2019-11-05 02:58:49 +03:00
- ReactCommon/turbomodule/core (= 1000.0.0)
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
- React-RCTPushNotification (1000.0.0):
Make PushNotificationManager TurboModule-compatible Summary: Changelog: [iOS][Added] - Make PushNotificationManager TurboModule-compatible Reviewed By: PeteTheHeat Differential Revision: D18375067 fbshipit-source-id: 256e6a42bf0055253f04df45e67f538f7564a966
2019-11-09 01:08:11 +03:00
- FBReactNativeSpec (= 1000.0.0)
- RCTTypeSafety (= 1000.0.0)
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- React-Core/RCTPushNotificationHeaders (= 1000.0.0)
Fix Cocoapods builds Summary: ## Problem For some reason, D20831545 broke the `use_frameworks!` build of RNTester. ## Building RNTester ``` pushd ~/fbsource/xplat/js/react-native-github/RNTester && USE_FRAMEWORKS=1 pod install && open RNTesterPods.xcworkspace && popd; ``` ## Error I built RNTester locally, and the error was this: ``` Undefined symbols for architecture x86_64: "facebook::jsi::HostObject::set(facebook::jsi::Runtime&, facebook::jsi::PropNameID const&, facebook::jsi::Value const&)", referenced from: vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o "facebook::jsi::HostObject::getPropertyNames(facebook::jsi::Runtime&)", referenced from: vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o ld: symbol(s) not found for architecture x86_64 ``` ## Fix It looked like libraries that depend on "ReactCommon/turbomodule/core" weren't linking to JSI correctly. So, I modified all such Podspecs to also depend on "React-jsi": ``` arc rfr ' s.dependency "ReactCommon/turbomodule/core", version' ' s.dependency "ReactCommon/turbomodule/core", version\n s.dependency "React-jsi", version' ``` This seemed to do the trick. In buck, we'd fix this problem using exported_dependencies. I skimmed through cocoapods, and couldn't find such a configuration option there. So, I guess this will have to do? Changelog: [iOS][Fixed] - Fix Cocoapods builds of RNTester Reviewed By: fkgozali, hramos Differential Revision: D20905465 fbshipit-source-id: 60218c8274ec165752a428f2a7a9a546607c8fec
2020-04-08 05:04:25 +03:00
- React-jsi (= 1000.0.0)
Make PushNotificationManager TurboModule-compatible Summary: Changelog: [iOS][Added] - Make PushNotificationManager TurboModule-compatible Reviewed By: PeteTheHeat Differential Revision: D18375067 fbshipit-source-id: 256e6a42bf0055253f04df45e67f538f7564a966
2019-11-09 01:08:11 +03:00
- ReactCommon/turbomodule/core (= 1000.0.0)
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
- React-RCTSettings (1000.0.0):
Make RCTSettingsManager TurboModule-compatible Summary: Make RCTSettingsManager TurboModule-compatible. Reviewed By: PeteTheHeat Differential Revision: D17581374 fbshipit-source-id: 22ec6237ea8b504ff826d0fe7b3db2fabfee9f80
2019-10-01 21:07:08 +03:00
- FBReactNativeSpec (= 1000.0.0)
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
- Folly (= 2020.01.13.00)
Fix podspecs Summary: I kept on running `USE_FRAMEWORKS=1 update-pods && open RNTesterPods.xcworkspace` and adding missing dependencies until `RNTesterPods` started compiling without failure. **Note:** I made sure to only commit the podfile changes from `update-pods`, **without** `USE_FRAMEWORKS=1`. Changelog: [iOS][Fixed] - Fix all RN Podspecs Reviewed By: fkgozali Differential Revision: D18284535 fbshipit-source-id: 44d288ae0e52dd2cbbe26bebe7df73ce05644b5d
2019-11-02 05:32:48 +03:00
- RCTTypeSafety (= 1000.0.0)
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- React-Core/RCTSettingsHeaders (= 1000.0.0)
Fix Cocoapods builds Summary: ## Problem For some reason, D20831545 broke the `use_frameworks!` build of RNTester. ## Building RNTester ``` pushd ~/fbsource/xplat/js/react-native-github/RNTester && USE_FRAMEWORKS=1 pod install && open RNTesterPods.xcworkspace && popd; ``` ## Error I built RNTester locally, and the error was this: ``` Undefined symbols for architecture x86_64: "facebook::jsi::HostObject::set(facebook::jsi::Runtime&, facebook::jsi::PropNameID const&, facebook::jsi::Value const&)", referenced from: vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o "facebook::jsi::HostObject::getPropertyNames(facebook::jsi::Runtime&)", referenced from: vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o ld: symbol(s) not found for architecture x86_64 ``` ## Fix It looked like libraries that depend on "ReactCommon/turbomodule/core" weren't linking to JSI correctly. So, I modified all such Podspecs to also depend on "React-jsi": ``` arc rfr ' s.dependency "ReactCommon/turbomodule/core", version' ' s.dependency "ReactCommon/turbomodule/core", version\n s.dependency "React-jsi", version' ``` This seemed to do the trick. In buck, we'd fix this problem using exported_dependencies. I skimmed through cocoapods, and couldn't find such a configuration option there. So, I guess this will have to do? Changelog: [iOS][Fixed] - Fix Cocoapods builds of RNTester Reviewed By: fkgozali, hramos Differential Revision: D20905465 fbshipit-source-id: 60218c8274ec165752a428f2a7a9a546607c8fec
2020-04-08 05:04:25 +03:00
- React-jsi (= 1000.0.0)
Fix podspecs Summary: I kept on running `USE_FRAMEWORKS=1 update-pods && open RNTesterPods.xcworkspace` and adding missing dependencies until `RNTesterPods` started compiling without failure. **Note:** I made sure to only commit the podfile changes from `update-pods`, **without** `USE_FRAMEWORKS=1`. Changelog: [iOS][Fixed] - Fix all RN Podspecs Reviewed By: fkgozali Differential Revision: D18284535 fbshipit-source-id: 44d288ae0e52dd2cbbe26bebe7df73ce05644b5d
2019-11-02 05:32:48 +03:00
- ReactCommon/turbomodule/core (= 1000.0.0)
Move Pods to react-native-github Summary: Now that the Pods/ directory is excluded by ShipIt from GitHub, we can move the Pods/ directory into react-native-github. Reviewed By: fkgozali Differential Revision: D15944730 fbshipit-source-id: b8165abbb4e6fef5ad4311da3885187b84ad1b20
2019-06-26 18:39:43 +03:00
- React-RCTTest (1000.0.0):
Make RCTTestModule TurboModule-compatible Reviewed By: fkgozali Differential Revision: D18545790 fbshipit-source-id: 035df69671ec44d13b79b014bfe90f5af9f43e58
2020-02-02 02:03:28 +03:00
- Folly (= 2020.01.13.00)
Move Pods to react-native-github Summary: Now that the Pods/ directory is excluded by ShipIt from GitHub, we can move the Pods/ directory into react-native-github. Reviewed By: fkgozali Differential Revision: D15944730 fbshipit-source-id: b8165abbb4e6fef5ad4311da3885187b84ad1b20
2019-06-26 18:39:43 +03:00
- React-Core (= 1000.0.0)
Make RCTDevMenu and RCTDevSettings TurboModule-compatible Summary: Changelog: [iOS][Added] - Make RCTDevMenu and RCTDevSettings TurboModule-compatible Reviewed By: shergin Differential Revision: D18148890 fbshipit-source-id: bd4f0b2797e299cd963e34fa47044a9e1232efe0
2019-11-05 02:58:49 +03:00
- React-CoreModules (= 1000.0.0)
Make RCTTestModule TurboModule-compatible Reviewed By: fkgozali Differential Revision: D18545790 fbshipit-source-id: 035df69671ec44d13b79b014bfe90f5af9f43e58
2020-02-02 02:03:28 +03:00
- React-jsi (= 1000.0.0)
- ReactCommon/turbomodule/core (= 1000.0.0)
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
- React-RCTText (1000.0.0):
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- React-Core/RCTTextHeaders (= 1000.0.0)
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
- React-RCTVibration (1000.0.0):
Make RCTVibration TurboModule-compatible Summary: Making RCTVibration TurboModule-compatible. Reviewed By: PeteTheHeat Differential Revision: D17581373 fbshipit-source-id: a7aa2d12e7251d332c855435c2f0d83d87f0d2ac
2019-10-01 21:07:08 +03:00
- FBReactNativeSpec (= 1000.0.0)
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
- Folly (= 2020.01.13.00)
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- React-Core/RCTVibrationHeaders (= 1000.0.0)
Fix Cocoapods builds Summary: ## Problem For some reason, D20831545 broke the `use_frameworks!` build of RNTester. ## Building RNTester ``` pushd ~/fbsource/xplat/js/react-native-github/RNTester && USE_FRAMEWORKS=1 pod install && open RNTesterPods.xcworkspace && popd; ``` ## Error I built RNTester locally, and the error was this: ``` Undefined symbols for architecture x86_64: "facebook::jsi::HostObject::set(facebook::jsi::Runtime&, facebook::jsi::PropNameID const&, facebook::jsi::Value const&)", referenced from: vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o "facebook::jsi::HostObject::getPropertyNames(facebook::jsi::Runtime&)", referenced from: vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o ld: symbol(s) not found for architecture x86_64 ``` ## Fix It looked like libraries that depend on "ReactCommon/turbomodule/core" weren't linking to JSI correctly. So, I modified all such Podspecs to also depend on "React-jsi": ``` arc rfr ' s.dependency "ReactCommon/turbomodule/core", version' ' s.dependency "ReactCommon/turbomodule/core", version\n s.dependency "React-jsi", version' ``` This seemed to do the trick. In buck, we'd fix this problem using exported_dependencies. I skimmed through cocoapods, and couldn't find such a configuration option there. So, I guess this will have to do? Changelog: [iOS][Fixed] - Fix Cocoapods builds of RNTester Reviewed By: fkgozali, hramos Differential Revision: D20905465 fbshipit-source-id: 60218c8274ec165752a428f2a7a9a546607c8fec
2020-04-08 05:04:25 +03:00
- React-jsi (= 1000.0.0)
Fix podspecs Summary: I kept on running `USE_FRAMEWORKS=1 update-pods && open RNTesterPods.xcworkspace` and adding missing dependencies until `RNTesterPods` started compiling without failure. **Note:** I made sure to only commit the podfile changes from `update-pods`, **without** `USE_FRAMEWORKS=1`. Changelog: [iOS][Fixed] - Fix all RN Podspecs Reviewed By: fkgozali Differential Revision: D18284535 fbshipit-source-id: 44d288ae0e52dd2cbbe26bebe7df73ce05644b5d
2019-11-02 05:32:48 +03:00
- ReactCommon/turbomodule/core (= 1000.0.0)
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-09 02:10:38 +03:00
- React-runtimeexecutor (1000.0.0):
- React-jsi (= 1000.0.0)
TM iOS: refactor header dir for TM Summary: For better cocoapods compatibility, refactored TM podspec to be a subspec of ReactCommon, then use `<ReactCommon/` header prefix for all TM files. Relevant efforts: https://github.com/facebook/react-native/pull/25619 https://github.com/facebook/react-native/pull/25393 Reviewed By: hramos Differential Revision: D16231697 fbshipit-source-id: 38d3418b19978ff54aa0c61b064ac45ac0e1c36c
2019-07-13 08:34:14 +03:00
- ReactCommon/turbomodule/core (1000.0.0):
- DoubleConversion
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
- Folly (= 2020.01.13.00)
TM iOS: refactor header dir for TM Summary: For better cocoapods compatibility, refactored TM podspec to be a subspec of ReactCommon, then use `<ReactCommon/` header prefix for all TM files. Relevant efforts: https://github.com/facebook/react-native/pull/25619 https://github.com/facebook/react-native/pull/25393 Reviewed By: hramos Differential Revision: D16231697 fbshipit-source-id: 38d3418b19978ff54aa0c61b064ac45ac0e1c36c
2019-07-13 08:34:14 +03:00
- glog
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 21:36:50 +03:00
- React-callinvoker (= 1000.0.0)
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- React-Core (= 1000.0.0)
TM iOS: Install TurboModule system in RNTester (pod) by default Summary: For CocoaPods variant only: install TurboModule binding so that sample modules can start using it. This commit only installs `global.__turboModuleProxy` - no sample module is provided. Note: RNTester.xcodeproj will NOT have TurboModule enabled, due to complication in the .xcodeproj setup (doable, but maybe for some other time...) To test: ``` console.error(global.__turboModuleProxy == null ? 'BOO' : 'YAY!'); ``` Saw `YAY!` in RNTester pod version. Reviewed By: cpojer Differential Revision: D14932536 fbshipit-source-id: 3dc083da9154ec320ce6789ec7f2cef5a08fd6a7
2019-04-15 22:07:02 +03:00
- React-cxxreact (= 1000.0.0)
- React-jsi (= 1000.0.0)
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-14 06:24:37 +03:00
- React-perflogger (= 1000.0.0)
TM iOS: refactor header dir for TM Summary: For better cocoapods compatibility, refactored TM podspec to be a subspec of ReactCommon, then use `<ReactCommon/` header prefix for all TM files. Relevant efforts: https://github.com/facebook/react-native/pull/25619 https://github.com/facebook/react-native/pull/25393 Reviewed By: hramos Differential Revision: D16231697 fbshipit-source-id: 38d3418b19978ff54aa0c61b064ac45ac0e1c36c
2019-07-13 08:34:14 +03:00
- ReactCommon/turbomodule/samples (1000.0.0):
- DoubleConversion
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
- Folly (= 2020.01.13.00)
TM iOS: refactor header dir for TM Summary: For better cocoapods compatibility, refactored TM podspec to be a subspec of ReactCommon, then use `<ReactCommon/` header prefix for all TM files. Relevant efforts: https://github.com/facebook/react-native/pull/25619 https://github.com/facebook/react-native/pull/25393 Reviewed By: hramos Differential Revision: D16231697 fbshipit-source-id: 38d3418b19978ff54aa0c61b064ac45ac0e1c36c
2019-07-13 08:34:14 +03:00
- glog
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 21:36:50 +03:00
- React-callinvoker (= 1000.0.0)
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- React-Core (= 1000.0.0)
TM iOS: Install TurboModule system in RNTester (pod) by default Summary: For CocoaPods variant only: install TurboModule binding so that sample modules can start using it. This commit only installs `global.__turboModuleProxy` - no sample module is provided. Note: RNTester.xcodeproj will NOT have TurboModule enabled, due to complication in the .xcodeproj setup (doable, but maybe for some other time...) To test: ``` console.error(global.__turboModuleProxy == null ? 'BOO' : 'YAY!'); ``` Saw `YAY!` in RNTester pod version. Reviewed By: cpojer Differential Revision: D14932536 fbshipit-source-id: 3dc083da9154ec320ce6789ec7f2cef5a08fd6a7
2019-04-15 22:07:02 +03:00
- React-cxxreact (= 1000.0.0)
- React-jsi (= 1000.0.0)
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-14 06:24:37 +03:00
- React-perflogger (= 1000.0.0)
TM iOS: refactor header dir for TM Summary: For better cocoapods compatibility, refactored TM podspec to be a subspec of ReactCommon, then use `<ReactCommon/` header prefix for all TM files. Relevant efforts: https://github.com/facebook/react-native/pull/25619 https://github.com/facebook/react-native/pull/25393 Reviewed By: hramos Differential Revision: D16231697 fbshipit-source-id: 38d3418b19978ff54aa0c61b064ac45ac0e1c36c
2019-07-13 08:34:14 +03:00
- ReactCommon/turbomodule/core (= 1000.0.0)
Add Appearance native module Summary: Implements the Appearance native module as discussed in https://github.com/react-native-community/discussions-and-proposals/issues/126. The purpose of the Appearance native module is to expose the user's appearance preferences. It provides a basic get() API that returns the user's preferred color scheme on iOS 13 devices, also known as Dark Mode. It also provides the ability to subscribe to events whenever an appearance preference changes. The name, "Appearance", was chosen purposefully to allow for future expansion to cover other appearance preferences such as reduced motion, reduced transparency, or high contrast modes. Changelog: [iOS] [Added] - The Appearance native module can be used to prepare your app for Dark Mode on iOS 13. Reviewed By: yungsters Differential Revision: D16699954 fbshipit-source-id: 03b4cc5d2a1a69f31f3a6d9bece23f6867b774ea
2019-08-31 03:06:03 +03:00
- Yoga (1.14.0)
@allow-large-files [Flipper][RN] Integrated Flipper in RNTester application Summary: Changelog: [iOS] [Fixed] Integrated Flipper in RNTester application and made sure that flipper connects with RNTester application allow-large-files Reviewed By: rickhanlonii Differential Revision: D19813213 fbshipit-source-id: f0c7a5a42ffaccd488582b0f42ce37aea946c636
2020-02-12 15:46:58 +03:00
- YogaKit (1.18.1):
- Yoga (~> 1.14)
iOS OSS: check in the Podfile.lock Summary: Should have been checked in previously. No setup change here. Reviewed By: shergin Differential Revision: D7626040 fbshipit-source-id: e7a1a9de70a40a22e39eb3777d1b62c8d7b66381
2018-04-14 03:19:01 +03:00
DEPENDENCIES:
- DoubleConversion (from `../third-party-podspecs/DoubleConversion.podspec`)
TM iOS: Set up CocoaPods specs for the TM specs Summary: This defines various sub specs to support building TurboModules that implement the codegen'ed specs. Reviewed By: PeteTheHeat Differential Revision: D16043221 fbshipit-source-id: 27ed532be929c11c8fe648632da8a72061cbc8b0
2019-07-02 01:12:56 +03:00
- FBLazyVector (from `../Libraries/FBLazyVector`)
- FBReactNativeSpec (from `../Libraries/FBReactNativeSpec`)
iOS: Fix Animated image crash when CADisplayLink target in RCTWeakProxy is nil Summary: ## Problem When self is nil, this may crash in RCTUIImageViewAnimated.m. ``` _displayLink = [CADisplayLink displayLinkWithTarget:[RCTWeakProxy weakProxyWithTarget:self] selector:selector(displayDidRefresh:)]; ``` ## Fix Replace `RCTWeakProxy` with a concrete class `RCTDisplayWeakRefreshable` that has the displayDidRefresh method, that calls the displayDidRefresh method in its weak target. ### Original Github Issue https://github.com/facebook/react-native/pull/28070#issuecomment-619295254 Changelog: [iOS] [Fixed] - Fix Animated image crash when CADisplayLink target in RCTWeakProxy is nil Reviewed By: shergin Differential Revision: D21419385 fbshipit-source-id: da7c3c38f81ea54f633da7f59359e07680ea2faf
2020-05-13 03:06:24 +03:00
- Flipper (~> 0.41.1)
Fix Cocoapods builds Summary: ## Problem For some reason, D20831545 broke the `use_frameworks!` build of RNTester. ## Building RNTester ``` pushd ~/fbsource/xplat/js/react-native-github/RNTester && USE_FRAMEWORKS=1 pod install && open RNTesterPods.xcworkspace && popd; ``` ## Error I built RNTester locally, and the error was this: ``` Undefined symbols for architecture x86_64: "facebook::jsi::HostObject::set(facebook::jsi::Runtime&, facebook::jsi::PropNameID const&, facebook::jsi::Value const&)", referenced from: vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o "facebook::jsi::HostObject::getPropertyNames(facebook::jsi::Runtime&)", referenced from: vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o ld: symbol(s) not found for architecture x86_64 ``` ## Fix It looked like libraries that depend on "ReactCommon/turbomodule/core" weren't linking to JSI correctly. So, I modified all such Podspecs to also depend on "React-jsi": ``` arc rfr ' s.dependency "ReactCommon/turbomodule/core", version' ' s.dependency "ReactCommon/turbomodule/core", version\n s.dependency "React-jsi", version' ``` This seemed to do the trick. In buck, we'd fix this problem using exported_dependencies. I skimmed through cocoapods, and couldn't find such a configuration option there. So, I guess this will have to do? Changelog: [iOS][Fixed] - Fix Cocoapods builds of RNTester Reviewed By: fkgozali, hramos Differential Revision: D20905465 fbshipit-source-id: 60218c8274ec165752a428f2a7a9a546607c8fec
2020-04-08 05:04:25 +03:00
- Flipper-DoubleConversion (= 1.1.7)
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-22 03:43:59 +03:00
- Flipper-Folly (~> 2.2)
Fix Cocoapods builds Summary: ## Problem For some reason, D20831545 broke the `use_frameworks!` build of RNTester. ## Building RNTester ``` pushd ~/fbsource/xplat/js/react-native-github/RNTester && USE_FRAMEWORKS=1 pod install && open RNTesterPods.xcworkspace && popd; ``` ## Error I built RNTester locally, and the error was this: ``` Undefined symbols for architecture x86_64: "facebook::jsi::HostObject::set(facebook::jsi::Runtime&, facebook::jsi::PropNameID const&, facebook::jsi::Value const&)", referenced from: vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o "facebook::jsi::HostObject::getPropertyNames(facebook::jsi::Runtime&)", referenced from: vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o ld: symbol(s) not found for architecture x86_64 ``` ## Fix It looked like libraries that depend on "ReactCommon/turbomodule/core" weren't linking to JSI correctly. So, I modified all such Podspecs to also depend on "React-jsi": ``` arc rfr ' s.dependency "ReactCommon/turbomodule/core", version' ' s.dependency "ReactCommon/turbomodule/core", version\n s.dependency "React-jsi", version' ``` This seemed to do the trick. In buck, we'd fix this problem using exported_dependencies. I skimmed through cocoapods, and couldn't find such a configuration option there. So, I guess this will have to do? Changelog: [iOS][Fixed] - Fix Cocoapods builds of RNTester Reviewed By: fkgozali, hramos Differential Revision: D20905465 fbshipit-source-id: 60218c8274ec165752a428f2a7a9a546607c8fec
2020-04-08 05:04:25 +03:00
- Flipper-Glog (= 0.3.6)
- Flipper-PeerTalk (~> 0.0.4)
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-22 03:43:59 +03:00
- Flipper-RSocket (~> 1.1)
iOS: Fix Animated image crash when CADisplayLink target in RCTWeakProxy is nil Summary: ## Problem When self is nil, this may crash in RCTUIImageViewAnimated.m. ``` _displayLink = [CADisplayLink displayLinkWithTarget:[RCTWeakProxy weakProxyWithTarget:self] selector:selector(displayDidRefresh:)]; ``` ## Fix Replace `RCTWeakProxy` with a concrete class `RCTDisplayWeakRefreshable` that has the displayDidRefresh method, that calls the displayDidRefresh method in its weak target. ### Original Github Issue https://github.com/facebook/react-native/pull/28070#issuecomment-619295254 Changelog: [iOS] [Fixed] - Fix Animated image crash when CADisplayLink target in RCTWeakProxy is nil Reviewed By: shergin Differential Revision: D21419385 fbshipit-source-id: da7c3c38f81ea54f633da7f59359e07680ea2faf
2020-05-13 03:06:24 +03:00
- FlipperKit (~> 0.41.1)
- FlipperKit/Core (~> 0.41.1)
- FlipperKit/CppBridge (~> 0.41.1)
- FlipperKit/FBCxxFollyDynamicConvert (~> 0.41.1)
- FlipperKit/FBDefines (~> 0.41.1)
- FlipperKit/FKPortForwarding (~> 0.41.1)
- FlipperKit/FlipperKitHighlightOverlay (~> 0.41.1)
- FlipperKit/FlipperKitLayoutPlugin (~> 0.41.1)
- FlipperKit/FlipperKitLayoutTextSearchable (~> 0.41.1)
- FlipperKit/FlipperKitNetworkPlugin (~> 0.41.1)
- FlipperKit/FlipperKitReactPlugin (~> 0.41.1)
- FlipperKit/FlipperKitUserDefaultsPlugin (~> 0.41.1)
- FlipperKit/SKIOSNetworkPlugin (~> 0.41.1)
iOS OSS: check in the Podfile.lock Summary: Should have been checked in previously. No setup change here. Reviewed By: shergin Differential Revision: D7626040 fbshipit-source-id: e7a1a9de70a40a22e39eb3777d1b62c8d7b66381
2018-04-14 03:19:01 +03:00
- Folly (from `../third-party-podspecs/Folly.podspec`)
- glog (from `../third-party-podspecs/glog.podspec`)
TM iOS: Set up CocoaPods specs for the TM specs Summary: This defines various sub specs to support building TurboModules that implement the codegen'ed specs. Reviewed By: PeteTheHeat Differential Revision: D16043221 fbshipit-source-id: 27ed532be929c11c8fe648632da8a72061cbc8b0
2019-07-02 01:12:56 +03:00
- RCTRequired (from `../Libraries/RCTRequired`)
iOS: Use RCTTypeSafety header namespace instead of React Summary: For better compatibility re: https://github.com/facebook/react-native/pull/25393, this target should just use `RCTTypeSafety` Reviewed By: PeteTheHeat Differential Revision: D16210888 fbshipit-source-id: 6a55d631453cc420909247a7d5a64379587225b7
2019-07-13 00:24:55 +03:00
- RCTTypeSafety (from `../Libraries/TypeSafety`)
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
- React (from `../`)
- React-ART (from `../Libraries/ART`)
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 21:36:50 +03:00
- React-callinvoker (from `../ReactCommon/callinvoker`)
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
- React-Core (from `../`)
Remove 's.static_framework = true' requirement for podspec (#25816) Summary: As part of the fix for https://github.com/facebook/react-native/issues/25349 I added `s.static_framework = true` to each podspec in repo (see https://github.com/facebook/react-native/pull/25619#discussion_r306993309 for more context). This was required to ensure the existing conditional compilation with `#if RCT_DEV` and `__has_include` still worked correctly when `use_frameworks!` is enabled. However, fkgozali pointed out that it would be ideal if we didn't have this requirement as it could make life difficult for third-party libraries. This removes the requirement by moving `React-DevSupport.podspec` and `React-RCTWebSocket.podspec` into `React-Core.podspec` as subspecs. This means the symbols are present when `React-Core.podspec` is built dynamically so `s.static_framework = true` isn't required. This means that any `Podfile` that refers to `React-DevSupport` or `React-RCTWebSocket` will need to be updated to avoid errors. ## Changelog I don't think this needs a changelog entry since its just a refinement of https://github.com/facebook/react-native/pull/25619. Pull Request resolved: https://github.com/facebook/react-native/pull/25816 Test Plan: Check `RNTesterPods` still works both with and without `use_frameworks!`: 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: hramos Differential Revision: D16495030 Pulled By: fkgozali fbshipit-source-id: 2708ac9fd20cd04cb0aea61b2e8ab0d931dfb6d5
2019-07-25 21:42:49 +03:00
- React-Core/DevSupport (from `../`)
- React-Core/RCTWebSocket (from `../`)
TM iOS: Set up CocoaPods specs for the TM specs Summary: This defines various sub specs to support building TurboModules that implement the codegen'ed specs. Reviewed By: PeteTheHeat Differential Revision: D16043221 fbshipit-source-id: 27ed532be929c11c8fe648632da8a72061cbc8b0
2019-07-02 01:12:56 +03:00
- React-CoreModules (from `../React/CoreModules`)
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
- React-cxxreact (from `../ReactCommon/cxxreact`)
- React-jsi (from `../ReactCommon/jsi`)
- React-jsiexecutor (from `../ReactCommon/jsiexecutor`)
- React-jsinspector (from `../ReactCommon/jsinspector`)
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-16 01:21:25 +03:00
- React-perflogger (from `../ReactCommon/reactperflogger`)
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
- React-RCTActionSheet (from `../Libraries/ActionSheetIOS`)
- React-RCTAnimation (from `../Libraries/NativeAnimation`)
- React-RCTBlob (from `../Libraries/Blob`)
- React-RCTImage (from `../Libraries/Image`)
- React-RCTLinking (from `../Libraries/LinkingIOS`)
- React-RCTNetwork (from `../Libraries/Network`)
- React-RCTPushNotification (from `../Libraries/PushNotificationIOS`)
- React-RCTSettings (from `../Libraries/Settings`)
Make RCTTestModule TurboModule-compatible Reviewed By: fkgozali Differential Revision: D18545790 fbshipit-source-id: 035df69671ec44d13b79b014bfe90f5af9f43e58
2020-02-02 02:03:28 +03:00
- React-RCTTest (from `./RCTTest`)
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
- React-RCTText (from `../Libraries/Text`)
- React-RCTVibration (from `../Libraries/Vibration`)
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-09 02:10:38 +03:00
- React-runtimeexecutor (from `../ReactCommon/runtimeexecutor`)
TM iOS: refactor header dir for TM Summary: For better cocoapods compatibility, refactored TM podspec to be a subspec of ReactCommon, then use `<ReactCommon/` header prefix for all TM files. Relevant efforts: https://github.com/facebook/react-native/pull/25619 https://github.com/facebook/react-native/pull/25393 Reviewed By: hramos Differential Revision: D16231697 fbshipit-source-id: 38d3418b19978ff54aa0c61b064ac45ac0e1c36c
2019-07-13 08:34:14 +03:00
- ReactCommon/turbomodule/core (from `../ReactCommon`)
- ReactCommon/turbomodule/samples (from `../ReactCommon`)
Change podspec name of yoga to Yoga Summary: Needed to capitalize the name, since this is the convention used elsewhere too ## Changelog: [iOS] [Changed] - Renamed yoga podspec to Yoga Reviewed By: shergin Differential Revision: D17127104 fbshipit-source-id: 14047bf452edda000037701f4ba7f4a02a0e717b
2019-08-30 17:10:51 +03:00
- Yoga (from `../ReactCommon/yoga`)
iOS OSS: check in the Podfile.lock Summary: Should have been checked in previously. No setup change here. Reviewed By: shergin Differential Revision: D7626040 fbshipit-source-id: e7a1a9de70a40a22e39eb3777d1b62c8d7b66381
2018-04-14 03:19:01 +03:00
SPEC REPOS:
Allow extensions to set their own presentedViewController Summary: Since extensions does not have access to sharedApplication, give them an option to set the presentedViewController. This will allow modules such as RCTAlertsManager to function correctly in extensions. Changelog: [General] [Added] - Added RCTUtilsUIOverride as a way to shortcut obtaining presentedViewController from sharedApplication to a supplied view controller for extensions. Reviewed By: PeteTheHeat Differential Revision: D18620886 fbshipit-source-id: c752a6e328588f388e23be5270bf7da277182cca
2019-11-22 11:45:19 +03:00
trunk:
iOS OSS: check in the Podfile.lock Summary: Should have been checked in previously. No setup change here. Reviewed By: shergin Differential Revision: D7626040 fbshipit-source-id: e7a1a9de70a40a22e39eb3777d1b62c8d7b66381
2018-04-14 03:19:01 +03:00
- boost-for-react-native
@allow-large-files [Flipper][RN] Integrated Flipper in RNTester application Summary: Changelog: [iOS] [Fixed] Integrated Flipper in RNTester application and made sure that flipper connects with RNTester application allow-large-files Reviewed By: rickhanlonii Differential Revision: D19813213 fbshipit-source-id: f0c7a5a42ffaccd488582b0f42ce37aea946c636
2020-02-12 15:46:58 +03:00
- CocoaAsyncSocket
- CocoaLibEvent
- Flipper
- Flipper-DoubleConversion
- Flipper-Folly
- Flipper-Glog
- Flipper-PeerTalk
- Flipper-RSocket
- FlipperKit
- OpenSSL-Universal
- YogaKit
iOS OSS: check in the Podfile.lock Summary: Should have been checked in previously. No setup change here. Reviewed By: shergin Differential Revision: D7626040 fbshipit-source-id: e7a1a9de70a40a22e39eb3777d1b62c8d7b66381
2018-04-14 03:19:01 +03:00
EXTERNAL SOURCES:
DoubleConversion:
:podspec: "../third-party-podspecs/DoubleConversion.podspec"
TM iOS: Set up CocoaPods specs for the TM specs Summary: This defines various sub specs to support building TurboModules that implement the codegen'ed specs. Reviewed By: PeteTheHeat Differential Revision: D16043221 fbshipit-source-id: 27ed532be929c11c8fe648632da8a72061cbc8b0
2019-07-02 01:12:56 +03:00
FBLazyVector:
:path: "../Libraries/FBLazyVector"
FBReactNativeSpec:
:path: "../Libraries/FBReactNativeSpec"
iOS OSS: check in the Podfile.lock Summary: Should have been checked in previously. No setup change here. Reviewed By: shergin Differential Revision: D7626040 fbshipit-source-id: e7a1a9de70a40a22e39eb3777d1b62c8d7b66381
2018-04-14 03:19:01 +03:00
Folly:
:podspec: "../third-party-podspecs/Folly.podspec"
glog:
:podspec: "../third-party-podspecs/glog.podspec"
TM iOS: Set up CocoaPods specs for the TM specs Summary: This defines various sub specs to support building TurboModules that implement the codegen'ed specs. Reviewed By: PeteTheHeat Differential Revision: D16043221 fbshipit-source-id: 27ed532be929c11c8fe648632da8a72061cbc8b0
2019-07-02 01:12:56 +03:00
RCTRequired:
:path: "../Libraries/RCTRequired"
iOS: Use RCTTypeSafety header namespace instead of React Summary: For better compatibility re: https://github.com/facebook/react-native/pull/25393, this target should just use `RCTTypeSafety` Reviewed By: PeteTheHeat Differential Revision: D16210888 fbshipit-source-id: 6a55d631453cc420909247a7d5a64379587225b7
2019-07-13 00:24:55 +03:00
RCTTypeSafety:
:path: "../Libraries/TypeSafety"
iOS OSS: check in the Podfile.lock Summary: Should have been checked in previously. No setup change here. Reviewed By: shergin Differential Revision: D7626040 fbshipit-source-id: e7a1a9de70a40a22e39eb3777d1b62c8d7b66381
2018-04-14 03:19:01 +03:00
React:
:path: "../"
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
React-ART:
:path: "../Libraries/ART"
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 21:36:50 +03:00
React-callinvoker:
:path: "../ReactCommon/callinvoker"
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
React-Core:
CocoaPods frameworks compatibility: Step 2 (#25619) Summary: This is my proposal for fixing `use_frameworks!` compatibility without breaking all `<React/*>` imports I outlined in https://github.com/facebook/react-native/pull/25393#issuecomment-508457700. If accepted, it will fix https://github.com/facebook/react-native/issues/25349. It builds on the changes I made in https://github.com/facebook/react-native/pull/25496 by ensuring each podspec has a unique value for `header_dir` so that framework imports do not conflict. Every podspec which should be included in the `<React/*>` namespace now includes it's headers from `React-Core.podspec`. The following pods can still be imported with `<React/*>` and so should not have breaking changes: `React-ART`,`React-DevSupport`, `React-CoreModules`, `React-RCTActionSheet`, `React-RCTAnimation`, `React-RCTBlob`, `React-RCTImage`, `React-RCTLinking`, `React-RCTNetwork`, `React-RCTPushNotification`, `React-RCTSettings`, `React-RCTText`, `React-RCTSettings`, `React-RCTVibration`, `React-RCTWebSocket` . There are still a few breaking changes which I hope will be acceptable: - `React-Core.podspec` has been moved to the root of the project. Any `Podfile` that references it will need to update the path. - ~~`React-turbomodule-core`'s headers now live under `<turbomodule/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-turbomodulesamples`'s headers now live under `<turbomodulesamples/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - ~~`React-TypeSaferty`'s headers now live under `<TypeSafety/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511040967. - ~~`React-jscallinvoker`'s headers now live under `<jscallinvoker/*>`~~ Replaced by https://github.com/facebook/react-native/pull/25619#issuecomment-511091823. - Each podspec now uses `s.static_framework = true`. This means that a minimum of CocoaPods 1.5 ([released in April 2018](http://blog.cocoapods.org/CocoaPods-1.5.0/)) is now required. This is needed so that the ` __has_include` conditions can still work when frameworks are enabled. Still to do: - ~~Including `React-turbomodule-core` with `use_frameworks!` enabled causes the C++ import failures we saw in https://github.com/facebook/react-native/issues/25349. I'm sure it will be possible to fix this but I need to dig deeper (perhaps a custom modulemap would be needed).~~ Addressed by https://github.com/facebook/react-native/pull/25619/commits/33573511f02f3502a28bad48e085e9a4b8608302. - I haven't got Fabric working yet. I wonder if it would be acceptable to move Fabric out of the `<React/*>` namespace since it is new? � ## Changelog [iOS] [Fixed] - Fixed compatibility with CocoaPods frameworks. Pull Request resolved: https://github.com/facebook/react-native/pull/25619 Test Plan: ### FB ``` buck build catalyst ``` ### Sample Project Everything should work exactly as before, where `use_frameworks!` is not in `Podfile`s. I have a branch on my [sample project](https://github.com/jtreanor/react-native-cocoapods-frameworks) here which has `use_frameworks!` in its `Podfile` to demonstrate this is fixed. You can see that it works with these steps: 1. `git clone git@github.com:jtreanor/react-native-cocoapods-frameworks.git` 2. `git checkout fix-frameworks-subspecs` 3. `cd ios && pod install` 4. `cd .. && react-native run-ios` The sample app will build and run successfully. To see that it still works without frameworks, remove `use_frameworks!` from the `Podfile` and do steps 3 and 4 again. ### RNTesterPods `RNTesterPodsPods` can now work with or without `use_frameworks!`. 1. Go to the `RNTester` directory and run `pod install`. 2. Run the tests in `RNTesterPods.xcworkspace` to see that everything still works fine. 3. Uncomment the `use_frameworks!` line at the top of `RNTester/Podfile` and run `pod install` again. 4. Run the tests again and see that it still works with frameworks enabled. Reviewed By: PeteTheHeat Differential Revision: D16465247 Pulled By: PeteTheHeat fbshipit-source-id: cad837e9cced06d30cc5b372af1c65c7780b9e7a
2019-07-25 08:26:42 +03:00
:path: "../"
TM iOS: Set up CocoaPods specs for the TM specs Summary: This defines various sub specs to support building TurboModules that implement the codegen'ed specs. Reviewed By: PeteTheHeat Differential Revision: D16043221 fbshipit-source-id: 27ed532be929c11c8fe648632da8a72061cbc8b0
2019-07-02 01:12:56 +03:00
React-CoreModules:
:path: "../React/CoreModules"
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
React-cxxreact:
:path: "../ReactCommon/cxxreact"
React-jsi:
:path: "../ReactCommon/jsi"
React-jsiexecutor:
:path: "../ReactCommon/jsiexecutor"
React-jsinspector:
:path: "../ReactCommon/jsinspector"
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-14 06:24:37 +03:00
React-perflogger:
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-16 01:21:25 +03:00
:path: "../ReactCommon/reactperflogger"
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
React-RCTActionSheet:
:path: "../Libraries/ActionSheetIOS"
React-RCTAnimation:
:path: "../Libraries/NativeAnimation"
React-RCTBlob:
:path: "../Libraries/Blob"
React-RCTImage:
:path: "../Libraries/Image"
React-RCTLinking:
:path: "../Libraries/LinkingIOS"
React-RCTNetwork:
:path: "../Libraries/Network"
React-RCTPushNotification:
:path: "../Libraries/PushNotificationIOS"
React-RCTSettings:
:path: "../Libraries/Settings"
Move Pods to react-native-github Summary: Now that the Pods/ directory is excluded by ShipIt from GitHub, we can move the Pods/ directory into react-native-github. Reviewed By: fkgozali Differential Revision: D15944730 fbshipit-source-id: b8165abbb4e6fef5ad4311da3885187b84ad1b20
2019-06-26 18:39:43 +03:00
React-RCTTest:
Make RCTTestModule TurboModule-compatible Reviewed By: fkgozali Differential Revision: D18545790 fbshipit-source-id: 035df69671ec44d13b79b014bfe90f5af9f43e58
2020-02-02 02:03:28 +03:00
:path: "./RCTTest"
Split React.podspec into separate podspecs for each Xcode project (#23559) Summary: This PR implements the first part of [RFC0004: CocoaPods Support Improvements](https://github.com/react-native-community/discussions-and-proposals/blob/353d44f64957113409eb16f836e23dba396a6b46/proposals/0004-cocoapods-support-improvements.md), splitting the `React.podspec` into separate podspecs to more closely match the structure of Xcode projects. The new structure aims to have one to one mapping between Xcode projects and podspecs. The only places where we differ from this mapping are: * `React/React-DevSupport.podspec`: `DevSupport` is a part of `React.xcodeproj`, which corresponds to the `React-Core` pod. However, we can't include it in the `React-Core` pod because `DevSupport` depends on `React-RCTWebSocket`, which depends on `React-Core`. Pods may not have circular dependencies. * The new pods under `ReactCommon/` don't have a corresponding `xcodeproj` because there are no `xcodproj` files in `ReactCommon/`. Those C++ modules are included in `React.xcodeproj`. *Next steps (not in scope of this PR):* - Start submitting the Podspecs to CocoaPods on a deploy (or turn the React Native repo into a spec repo): this is important in order to make the experience nicer for library consumers, so that it's not necessary to specify the local path of each Podspec in `Podfile`, you can just add `pod 'React', <version>`. - Add `Podfile` to the default project template (I have a PR ready for this, but because of bugs related to subspecs, it's blocked on this PR) [iOS] [Changed] - Split React.podspec into separate podspecs for each Xcode project Pull Request resolved: https://github.com/facebook/react-native/pull/23559 Differential Revision: D14179326 Pulled By: cpojer fbshipit-source-id: 397a9c30b6b5d24f86c790057c71f0d403f56c3d
2019-02-22 05:22:05 +03:00
React-RCTText:
:path: "../Libraries/Text"
React-RCTVibration:
:path: "../Libraries/Vibration"
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-09 02:10:38 +03:00
React-runtimeexecutor:
:path: "../ReactCommon/runtimeexecutor"
TM iOS: refactor header dir for TM Summary: For better cocoapods compatibility, refactored TM podspec to be a subspec of ReactCommon, then use `<ReactCommon/` header prefix for all TM files. Relevant efforts: https://github.com/facebook/react-native/pull/25619 https://github.com/facebook/react-native/pull/25393 Reviewed By: hramos Differential Revision: D16231697 fbshipit-source-id: 38d3418b19978ff54aa0c61b064ac45ac0e1c36c
2019-07-13 08:34:14 +03:00
ReactCommon:
:path: "../ReactCommon"
Change podspec name of yoga to Yoga Summary: Needed to capitalize the name, since this is the convention used elsewhere too ## Changelog: [iOS] [Changed] - Renamed yoga podspec to Yoga Reviewed By: shergin Differential Revision: D17127104 fbshipit-source-id: 14047bf452edda000037701f4ba7f4a02a0e717b
2019-08-30 17:10:51 +03:00
Yoga:
iOS OSS: check in the Podfile.lock Summary: Should have been checked in previously. No setup change here. Reviewed By: shergin Differential Revision: D7626040 fbshipit-source-id: e7a1a9de70a40a22e39eb3777d1b62c8d7b66381
2018-04-14 03:19:01 +03:00
:path: "../ReactCommon/yoga"
SPEC CHECKSUMS:
boost-for-react-native: 39c7adb57c4e60d6c5479dd8623128eb5b3f0f2c
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 21:36:50 +03:00
CocoaAsyncSocket: 694058e7c0ed05a9e217d1b3c7ded962f4180845
@allow-large-files [Flipper][RN] Integrated Flipper in RNTester application Summary: Changelog: [iOS] [Fixed] Integrated Flipper in RNTester application and made sure that flipper connects with RNTester application allow-large-files Reviewed By: rickhanlonii Differential Revision: D19813213 fbshipit-source-id: f0c7a5a42ffaccd488582b0f42ce37aea946c636
2020-02-12 15:46:58 +03:00
CocoaLibEvent: 2fab71b8bd46dd33ddb959f7928ec5909f838e3f
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
DoubleConversion: cde416483dac037923206447da6e1454df403714
Make RCTDevLoadingView TurboModule-compatible Summary: This is a redo of D16969764, with a few extensions. ## Changes 1. Move `RCTDevLoadingView.{h,m}` to `CoreModuels/RCTDevLoadingView.{h,mm}` 2. Extract ObjC API of `RCTDevLodingView` into `RCTDevLoadingViewProtocol` in `ReactInternal`. 3. Create API `RCTDevLoadingViewSetEnabled.h` in `ReactInternal` to enable/disable `RCTDevLoadingView` Changelog: [iOS][Added] - Make RCTDevLoadingView TurboModule-compatible Reviewed By: PeteTheHeat Differential Revision: D18642554 fbshipit-source-id: 6b62e27e128d98254b7a6d018399ec1c06e274fc
2020-02-28 04:01:18 +03:00
FBLazyVector: 8ea0285646adaf7fa725c20ed737c49ee5ea680a
FBReactNativeSpec: e8f07c749b9cf184c819f5a8ca44b91ab61fca12
iOS: Fix Animated image crash when CADisplayLink target in RCTWeakProxy is nil Summary: ## Problem When self is nil, this may crash in RCTUIImageViewAnimated.m. ``` _displayLink = [CADisplayLink displayLinkWithTarget:[RCTWeakProxy weakProxyWithTarget:self] selector:selector(displayDidRefresh:)]; ``` ## Fix Replace `RCTWeakProxy` with a concrete class `RCTDisplayWeakRefreshable` that has the displayDidRefresh method, that calls the displayDidRefresh method in its weak target. ### Original Github Issue https://github.com/facebook/react-native/pull/28070#issuecomment-619295254 Changelog: [iOS] [Fixed] - Fix Animated image crash when CADisplayLink target in RCTWeakProxy is nil Reviewed By: shergin Differential Revision: D21419385 fbshipit-source-id: da7c3c38f81ea54f633da7f59359e07680ea2faf
2020-05-13 03:06:24 +03:00
Flipper: 33585e2d9810fe5528346be33bcf71b37bb7ae13
@allow-large-files [Flipper][RN] Integrated Flipper in RNTester application Summary: Changelog: [iOS] [Fixed] Integrated Flipper in RNTester application and made sure that flipper connects with RNTester application allow-large-files Reviewed By: rickhanlonii Differential Revision: D19813213 fbshipit-source-id: f0c7a5a42ffaccd488582b0f42ce37aea946c636
2020-02-12 15:46:58 +03:00
Flipper-DoubleConversion: 38631e41ef4f9b12861c67d17cb5518d06badc41
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-22 03:43:59 +03:00
Flipper-Folly: c12092ea368353b58e992843a990a3225d4533c3
@allow-large-files [Flipper][RN] Integrated Flipper in RNTester application Summary: Changelog: [iOS] [Fixed] Integrated Flipper in RNTester application and made sure that flipper connects with RNTester application allow-large-files Reviewed By: rickhanlonii Differential Revision: D19813213 fbshipit-source-id: f0c7a5a42ffaccd488582b0f42ce37aea946c636
2020-02-12 15:46:58 +03:00
Flipper-Glog: 1dfd6abf1e922806c52ceb8701a3599a79a200a6
Flipper-PeerTalk: 116d8f857dc6ef55c7a5a75ea3ceaafe878aadc9
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-22 03:43:59 +03:00
Flipper-RSocket: 64e7431a55835eb953b0bf984ef3b90ae9fdddd7
iOS: Fix Animated image crash when CADisplayLink target in RCTWeakProxy is nil Summary: ## Problem When self is nil, this may crash in RCTUIImageViewAnimated.m. ``` _displayLink = [CADisplayLink displayLinkWithTarget:[RCTWeakProxy weakProxyWithTarget:self] selector:selector(displayDidRefresh:)]; ``` ## Fix Replace `RCTWeakProxy` with a concrete class `RCTDisplayWeakRefreshable` that has the displayDidRefresh method, that calls the displayDidRefresh method in its weak target. ### Original Github Issue https://github.com/facebook/react-native/pull/28070#issuecomment-619295254 Changelog: [iOS] [Fixed] - Fix Animated image crash when CADisplayLink target in RCTWeakProxy is nil Reviewed By: shergin Differential Revision: D21419385 fbshipit-source-id: da7c3c38f81ea54f633da7f59359e07680ea2faf
2020-05-13 03:06:24 +03:00
FlipperKit: bc68102cd4952a258a23c9c1b316c7bec1fecf83
Upgrade Folly to v2020.01.13.00 (#27810) Summary: Upgrade Folly to v2020.01.13.00. Fixes https://github.com/facebook/react-native/issues/27640 ## Changelog [iOS] [Changed] - Upgrade Folly to v2020.01.13.00 Pull Request resolved: https://github.com/facebook/react-native/pull/27810 Test Plan: Test by building and running RNTester Reviewed By: mdvacca Differential Revision: D19483115 Pulled By: fkgozali fbshipit-source-id: 4a85325a95b5f7857da75995d587218740d8b077
2020-01-21 23:41:45 +03:00
Folly: b73c3869541e86821df3c387eb0af5f65addfab4
glog: 40a13f7840415b9a77023fbcae0f1e6f43192af3
@allow-large-files [Flipper][RN] Integrated Flipper in RNTester application Summary: Changelog: [iOS] [Fixed] Integrated Flipper in RNTester application and made sure that flipper connects with RNTester application allow-large-files Reviewed By: rickhanlonii Differential Revision: D19813213 fbshipit-source-id: f0c7a5a42ffaccd488582b0f42ce37aea946c636
2020-02-12 15:46:58 +03:00
OpenSSL-Universal: 8b48cc0d10c1b2923617dfe5c178aa9ed2689355
Make RCTDevLoadingView TurboModule-compatible Summary: This is a redo of D16969764, with a few extensions. ## Changes 1. Move `RCTDevLoadingView.{h,m}` to `CoreModuels/RCTDevLoadingView.{h,mm}` 2. Extract ObjC API of `RCTDevLodingView` into `RCTDevLoadingViewProtocol` in `ReactInternal`. 3. Create API `RCTDevLoadingViewSetEnabled.h` in `ReactInternal` to enable/disable `RCTDevLoadingView` Changelog: [iOS][Added] - Make RCTDevLoadingView TurboModule-compatible Reviewed By: PeteTheHeat Differential Revision: D18642554 fbshipit-source-id: 6b62e27e128d98254b7a6d018399ec1c06e274fc
2020-02-28 04:01:18 +03:00
RCTRequired: 34582e9b3ebe69f244e091f37218d318406d5c4a
RCTTypeSafety: 1ade47a69b092cddf1e4ea21e0c5bdc65cc950b4
React: cafb3c2321f7df55ce90dbf29d513799a79e4418
React-ART: df0460bdff42ef039e28ee3ffd41f50b75644788
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 21:36:50 +03:00
React-callinvoker: 0dada022d38b73e6e15b33e2a96476153f79bbf6
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-14 06:24:37 +03:00
React-Core: d85e4563acbfbb6e6be7414a813ad55d05d675df
Fix Cocoapods builds Summary: ## Problem For some reason, D20831545 broke the `use_frameworks!` build of RNTester. ## Building RNTester ``` pushd ~/fbsource/xplat/js/react-native-github/RNTester && USE_FRAMEWORKS=1 pod install && open RNTesterPods.xcworkspace && popd; ``` ## Error I built RNTester locally, and the error was this: ``` Undefined symbols for architecture x86_64: "facebook::jsi::HostObject::set(facebook::jsi::Runtime&, facebook::jsi::PropNameID const&, facebook::jsi::Value const&)", referenced from: vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o "facebook::jsi::HostObject::getPropertyNames(facebook::jsi::Runtime&)", referenced from: vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o ld: symbol(s) not found for architecture x86_64 ``` ## Fix It looked like libraries that depend on "ReactCommon/turbomodule/core" weren't linking to JSI correctly. So, I modified all such Podspecs to also depend on "React-jsi": ``` arc rfr ' s.dependency "ReactCommon/turbomodule/core", version' ' s.dependency "ReactCommon/turbomodule/core", version\n s.dependency "React-jsi", version' ``` This seemed to do the trick. In buck, we'd fix this problem using exported_dependencies. I skimmed through cocoapods, and couldn't find such a configuration option there. So, I guess this will have to do? Changelog: [iOS][Fixed] - Fix Cocoapods builds of RNTester Reviewed By: fkgozali, hramos Differential Revision: D20905465 fbshipit-source-id: 60218c8274ec165752a428f2a7a9a546607c8fec
2020-04-08 05:04:25 +03:00
React-CoreModules: d13d148c851af5780f864be74bc2165140923dc7
Fix CircleCI by adding dependency on JSI to cxxreact (#29087) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/29087 D21908523 added an implicit dependency on `jsi.h` to use functions like `asObject`, etc. For some reason this doesn't break the build with BUCK (??) but it does with cocoapods. Adding the dep to the cxxreact podspec and regenerating offline mirrors to unbreak CircleCI. Also adding the BUCK dep and include statement for good measure. Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D21924592 fbshipit-source-id: 295c0670c6499e1195ba3c3a3320c6aee13bc025
2020-06-08 03:53:07 +03:00
React-cxxreact: 4661b3295e62c6eaada084e2f826c70c71ef11ea
Make RCTDevLoadingView TurboModule-compatible Summary: This is a redo of D16969764, with a few extensions. ## Changes 1. Move `RCTDevLoadingView.{h,m}` to `CoreModuels/RCTDevLoadingView.{h,mm}` 2. Extract ObjC API of `RCTDevLodingView` into `RCTDevLoadingViewProtocol` in `ReactInternal`. 3. Create API `RCTDevLoadingViewSetEnabled.h` in `ReactInternal` to enable/disable `RCTDevLoadingView` Changelog: [iOS][Added] - Make RCTDevLoadingView TurboModule-compatible Reviewed By: PeteTheHeat Differential Revision: D18642554 fbshipit-source-id: 6b62e27e128d98254b7a6d018399ec1c06e274fc
2020-02-28 04:01:18 +03:00
React-jsi: fe94132da767bfc4801968c2a12abae43e9a833e
Instrument JS requires Summary: This diff instruments two markers: - JSRequireBeginning: From the start of the JS require to when we start creating the platform NativeModule - JSRequireEnding: From the end of platform NativeModule create to the end of the JS require In order to accomplish this, I had modify `ModuleRegistry::ModuleRegistry()` to accept a `std::shared_ptr<NativeModulePerfLogger>`. I also had to implement the public method `ModuleRegistry::getNativeModulePerfLogger()` so that `JSINativeModules` could start logging the JS require beginning and ending. Changelog: [Internal] Reviewed By: PeteTheHeat Differential Revision: D21418803 fbshipit-source-id: 53828817ae41f23f3f04a95b1d3ac0012735da48
2020-05-14 06:24:37 +03:00
React-jsiexecutor: 959bb48c75a3bfc1b1d2b991087a6d8df721cbcf
Make RCTDevLoadingView TurboModule-compatible Summary: This is a redo of D16969764, with a few extensions. ## Changes 1. Move `RCTDevLoadingView.{h,m}` to `CoreModuels/RCTDevLoadingView.{h,mm}` 2. Extract ObjC API of `RCTDevLodingView` into `RCTDevLoadingViewProtocol` in `ReactInternal`. 3. Create API `RCTDevLoadingViewSetEnabled.h` in `ReactInternal` to enable/disable `RCTDevLoadingView` Changelog: [iOS][Added] - Make RCTDevLoadingView TurboModule-compatible Reviewed By: PeteTheHeat Differential Revision: D18642554 fbshipit-source-id: 6b62e27e128d98254b7a6d018399ec1c06e274fc
2020-02-28 04:01:18 +03:00
React-jsinspector: 7fbf9b42b58b02943a0d89b0ba9fff0070f2de98
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-16 01:21:25 +03:00
React-perflogger: 1f668f3e4d1adef1fafb3b95e7d6cf922113fe31
Make RCTDevLoadingView TurboModule-compatible Summary: This is a redo of D16969764, with a few extensions. ## Changes 1. Move `RCTDevLoadingView.{h,m}` to `CoreModuels/RCTDevLoadingView.{h,mm}` 2. Extract ObjC API of `RCTDevLodingView` into `RCTDevLoadingViewProtocol` in `ReactInternal`. 3. Create API `RCTDevLoadingViewSetEnabled.h` in `ReactInternal` to enable/disable `RCTDevLoadingView` Changelog: [iOS][Added] - Make RCTDevLoadingView TurboModule-compatible Reviewed By: PeteTheHeat Differential Revision: D18642554 fbshipit-source-id: 6b62e27e128d98254b7a6d018399ec1c06e274fc
2020-02-28 04:01:18 +03:00
React-RCTActionSheet: 51c43beeb74ef41189e87fe9823e53ebf6210359
Fix Cocoapods builds Summary: ## Problem For some reason, D20831545 broke the `use_frameworks!` build of RNTester. ## Building RNTester ``` pushd ~/fbsource/xplat/js/react-native-github/RNTester && USE_FRAMEWORKS=1 pod install && open RNTesterPods.xcworkspace && popd; ``` ## Error I built RNTester locally, and the error was this: ``` Undefined symbols for architecture x86_64: "facebook::jsi::HostObject::set(facebook::jsi::Runtime&, facebook::jsi::PropNameID const&, facebook::jsi::Value const&)", referenced from: vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o "facebook::jsi::HostObject::getPropertyNames(facebook::jsi::Runtime&)", referenced from: vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o ld: symbol(s) not found for architecture x86_64 ``` ## Fix It looked like libraries that depend on "ReactCommon/turbomodule/core" weren't linking to JSI correctly. So, I modified all such Podspecs to also depend on "React-jsi": ``` arc rfr ' s.dependency "ReactCommon/turbomodule/core", version' ' s.dependency "ReactCommon/turbomodule/core", version\n s.dependency "React-jsi", version' ``` This seemed to do the trick. In buck, we'd fix this problem using exported_dependencies. I skimmed through cocoapods, and couldn't find such a configuration option there. So, I guess this will have to do? Changelog: [iOS][Fixed] - Fix Cocoapods builds of RNTester Reviewed By: fkgozali, hramos Differential Revision: D20905465 fbshipit-source-id: 60218c8274ec165752a428f2a7a9a546607c8fec
2020-04-08 05:04:25 +03:00
React-RCTAnimation: 9d09196c641c1ebfef3a4e9ae670bcda5fadb420
React-RCTBlob: 715489626cf44d28ee51e5277a4d559167351696
React-RCTImage: 19151d2d071b05c3832a0b212473cafa4ea8948f
React-RCTLinking: 7c94c0f2fcc658cb4043dacb4f6621dca2f8f8b5
React-RCTNetwork: 7596e84acacd5d0674e9743b55c5bf61a626af69
React-RCTPushNotification: 88c9f47ff0d4391d5136d70745f15713cdc5f6bb
React-RCTSettings: a29c61f85f535ba2eff54d80bef2ea3cdb6e5fba
Make RCTDevLoadingView TurboModule-compatible Summary: This is a redo of D16969764, with a few extensions. ## Changes 1. Move `RCTDevLoadingView.{h,m}` to `CoreModuels/RCTDevLoadingView.{h,mm}` 2. Extract ObjC API of `RCTDevLodingView` into `RCTDevLoadingViewProtocol` in `ReactInternal`. 3. Create API `RCTDevLoadingViewSetEnabled.h` in `ReactInternal` to enable/disable `RCTDevLoadingView` Changelog: [iOS][Added] - Make RCTDevLoadingView TurboModule-compatible Reviewed By: PeteTheHeat Differential Revision: D18642554 fbshipit-source-id: 6b62e27e128d98254b7a6d018399ec1c06e274fc
2020-02-28 04:01:18 +03:00
React-RCTTest: cfe25fcf70b04a747dba4326105db398250caa9a
React-RCTText: 6c01963d3e562109f5548262b09b1b2bc260dd60
Fix Cocoapods builds Summary: ## Problem For some reason, D20831545 broke the `use_frameworks!` build of RNTester. ## Building RNTester ``` pushd ~/fbsource/xplat/js/react-native-github/RNTester && USE_FRAMEWORKS=1 pod install && open RNTesterPods.xcworkspace && popd; ``` ## Error I built RNTester locally, and the error was this: ``` Undefined symbols for architecture x86_64: "facebook::jsi::HostObject::set(facebook::jsi::Runtime&, facebook::jsi::PropNameID const&, facebook::jsi::Value const&)", referenced from: vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o "facebook::jsi::HostObject::getPropertyNames(facebook::jsi::Runtime&)", referenced from: vtable for facebook::react::ObjCTurboModule in RCTImageEditingManager.o vtable for facebook::react::ObjCTurboModule in RCTImageLoader.o vtable for facebook::react::ObjCTurboModule in RCTImageStoreManager.o ld: symbol(s) not found for architecture x86_64 ``` ## Fix It looked like libraries that depend on "ReactCommon/turbomodule/core" weren't linking to JSI correctly. So, I modified all such Podspecs to also depend on "React-jsi": ``` arc rfr ' s.dependency "ReactCommon/turbomodule/core", version' ' s.dependency "ReactCommon/turbomodule/core", version\n s.dependency "React-jsi", version' ``` This seemed to do the trick. In buck, we'd fix this problem using exported_dependencies. I skimmed through cocoapods, and couldn't find such a configuration option there. So, I guess this will have to do? Changelog: [iOS][Fixed] - Fix Cocoapods builds of RNTester Reviewed By: fkgozali, hramos Differential Revision: D20905465 fbshipit-source-id: 60218c8274ec165752a428f2a7a9a546607c8fec
2020-04-08 05:04:25 +03:00
React-RCTVibration: d42d73dafd9f63cf758656ee743aa80c566798ff
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-09 02:10:38 +03:00
React-runtimeexecutor: 60dd6204a13f68a1aa1118870edcc604a791df2b
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-14 06:24:37 +03:00
ReactCommon: 511b4a9ea129c129c6dbc982942007d195903a9a
iOS: Deprecate iOS 9 / tvOS 9 SDK support Summary: It is time to target SDK version 10.0+. Changelog: [iOS] [Deprecated] - Deprecating support for iOS/tvOS SDK 9.x, 10.0+ is now required Reviewed By: mdvacca Differential Revision: D19265731 fbshipit-source-id: 93b6f9e8f61c5b36ff69e80d3f18256aa96cc2c0
2020-01-02 23:49:45 +03:00
Yoga: f7fa200d8c49f97b54c9421079e781fb900b5cae
@allow-large-files [Flipper][RN] Integrated Flipper in RNTester application Summary: Changelog: [iOS] [Fixed] Integrated Flipper in RNTester application and made sure that flipper connects with RNTester application allow-large-files Reviewed By: rickhanlonii Differential Revision: D19813213 fbshipit-source-id: f0c7a5a42ffaccd488582b0f42ce37aea946c636
2020-02-12 15:46:58 +03:00
YogaKit: f782866e155069a2cca2517aafea43200b01fd5a
iOS OSS: check in the Podfile.lock Summary: Should have been checked in previously. No setup change here. Reviewed By: shergin Differential Revision: D7626040 fbshipit-source-id: e7a1a9de70a40a22e39eb3777d1b62c8d7b66381
2018-04-14 03:19:01 +03:00
Revert D21336180: Update cocoapods, fix RNTester Differential Revision: D21336180 Original commit changeset: 4d51f53466ec fbshipit-source-id: 5519bc0457f14060e793d2da454489b77fce923f
2020-05-02 01:09:09 +03:00
PODFILE CHECKSUM: 5f0be4be03d6934478b9dd621bfbab4383b8c85d
iOS OSS: check in the Podfile.lock Summary: Should have been checked in previously. No setup change here. Reviewed By: shergin Differential Revision: D7626040 fbshipit-source-id: e7a1a9de70a40a22e39eb3777d1b62c8d7b66381
2018-04-14 03:19:01 +03:00
Update cocoapods (#28833) Summary: Pull Request resolved: https://github.com/facebook/react-native/pull/28833 The checked-in RNTester podfile was generated using Cocoapods version 1.9.1. This doesn't match the version currently used in CircleCI, which is 1.8.4. In order to update the offline mirrors and land them without breaking CircleCI, it seems we need to switch back to 1.8.4. This diff updates the podfile back to 1.8.4 and updates the offline mirrors. Reviewed By: fkgozali Differential Revision: D21392989 fbshipit-source-id: b14aa6e2798175534e9416410ba9d6877fb718c0
2020-05-07 02:58:03 +03:00
COCOAPODS: 1.8.4