Summary:
A very common pattern I've seen in RN codebase:
- (instancetype) init {
[[NSNotificationCenter defaultCenter] addObserver:self ...]
}
- (void) dealloc {
[[NSNotificationCenter defaultCenter] removeObserver:self ...]
}
From Apple:
https://developer.apple.com/documentation/foundation/nsnotificationcenter/1413994-removeobserver?language=objc
> If your app targets iOS 9.0 and later or macOS 10.11 and later, you don't need to unregister an observer in its dealloc method.
RN targets iOS9+
Changelog: [Internal][Cleanup] Remove unneeded NSNotification center removeObserver
Reviewed By: shergin
Differential Revision: D18264235
fbshipit-source-id: 684e5f5555cec96b055b13cd83daaeb393f4fac9
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
Summary:
This diff switches the exception manager over to the reportException native module function on iOS and adds a new field `extraData.showRedbox` as a temporary hack to control hiding/showing native redboxes for LogBox.
Once LogBox is rolled out we'll remove this field, so we're hacking it into the available unused and untyped extraData bag, which will simplify gutting it in the future.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D18212047
fbshipit-source-id: f14e31d90359b7d455a73c2368ce010c28364a5c
Summary:
This diff adds back RN reload reason, which was removed earlier in the stack. cc/Rick
For callsites which already had a reason, I kept the string exactly the same. For callsites which didn't have a reason, I made up something reasonable.
Changelog: [Internal][Fixed] Re-implemented bridge reload reason text.
Reviewed By: RSNara
Differential Revision: D18074478
fbshipit-source-id: 64a3cd7718674a7ba7228a80e34791ce9f153f9f
Summary:
Motivation described in diff 1/N.
This diff replaces calls to `[bridge reload]` with calls to `RCTReloadCommand`. This shouldn't have any change in behaviour since RCTBridge listens to RCTReloadCommand and calls `[bridge reload]` [here](https://fburl.com/diffusion/kemzkrei).
It will allow us to customize who listens and reacts to RN lifecycle.
Changelog: [Internal][Changed] - Migrated [bridge reload] calls to RCTReloadCommand
Reviewed By: shergin
Differential Revision: D17880909
fbshipit-source-id: 80b26c6badd4b216656fed6dd04554e9877f4bb7
Summary:
On iOS the promised returned by `Share.share(content, options)` isn't resolved if the user dismisses the dialog by either pressing "Cancel" or pressing outside the shared dialog. This PR fixes this issue.
This fixes https://github.com/facebook/react-native/issues/26809.
## Changelog
[iOS] [Fixed] - Fix promised returned by `Share.share(content, options)` not resolving if share dialog dismissed
Pull Request resolved: https://github.com/facebook/react-native/pull/26842
Test Plan:
1. on iOS, open a share dialog with:
```typescript
const onShare = async () => {
const result = await Share.share({ message: 'example message' });
}
```
2. Dismiss the opened share dialog and the returned promised should resolve.
Differential Revision: D18189755
Pulled By: cpojer
fbshipit-source-id: 1269932e9549026afefdaa8478ff7d33bbaeb86f
Summary:
* Fabric surface hosting view should emit the same event as RCTRootView
* Before emitting to JS, make sure to check if the color scheme really changed to avoid unnecessary re-render in JS
Changelog: [Internal]
Reviewed By: mdvacca, mmmulani
Differential Revision: D18100700
fbshipit-source-id: 451199beac07cdfb3833131ee429cc151391d8dd
Summary:
Some apps may need to disable the automatic dark mode color scheme assignment. This provides such kill switch.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D18088313
fbshipit-source-id: 75abf34e92f8a4a637daa26135adf85965cb9df5
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
Summary:
Some of our NativeModule type specs aren't compatible with our Android codegen and type safety checks - specifically, we don't support `$ReadOnly` in our type checks, and we don't support map types in the codegen. Removing these from a couple of the OSS type specs so we can enable codegen for these modules (eventually).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D17882093
fbshipit-source-id: 6e8669e4be775347199b2b5346bd8d40d7620886
Summary:
`xplat` targets add different deps based on what platform the target is being built for.
for anything using `fb_xplat`, we can put all ios supermodules in `fbobjc_labels` and all android sms in `fbandroid_labels`
There's some weirdness with python targets like `thrift_gen` in `/xplat/mobileconfig/tools/generator/gen-py/BUCK` that don't have platform-specific labels because the except_for list for `fbandroid` doesn't need the `fbsource//` prefix (see changes in `/ios/isolation/infra.mobileconfig.sm`)
Changelog: [Internal]
Reviewed By: shergin, joshleibsly
Differential Revision: D17884952
fbshipit-source-id: e245364cf515b75682990094d24f789d53b1f3f5
Summary:
**Note:** This was landed in D17724498 but reverted in D17855088. The revert had nothing to do with this NativeModule.
Changelog: [iOS][Added] Make RCTAsyncLocalStorage TurboModule-compatible
Reviewed By: PeteTheHeat
Differential Revision: D17917841
fbshipit-source-id: 0f9dd5f592180d6512ca560007daa531a4da5b59
Summary:
**Note:** This was landed in D17722913, but reverted in D17855088. The revert had nothing to do with this NativeModule.
Changelog: [iOS][Added] Make RCTAlertManager TurboModule-compatible
Reviewed By: PeteTheHeat
Differential Revision: D17917827
fbshipit-source-id: d86ea2cddddd9535d656709296c74aebd6f45793
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`.
Reviewed By: PeteTheHeat
Differential Revision: D17720575
fbshipit-source-id: 44b07cfa07cbb2b87254132810f86974edc7edab
Summary: We generate a stub for plugin system, so that TurboModules can work in OSS. Unless the `RN_DISABLE_OSS_PLUGIN_HEADER` define is seet, TurboModules will use the plugin stub. Therefore, for internal builds, we should set this define.
Reviewed By: fkgozali, mdvacca
Differential Revision: D17789993
fbshipit-source-id: a93735738513457236adb3064b80601053c95dd3
Summary: We need to mark the OSS plugin functions with `__attribute__((used))`, so that the compiler doesn't strip them out.
Reviewed By: fkgozali
Differential Revision: D17742818
fbshipit-source-id: df8055286cace850cea21bb6f09eb5ee6b587c0e
Summary:
[iOS] [Added] - Add definition for `queryCache` in ImageLoader
This diff is related to moving RCTImageViewManager's commands to a native module, ImageLoader.
Reviewed By: zackargyle, TheSavior
Differential Revision: D17714521
fbshipit-source-id: 722cc17a2ebb03e72d7c080dfc4d0aa6d7440e85
Summary:
[iOS] [Added] - Add `prefetchImage` to ImageLoader native module.
This diff is related to moving RCTImageViewManager's commands to a native module, ImageLoader.
Reviewed By: zackargyle, TheSavior
Differential Revision: D17714519
fbshipit-source-id: 0a50f640cf0c5668a11dd5d40553c257ebbd9d2b
Summary:
Define getSizeWithHeaders in ImageLoader native module.
This diff is related to moving RCTImageViewManager's commands to a native module, ImageLoader.
See it's usage here: D17704091
Reviewed By: TheSavior
Differential Revision: D17693907
fbshipit-source-id: 3c2d7b19ac68ead831e780c4ee23e3ed0643be3a
Summary: Previously, I introduced methods to convert `facebook::react::LazyVector<T>` to `NSArray*`, but I realized that there are already methods available in `RCTConvertHelpers` that do this for us. So, I'm switching over to using those methods instead.
Reviewed By: fkgozali
Differential Revision: D17716914
fbshipit-source-id: e1ef7636e36b594bc558d7025573082bd2bccab9
Summary:
Some NativeModules belong to their own buck target (separate from `ReactInternal`). We shouldn't move those NativeModules to `CoreModuels`, because that would unnecessarily bloat `CoreModules`.
In this diff, I extended the `update-plugins.js` script to also generate plugin stubs for those additional targets. This way, we can convert those NativeModules to TurboModules without moving them to CoreModules.
Now, in `update-plugins.js`, we have this array:
```
const libraries = [
{
name: 'CoreModules',
outputFiles: {
ios: ['CoreModulesPlugins.h', 'CoreModulesPlugins.mm'],
android: [],
},
outputPath: {
ios: `${GITHUB_DIR}/React/CoreModules`,
android: '',
},
},
];
```
To codegen another pair of plugin files for another target, simply insert to this array.
**Note:** We'll have to modify RNTesterTurboModuleProvider, but I can take care of that when I setup RNTester for TurboModules.
Reviewed By: fkgozali
Differential Revision: D17671288
fbshipit-source-id: 412d2e730682f82740241506f241dcfb4d302e99
Summary: RCTActionSheetManager is now hooked up to the NativeModule codegen. It's also TurboModule-compatible.
Reviewed By: PeteTheHeat
Differential Revision: D16966007
fbshipit-source-id: 8fdd32cf9fa09ccda9f38513bb0ac9896f8af1b0
Summary: These NativeModules were easy to convert, since no other NativeModules in `React/Modules` depend on them.
Reviewed By: PeteTheHeat
Differential Revision: D16817959
fbshipit-source-id: 1036c2d437e1275776a185bf68c450c6454985df
Summary:
## Motivation
The concept behind JSCallInvoker doesn't necessarily have to apply only to the JS thread. On Android, we need to re-use this abstraction to allow execution of async method calls on the NativeModules thread.
Reviewed By: PeteTheHeat
Differential Revision: D17377313
fbshipit-source-id: 3d9075cbfce0b908d800a366947cfd16a3013d1c
Summary:
@public
Both of these are used for turning BUCK configs and build mode into compiler flags, so we should combine them to avoid confusion on where they are to be used.
Reviewed By: fkgozali
Differential Revision: D17262579
fbshipit-source-id: d145374fd619068f794018d79111720d30f6269c
Summary: Implements the new `reportException` method in the iOS version of `ExceptionsManager`.
Reviewed By: sammy-SC
Differential Revision: D17226365
fbshipit-source-id: baa81424399175eaf8fc0835d4df01897e7fa468
Summary:
Refines the condition for ignoring updates to an already-open redbox on iOS.
Previously we would only update the stack trace if the message string in the update was exactly the same as in the initial redbox. With this diff we rely on the `exceptionId` parameter instead, and only fall back to string comparison if it's omitted (i.e. for non-JS uses of redbox on iOS).
NOTE: `exceptionId` is part of the existing ExceptionsManager API and is already supported on Android.
Reviewed By: sammy-SC
Differential Revision: D17226179
fbshipit-source-id: 5940110bf4e4358a8a1b3477e8d2cf8b224dd9f8
Summary:
For iOS < 13, default to "light" appearance, just like in Android (instead of `nil`).
This fixes the following redbox:
{F205818545}
Reviewed By: cpojer
Differential Revision: D17147970
fbshipit-source-id: b2adccd349a0a0ff7668c2f30e93164d23c3eea6
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
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
Summary:
Move RCTAccessibilityManager to CoreModules (since that's the only dir that supports TM).
Fixup some variable names to match spec.
Reviewed By: RSNara
Differential Revision: D16861739
fbshipit-source-id: a0a53b221dcc172979d1f2c83851ab92e23f2333
Summary: In D16805827, I moved ImageLoader to CoreModules. In the process, I migrated usages of `[_bridge moduleForClass:[RCTImageLoader class]]` to `[_bridge moduleForName:@"ImageLoader"]`. These two APIs aren't equivalent, however, since `[_bridge moduleForClass:[RCTImageLoader class]]` by default lazily loads the requested NativeModule, but `[_bridge moduleForName:@"ImageLoader"]` doesn't. So, I had to explicitly set `lazilyLoadIfNecessary` to `YES` in all the call-sites I migrated, to ensure that ImageLoader is correctly initialized when necessary.
Reviewed By: PeteTheHeat
Differential Revision: D16948165
fbshipit-source-id: 434697637dfa5e32de1c398744f9c28c19a6fd94
Summary: Follow pattern laid out by Kevin in D16001262 to convert a Core OSS native module to use TM generated spec.
Reviewed By: RSNara
Differential Revision: D16016391
fbshipit-source-id: f517777be44c68367d786f04c50cf12f240eed00
Summary: Missing space was causing this to show up as "themoduleForClass".
Reviewed By: shergin
Differential Revision: D16918867
fbshipit-source-id: c4bd19ca873d07e30e3fe8fc2c20277aab2d26d5
Summary:
`NativeExceptionsManager.js` contains the JS spec for this native module. This diff moves the objc code to CoreModules (since it's the only directory that supports TM at the moment) and makes it conform to the spec.
NOTE: I will update podfiles after this diff is reviewed, before I land. Adding those generated changes makes it really hard to review.
Reviewed By: RSNara
Differential Revision: D16812212
fbshipit-source-id: 38b6e9a20ce15e7e9995df34493b37ed7adb2911
Summary:
This diff adds a JS spec for RCTImageLoader, and conforms to it in ObjC++. Since RCTImageLoader isn't called from JS, the js spec is empty. Since `/CoreModules/` is the only dir in OSS which supports TM, move the ObjC++ impl there.
The change in `NativeExceptionsManager.js` fixes a weird bug I was hitting in codegen, where the codegen cpp file wouldn't compile due to unused variable.
Reviewed By: JoshuaGross
Differential Revision: D16495674
fbshipit-source-id: 191897b87730a6b0b96022eedc6412551fae04a6
Summary:
This diff moves RCTImageLoader, RCTImageEditingManager, and RCTImageStoreManager to CoreModules. This is necessary for us to convert all these NativeModules to TurboModules.
**Note:** As a part of this diff, I had to break apart `RCTImageLoader.h`. All the protocols that were in `RCTImageLoader` are now in their own headers. Furthermore, `RCTImageLoader`'s methods are defined in `RCTImageLoaderProtocol`, so that we can call them from classes like `RCTImageViewManager` in `RCTImage`.
Reviewed By: PeteTheHeat
Differential Revision: D16805827
fbshipit-source-id: 89f6728b0766c30b74e25f7af1be8e6b8a7e6397
Summary: Currently this is the default, but I plan to toggle the default to False shortly. False is better for build speed, as it forces you to separate deps and exported_deps.
Reviewed By: williamtwilson
Differential Revision: D16785991
fbshipit-source-id: 8cb73b87f1dfa50f21c0c12df1579054cdc99e6e
Summary: For some reason the conversion from a BOOL object to `bool` (C++ style) may lead to incorrect boolean value. This fixes the value provided to the builder to be of `bool` type instead.
Reviewed By: JoshuaGross
Differential Revision: D16657766
fbshipit-source-id: b66922aceadd20d16226a07f73b24ee0a3b825dc
Summary: It's actually the first module in OSS which is typed with taking advantages of codegen.
Reviewed By: RSNara
Differential Revision: D16620334
fbshipit-source-id: 65d6656506f2a4c68d493939ecfa65ba975abead
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
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 33573511f0.
- 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
Summary: For now, suppress this warning - they are harmless.
Reviewed By: mdvacca
Differential Revision: D16198994
fbshipit-source-id: b167d0e98bbc4abcd0461d50f01f364d8d560aec
Summary: This adds internal script to automatically sync the plugins definition. For github consumption, the CoreModulesPlugins.* will stay checked in, nothing change.
Reviewed By: RSNara
Differential Revision: D16102352
fbshipit-source-id: 8f74ea9dde046183ae620682fd7e181b4cc95a94
Summary: To look up TurboModule Class based on its name, this new function `RCTCoreModulesClassProvider()` can be used to find a TurboModule impl in the app. For now this is manually maintained and sync'ed with FB internal version. Only modules that live under React/CoreModules/ should be handled here.
Reviewed By: PeteTheHeat
Differential Revision: D16100291
fbshipit-source-id: 6b7556dec1fa83d1e081c7e8c0fe295187934274
Summary:
We should be able to just use `header_path_prefix` and normal `glob(["**/*.h"])` patterns, and that should be compatible with the build system.
This also allows `RCTPlatform.mm` to import `"RCTPlatform.h"` directly without any namespace.
Reviewed By: RSNara
Differential Revision: D16096779
fbshipit-source-id: b17b79baf958f1e9a63085a928b64663cb29bbbb
Summary: This is an attempt to use internal iOS plugin system for NativeModules in github.
Reviewed By: RSNara
Differential Revision: D16082484
fbshipit-source-id: 81d9f20b20419e9613a2babdd56d0e037705bf4e
Summary: First attempt to make RCTPlatform module implement the generated specs for TurboModule.
Reviewed By: PeteTheHeat
Differential Revision: D16001262
fbshipit-source-id: 24067c2840b9aa2be224c0c7c82fe7edc98d40d9
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
Summary: Right now the entire RN core code lives inside one giant internal Buck target. This makes it hard to refactor the infra and to roll out TurboModules. For now, create a baseline for how RN core dir can be structured.
Reviewed By: PeteTheHeat
Differential Revision: D16001260
fbshipit-source-id: bba947e2fb75576a2e1f3f4c816575f1157dcb03