Summary:
Currently, installing `react-native-community/eslint-config` with projects using eslint v7 causes the following warning
```
warning "react-native-community/eslint-config > eslint-plugin-react-native@3.8.1" has incorrect peer dependency "eslint@^3.17.0 || ^4 || ^5 || ^6".
```
This PR updates the eslint-plugin-react-native module to suppress the warning
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Internal] [Changed] - update eslint-plugin-react-native for community eslint-config
Pull Request resolved: https://github.com/facebook/react-native/pull/30350
Test Plan: eslint working without error with projects using eslint v7
Reviewed By: GijsWeterings
Differential Revision: D25480912
Pulled By: nadiia
fbshipit-source-id: 2a956070e5bb75168d68501f9ec9486a34011349
Summary:
In preparation for flipping the default, marking autoglob as False in places where it isn't explicitly specified.
Changelog: [Internal]
Reviewed By: strulovich
Differential Revision: D25497305
fbshipit-source-id: 142e5caca2d67efcb3c25067a36934f7f6dd4b21
Summary:
All NativeModules that use the bridge to require the eventDispatcher are now instead using the RCTModuleRegistry I introduced in D25412847 (0ed81b28d3).
## What does this codemod do?
For all ObjC files that contain `synthesize bridge = _bridge`, migrate calls that access the React Native bridge from `self`, and use it to load the event dispatcher.
**Thoughts on Codemod Safety:** If we can access the bridge from self, then that means that if we synthesize the module registry, we can access the module registry from self. Therefore, this codemod is safe.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25449795
fbshipit-source-id: 2f7235d14659e73d673ae08763dc2cccdde55a19
Summary:
## Problem
Many of our NativeModules are TurboModule-compatible. All our TurboModules currently use the bridge to require other NativeModules/TurboModules. As we migrate more surfaces to Venice, this lookup in many of these TurboModules will break, because the bridge will be nil.
## Initial Solution
We migrate all these TurboModules over to the turboModuleRegistry. In FBiOS, this will work because all NativeModules are TurboModule-compatible, and should [have the turboModuleRegistry attached to them by the TurboModuleManager](https://fburl.com/diffusion/d747fbc3). However, this solution has a few problems:
- If the TurboModule is used within a TurboModule-disabled app, it will break, because turboModuleRegistry will be nil on the module. Therefore, this solution isn't portable/flexible across apps.
- Longer term, we should deprecate synthesize bridge inside NativeModules. With this approach, we can't remove the synthesize bridge = bridge call from the NativeModule.
## Suggested Solution
Both NativeModules and TurboModules will be given access to an `RCTModuleRegistry` object. The RCTModuleRegistry object will use the TurboModuleManager when available and the Bridge when available to query for NativeModules and TurboModules. Otherwise, it'll just return nil.
When we do a lookup via this RCTModuleRegistry:
- In Venice, the bridge will be nil, so we won't search the bridge.
- In FBiOS, the bridge and the TurboModuleManager will be non-nil, so we'll first search the bridge, and then the TurboModuleManager.
- In standalone apps, the TurboModuleManager will be nil, so we'll only do a lookup on the bridge.
Long story short, RCTModuleRegistry will do the right thing in all scenarios.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D25412847
fbshipit-source-id: 13f41276158d90c68ab4925e518d71a2f369c210
Summary:
Some of the existing files under uimanager/ are self contained and used by the component codegen output. This commit split out those files into a dedicated uimanager/interfaces/ dir/target so that more targets can depend on it without causing dep cycle.
Also, the component codegen output doesn't need LayoutShadowNode at all, so this removed the import.
This will allow us to combine the Java codegen output for TM spec and Fabric components, simplifying build and dependency management (not in this commit yet).
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D25451409
fbshipit-source-id: 827545a3d78ebed1815cf9e52da2fa896b012aa1
Summary:
This commit:
* Generate Fabric component Java files along side Java NativeModule specs, when `USE_FABRIC=1` is set
* Adjust the component codegen to place output files in a subdir based on package name
* Adjust existing Buck targets to filter the right nativemodule vs component java files (this avoids duplicated symbols)
* Compiles the Java output during build time on RNTester/ReactAndroid (Gradle)
Not in this commit:
* Fabric C++ files
* Removing checked-in generated component files.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25416614
fbshipit-source-id: fd670ead2198c9b5a65812c692b7aed9f3d7cd58
Summary:
There is partially compiled TurboModule code in [NativeAnimatedModule](https://fburl.com/diffusion/g91a70ng) that fails to build with:
`"File neither contains a module declaration, nor a component declaration. For module declarations, please make sure your file has an InterfaceDeclaration extending TurboModule. For component declarations, please make sure your file has a default export calling the codegenNativeComponent<Props>(...) macro"`
This diff removes react-native-web from the TurboModules logic while we work on a cleaner solution, tracked in T80868008
msdkland[metro]
Changelog: [Internal]
Reviewed By: cpojer, RSNara
Differential Revision: D25325163
fbshipit-source-id: 346abf52660073f976b0f978cbfbfc8402f4b3ee
Summary:
Added examples to RNTester for the AccessibilityInfo API for:
1. SetAccessibilityFocus()
2. isReduceMotionEnabled()
3. iOS Only
a. isBoldTextEnabled()
b. isGrayScaleEnabled()
c. isInvertColorsEnabled()
d. isReduceTransparencyEnabled()
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[General] [Added] - Add new examples to the Accessibility API page
Pull Request resolved: https://github.com/facebook/react-native/pull/30379
Test Plan: 
Reviewed By: TheSavior
Differential Revision: D25245329
Pulled By: rickhanlonii
fbshipit-source-id: e9c11c775410075199b4e1011b3dac0acd972e89
Summary:
Add missing examples to ScrollView for RNTester.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[General] [Added] - Add missing examples to ScrollView for RNTester.
Pull Request resolved: https://github.com/facebook/react-native/pull/30454
Test Plan: There are a lot of examples that have been added that affects the UI (see RNCore Excel sheet for details).
Reviewed By: sammy-SC
Differential Revision: D25310613
Pulled By: rickhanlonii
fbshipit-source-id: 64a771aa8d3c3683eed983b0c36625078e5533fe
Summary:
In the Codegen, we need to answer the following questions:
*Question:* What are all the calls into TurboModuleRegistry?
*Answer:* Find all CallExpressions that represent TurboModuleRegistry.get<Spec>() or TurboModuleRegisty.getEnforcing<Spec>().
*Question:* Is this a component spec?
*Answer:* Does this spec have a CallExpression where the callee is 'codegenNativeComponent'?
*Question:* Is this a module spec?
*Answer:* Does this spec have an interface that extends TurboModule?
All these answers can be implemented using the visitor pattern. Hence, this diff introduces the `visit` utility, and uses it to answer these questions.
**Motivation:** Cleaner code.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D25162617
fbshipit-source-id: 66ec95fc07ecb29aa9bf9993cb826204af283d03
Summary:
**Motivation:** After this change, we can show this ParserError using the React Native Module ESLint rule. Previously when we declared more than one NativeModule spec in a file, we incorrectly reported that there were *no* NativeModule specs in the file.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D25163299
fbshipit-source-id: 92bc09d09cdbc323e0ac1f317c40a767880f5bc2
Summary:
## What is `guard`?
`guard` accepts some JavaScript function that can throw a ParserError. If a ParserError is thrown by that JavaScript function, it captures and pushes the error to some global array, and returns null. If no ParserError is thrown, it simply returns the return value of the JavaScript function. This utility is used in the NativeModule spec parser to help it continue parsing even after it detects errors. Why do we want to do this? In the NativeModule spec linter, we want to display all these ParserErrors via ESLint.
## Changes
This diff renames `guard` to `tryParse` because `tryParse` more appropriately captures the intent/function of this utility: the work passed to it "tries" to parse some Flow types. A name like "guard" is a bit more ambiguous: What is it guarding against? What is the work doing? ¯\_(ツ)_/¯
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D25156185
fbshipit-source-id: 516647770579daa8613dbd67535074823f1aa848
Summary:
## Changes
1. In the NativeModule spec parser, the moduleName is now being extracted from the TurboModuleRegistry.get<Spec>(...) call by examining the Flow ast node. Previously, we used regex parsing, which was unsafe because it could be fooled by TurboModuleRegistry.get<Spec>(...) calls in comments.
2. The logic to parse and validate the TurboModuleRegistry.get<Spec>(...) call is now centralized in the NativeModule Spec Parser (it was removed from the react-native-modules ESLint rule). The linter is now only responsible for three things:
1. Detecting if a JavaScript file contains a TurboModuleRegistry.get<Spec> call or a TurboModule interface, and if so
2. Running the NativeModule spec parser on it.
3. It also validates that the Module spec's filename starts with the prefix "Native".
The React Native Modules linter now completely delegates to the NativeModules Spec parser, without doing any error checking of its own. If an error is reported by the React Native Modules linter, and that error doesn't have anything to do with the "Native" prefix, then it *must* be addressed. Otherwise, it will cause the NativeModule Spec Parser to fail on that particular spec.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D25153243
fbshipit-source-id: da74dbb66b1d8dca3a2b1952402222c6696b73d6
Summary:
Hermes being a subspec of ReactCore causes some build issues when RN is included in 2 different targets. It also causes it to include a lot of additional dependencies that it doesn't need. This moves it to a separate podspec loosely based on other specs in ReactCommon.
## Changelog
[iOS] [Fixed] - Move hermes to a separate podspec
Pull Request resolved: https://github.com/facebook/react-native/pull/30478
Test Plan: Test that it builds and run properly in an app
Reviewed By: fkgozali
Differential Revision: D25308237
Pulled By: hramos
fbshipit-source-id: b4cc44ea2b1b854831e881dbbf9a2f30f6704001
Summary:
When building RN Tester with use_frameworks it crashes on launch because of duplicate folly singletons. Seems that it is included twice because of Flipper. From what I understand flipper is not really compatible with use_frameworks so this removes it from that build variant. We also remove hardcoded SONARKIT defines in the xcodeproject, those will be added by the Flipper podspec anyway so it is not needed.
This then exposed a missing double conversion header error in Folly so this fixes the DoubleConversion podspec to add its headers path to the user project.
## Changelog
[Internal] [Fixed] - Fix use_framework RNTester crash
Pull Request resolved: https://github.com/facebook/react-native/pull/30520
Test Plan: Tested RN tester with use frameworks on and off. Also made sure flipper works still when frameworks is false.
Reviewed By: fkgozali
Differential Revision: D25307973
Pulled By: hramos
fbshipit-source-id: 17b90e871734e32f5982c4fc9c07aeea232f868f
Summary:
Fixes https://github.com/facebook/react-native/issues/30325
After the RNTester redesign, a style started globally caching screen width. This isn't needed, but means that width is incorrect if the device is rotated, or a window is resized. Rely on default layout which will be 100% width instead.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Internal] [Fixed] - Fix RNTester Not Resizing Examples on Rotation/Resize
Pull Request resolved: https://github.com/facebook/react-native/pull/30376
Test Plan: Tested viewing an example and rotating the device in iOS simulator
Reviewed By: rickhanlonii
Differential Revision: D25098642
Pulled By: appden
fbshipit-source-id: 9acdb656da7de9fda05f6091b36f8d9aa2155524
Summary:
Move the codegen invocation out of Podfiles and into the FBReactNativeSpec Pod itself. With this change, developers do not need to modify their existing project's Podfiles, and yet the codegen will be integrated into their projects automatically by way of the FBReactNativeSpec Pod.
This is accomplished in part by injecting a script build phase into the Pods Xcode project that is generated by CocoaPods. The build phase will save the output of the codegen script to a log in the derived files directory. The codegen will be executed if the codegen log file is not present, or if the contents of the Libraries directory has changed.
The codegen will thus be invoked in these situations:
**RNTester:**
* When `packages/rn-tester/RNTesterPods.xcworkspace` is built, if the codegen output logfile is not present or if the input files have changed.
**OSS React Native apps:**
* When `ios/AwesomeProject.xcworkspace` is built, if the codegen output file is not present or if the input files have changed. Normally, this should not happen, as we do not expect folks to update the contents of `node_modules/react-native/Libraries`.
Pull Request resolved: https://github.com/facebook/react-native/pull/30449
Changelog: [Internal] - Moved codegen invocation out of Podfile and into FBReactNativeSpec Pod
Reviewed By: fkgozali
Differential Revision: D25138896
fbshipit-source-id: 4779f822459cea2c30fd544eee19a49e8d80153d
Summary:
Added an example to test focus and blur events in AppState (Android only)
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Android] [Added] - Add example for focus and blur events to AppStateExample
Pull Request resolved: https://github.com/facebook/react-native/pull/30381
Test Plan: 
Reviewed By: cpojer
Differential Revision: D25245334
Pulled By: rickhanlonii
fbshipit-source-id: 916f18a74140cc43e0d513eb4073cbcc44e41427
Summary:
Changes `react-native/babel-plugin-codegen` to generate calls to `NativeComponentRegistry` instead of `registerGeneratedViewConfig`.
The only notable changes in behavior from this will be:
1. In bridgeless mode, all components using `codegenNativeComponent` will no longer access `UIManager`.
2. In bridge mode, all components using `codegenNativeComponent` will no longer verify equivalence in production. Only in `__DEV__`. (This may improve performance slightly.)
This also changes the `ViewConfig` to be lazily allocated and drops support for `__INTERNAL_VIEW_CONFIG`, which we no longer need.
Changelog:
[Internal]
Reviewed By: JoshuaGross
Differential Revision: D25135881
fbshipit-source-id: ca2191872c02622ab2279b808102eeb1f664d207
Summary:
Use pre-built react-native-codegen library from npm in the iOS app template.
Built react-native-codegen from source when used with RNTester.
Published react-native-codegen@0.0.6.
Changelog:
[iOS][Added] - Use react-native-codegen in iOS app template
[Internal] - Bump react-native-codegen: 0.0.6
Reviewed By: fkgozali
Differential Revision: D25128036
fbshipit-source-id: f294c23b9b911aae6f404edc01b62426fb578477
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/30416
This diff changes the constructor param for TurboModuleManager from jsContext (a long representing the `jsi::Runtime` pointer) to a RuntimeExecutor. It also updates callsites to use the new RuntimeExecutor created by CatalystInstance. This is only used for installing the TurboModule JSI binding; it's not currently used for JS invocation in TurboModules, which is handled separately by JSCallInvoker. Ultimately we may be able to implement JSCallInvoker *with* the provided RuntimeExecutor, but there's some additional logic in JSCallInvoker that we don't have here yet.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D21338930
fbshipit-source-id: 1480c328f1a1776ddf22752510c0f3b35168a489
Summary:
Migrate over to [how we load so libraries in Fb4aTurboModuleManagerDelegate](https://fburl.com/diffusion/wu0mcr8o).
## Motivation
When we migrated Twilight over to TurboModules, we used the CatalystTurboModuleManager as a template. This led to a production crash (T70918829) because we weren't loading so's this way. The fix: D24894071.
I'm updating these two TMMDelegates so that people don't fall into the same trap when migrating other Standalone apps.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24992931
fbshipit-source-id: 3ac3b8c30a67e24f79021f915abf5ae980d5b5d3
Summary:
Add the `react-native-codegen` source to the `react-native` npm package.
Instead of using `react-native-codegen` from npm, the iOS app template will now build the package from source. Doing so removes the need to carefully time `react-native-codegen` npm releases to oss `react-native` releases, as the codegen and the oss release will be cut at the same time.
Changelog: [Internal] - Removed react-native-codegen dependency from iOS app template
Reviewed By: TheSavior
Differential Revision: D24904655
fbshipit-source-id: a07932bc748e2afb9359de584181bcb9dd0810ea
Summary:
This is the one usage of `flow weak` in Xplat - change it to normal `flow` and add a suppression where an error appears.
Changelog: [Internal]
Reviewed By: Hans-Halverson
Differential Revision: D24878970
fbshipit-source-id: 16e459c261b41e04de1555ed7ef4ecf2f5b3721e
Summary:
When running yarn install from the codegen directory it will reinstall all dependencies for the react-native workspace inside the react-native package. In my case this caused issues with metro because it would now have 2 copies of it (node_modules/metro and node_modules/react-native/node_modules/metro).
To avoid this copy the react-native-codegen source in a temporary directory and yarn install from there, then copy the built files back.
## Changelog
[Internal] - Build rn-codegen in a temporary directory
Pull Request resolved: https://github.com/facebook/react-native/pull/30292
Test Plan: Tested the script in an app with codegen enabled. Fresh install with rn-codegen not built, made sure no extra modules are installed under node_modules/react-native/node_modules.
Reviewed By: yungsters
Differential Revision: D24893216
Pulled By: fkgozali
fbshipit-source-id: 2c372b755632ea6f50ad5d4562248612b349a9a6
Summary:
There is a flow where TM registry is creating a module instance (as registered in the TurboReactPackage), only to discard it if it's not a TM enabled module. This may be fine for many modules, but for module like `UIManagerModule`, this may cause a race condition or other issues, including potential perf regression when accessing UIManager from JS (e.g. for getting native viewConfigs).
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24811838
fbshipit-source-id: 6e1cce6993a6e5c9763773f175083bf52925c910
Summary:
## New Functionality
- Detect if the JS file represents a NativeModule spec.
- **Note:** A JS file is a NativeModule spec if it contains a flow `interface` that extends `TurboModule`. This logic is copied over from the OSS Codegen, here: 7ccb67a49c/packages/react-native-codegen/src/parsers/flow/index.js (L60-L75)
- For all NativeModule specs, generate the spec's schema using the OSS Codegen for Modules, and conditionally inline it into every `TurboModuleRegistry.get(Enforcing)?` call in the spec, like so:
**Before:**
```
/**
* flow
*/
import type {TurboModule} from 'RCTExport';
export interface Spec extends TurboModule {
//...
}
export default TurboModuleRegistry.get<Spec>('FooModule');
```
**After:**
```
/**
* flow
*/
import type {TurboModule} from 'RCTExport';
export interface Spec extends TurboModule {
//...
}
export default TurboModuleRegistry.get<Spec>('FooModule', __getModuleShape());
function __getModuleShape() {
if (!(global.RN$EnableTurboModuleJSCodegen === true)) {
return undefined;
}
return {...};
}
```
Changelog: [General][Added] Extend react-native/babel-plugin-codegen to generate TurboModule JS codegen
Reviewed By: TheSavior
Differential Revision: D22803845
fbshipit-source-id: 18c157a1dbfcc575012184de31c38908acd53c36
Summary:
## Changes
{| ... |} -> { ... }
**Motivation:** In Flow, object literals are exact by default. So, there's no need for the pipes. Also: Now, the syntax for object literals is consistent across react-native-codegen.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24774771
fbshipit-source-id: 24ceb6f5876122aa8ad9e08c7e903215864ad6f5
Summary:
This type annotation was declared inline twice. Just pulling it out into a type alias in this diff.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24723191
fbshipit-source-id: 9f2061087172979ea838dfdf2533e17b9b559c71
Summary:
Int32EnumTypeAnnotation represents a union of numbers. In the corresponding type annotation, we represent options as `$ReadOnlyArray<{value: number}>`. Since each option is a number, we could instead represent options as `$ReadOnlyArray<number>` - there's no need to use an object with a singular property (i.e: 'value'). The same is could be said of StringEnumTypeAnnotation.
In this diff, we change `Int32EnumTypeAnnotation.options` to `$ReadOnlyArray<number>`, and `StringEnumTypeAnnotation.options` to `$ReadOnlyArray<string>`.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24723107
fbshipit-source-id: 4734cf72a4a29b6b321d8161bea70cf524ce0963
Summary:
Commands are `FunctionTypeAnnotation`, but they don't have a return type. I this diff, I introduced a `FunctionTypeAnnotation<+P, +R>` utility type, and made the `CommandTypeAnnotation` be an instantiation of it, with the return type fixed to `VoidTypeAnnotation`.
Now, the shape of a FunctionTypeAnnotation is unified across the NativeModule and Component schemas.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24719965
fbshipit-source-id: 0089c3b23f05b0c534ba28dbe336c7f2db5866b3
Summary:
Everywhere else in the CodegenSchema, type annotation partials are suffixed with "Shape". In the NativeModule schema, we were using the suffix "Schema". In this diff, we standardize on the "Shape" suffix.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24719395
fbshipit-source-id: 307935f5fe0681c31cd52e9cf4ae579f61c1ae68
Summary:
CodegenSchema exports `NativeModuleMethodParamSchema` and `NativeModuleObjectTypeAnnotationPropertySchema`, which are partials of NativeModule type annotations. This creates unnecessary coupling between the type annotations of CodegenSchema and the files that depend on it.
**Actual Problem:** Suppose that we want to rename one of these partials. Then, all imports in all files would have to be updated, even when the actual shape of the composed type annotation wasn't changed.
This diff removes these partials, which reduces the surface area of the exports of CodegenSchema.js
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24719396
fbshipit-source-id: c822aaa252f156c524f4ef4917ebb61b1a39ff9e
Summary:
The names of events and props flow type annotations are singular. The names of the commands flow types are however plural. This diff renames all "Commands*" flow types to be singular.
**Motivation:** Consistency
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24708276
fbshipit-source-id: 5d5d2123426ca1139953169d0ea764b82b2f3809
Summary:
All throughout the Codegen schema, we re-declare the following shape:
```
{
type: 'ObjectTypeAnnotation',
properties: $ReadOnlyArray<{
name: string,
optional: boolean,
typeAnnotation: ...
}>
}
```
This diff introduces an `ObjectTypeAnnotation<T>` utility type and replaces those re-declarations with instantiations of this type.
**Motivation:** To reduce noise in the CodegenSchema. This should be a pure refactor, and shouldn't actually change any behaviour.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24707963
fbshipit-source-id: 6b4eb711ddd041f3a041109ade5ad5644fb16924
Summary:
This diff re-organizes CodegenSchema to declare the larger types first, which use smaller undeclared types. The smaller types are declared further down the file, and they themselves use even smaller undeclared types.
**Motivation:** Increase the readability of CodegenSchema.js. Now, if people want to understand the shape of the Codegen Schema, they can just read the file from top to bottom.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24701424
fbshipit-source-id: 181e87bff5e32d998463221891f459b0df26ef52
Summary:
Reserved type annotations can appear in three different contexts: commands, props, and NativeModules. For now, commands and NativeModules share the same reserved type annotations. In the future, we may want to merge these reserved type annotations with the props reserved type annotations.
**Motivation:** The meaning of FunctionValue in FunctionValueTypeAnnotation isn't clear - in fact, it's downright confusing. Therefore, this diff renames this Flow type to ReservedTypeAnnotation, which I believe sufficiently captures the intent of the type annotation.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24701322
fbshipit-source-id: bde0273b4a89c9e7175c60ed3468ed870b320044
Summary:
Our CodegenSchema is littered with types that have the following shape
```
{
name: string,
optional: boolean,
typeAnnotation: ...
}
```
In all these types, the only difference is the typeAnnotation. This diff introduces a new utility type called `NamedShape`, that just creates this shape, given a type annotation. This should help reduce the amount of noise in the CodegenSchema, and make it a bit easier to read.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24701331
fbshipit-source-id: a30d3e22933116e3dabf7929615905febacecba3
Summary:
All ObjectTypeAnnotation *properties* in the codegen have the following shape:
```
{
name: string,
optional: boolean,
typeAnnotation: ...
}
```
EventObjectTypeProperty is a property of some ObjectTypeAnnotation, yet it doesn't follow this pattern. This diff cleans up EventObjectPropertyType. This is a part of a larger effort to clean up the Component Schema and unify the notion of a "type annotation" across the Component and Module schemas.
Reviewed By: yungsters
Differential Revision: D24701027
fbshipit-source-id: edc7dc632a217fb5a82ffd8a62aef990baf398c2
Jesse Katsumata
Ron Edelstein
Ramanpreet Nara
Kevin Gozali
Su Min Kim
Evan Gilbert
Janic Duplessis
Nick Gerleman
Héctor Ramos
Kshitij Kotasthane
Tim Yung
Emily Janzer
Luke Walczak
George Zahariev
Nadiia D
Christoph Nakazawa
Moti Zilberman
