Summary:
While working updating the codeden Makefile template for Android, I've removed
the `libreact_debug` and `libreact_render_debug` dependencies as they were unused in a
simple turbomodule. Turns out that `:ReactAndroid` is depending on having those dependencies.
Moving the build file to use AGP APIs, triggers this scenario and is making `ReactAndroid`
failing to build (see the build status for https://github.com/facebook/react-native/pull/32443).
I'm updating the codegen Makefile template to reintrodce the two libraries + I've update the prebuilt
makefile (used in the playbook) to include `react_debug` prebuilts as they were missing.
Changelog:
[Internal] [Changed] - Re-add libreact_debug to codegen makefile and add prebuilts for them
Reviewed By: ShikaSD
Differential Revision: D31900675
fbshipit-source-id: ff188c0498a0dca4a951a548a580ca8dd0674782
Summary:
Adds the `glob` type definition via `flow-typed` so that the `combine-js-to-schema-cli.js` script does not need a Flow suppression.
Changelog:
[Internal]
Reviewed By: kacieb
Differential Revision: D31800809
fbshipit-source-id: 3e01a096d2153639a619a7152bd06332df57f06b
Summary:
This diff updates the Makefile generated by `react-native-codegen`
to include the correct list of modules. Specifically I've removed some modules that are unused
like `libreact_debug` and added others that are necessary for the build to compile correctly
such as `libfbjni`.
Plus I've bumped the C++ version to 17 as we had a mixture of 14 and 17 across the codebase.
Changelog:
[Internal] [Changed] - Update codegen template to include correct native modules and C++17
Reviewed By: mdvacca
Differential Revision: D31754427
fbshipit-source-id: 8490fa5c5ad298689b564f760c3fc65550c94547
Summary:
I had to make this change when enabling Fabric in OSS. Without the full path, it can't find the modules like processColor within node_modules.
Changelog: Internal
Reviewed By: motiz88
Differential Revision: D31300424
fbshipit-source-id: 59b82470ec1ce63b63704931786e22b98f4bf046
Summary:
Changelog: [Internal]
Some environments that use codegen don't have Haste enabled, breaking the `require('NativeComponentRegistry')` call in generated view configs. Here we change it to reference an explicit path relative to `react-native`.
Reviewed By: JoshuaGross
Differential Revision: D31166063
fbshipit-source-id: cebc23d0d95b5cde76d0f8473eabc03ca82a862e
Summary:
If I understand the code correctly, component.extendsProps is expected to have more than 1 entry. I encounter a bug where it was an empty and produced an broken Props.h file while testing out in OSS.
```
// Example of the broken file.
class RNTMyNativeViewProps final : {
public:
```
In this diff, it makes it clear that the function has failed so that the codegen fails when the input is wrong.
There is probably an upstream problem that we should warn about, but this diff is just to make sure this method fails loudly.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D30847173
fbshipit-source-id: 34c894f0a7bb81e132b6ed44f51d0f92ed9a5a20
Summary:
Adding an error message when codegen doesn't recognize any modules to help users understand what's going on.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D30624535
fbshipit-source-id: 781f1f874a5b0c16a05191186b81c2d3892da95b
Summary:
Ship libjsi as a standalone dynamic library. This prevents problems
with exception handling caused by duplicate typeinfo across multiple
shared libs, and reduces bundle size by removing duplicate copies of
JSI.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D30599215
fbshipit-source-id: abad1398342a5328daa825f3f684e0067cad7a96
Summary:
See previous diffs for context. This updates all of the relevant props structs.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D29855426
fbshipit-source-id: 30177c3380ef82ecf8f2a4321f128cfbe8a576e0
Summary:
String type seems to be already supported by codegen, but it was not included in the list for command methods.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29306740
fbshipit-source-id: 44b267c09f471dc601759ed2f7211a9e0fc1bb90
Summary:
This pre-suppresses the 154 error diff ahead of its release, since it is large.
Changelog: [Internal]
Reviewed By: samwgoldman
Differential Revision: D29065246
fbshipit-source-id: f418041305a46df410dcbe3d9a4db81a61ac7014
Summary:
This pre-suppresses the 153 error diff ahead of its release, since it is large.
Changelog: [Internal]
Reviewed By: mroch
Differential Revision: D28754374
fbshipit-source-id: 1806f53bc7d804644d434583a2dcd6da63d00328
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/31543
Changelog:
[iOS][Added] - Description
When compiling iOS apps with flag `-Wnullability-completeness` (like Lightspeed app and soon Instagram), Objective-C headers are required to either have full *explicit* nullability annotations on all members of its public API, or none at all; partially annotated headers will fail to build that module.
RN native modules are currently generated with *partial* annotations. This works today because most apps are not compiled with `-Wnullability-completeness` turned on. But when we flip the switch for Instagram, the app doesn't build due to importing these RN partially annotated modules.
JavsScript Flow types are implied nonnull, and the current RN codegen translates Flow's [maybe/optional](https://flow.org/en/docs/types/maybe/) type to Obj-C `_Nullable` annotation, and everything else without an explicit Obj-C annotation. However this creates a mismatch with the Obj-C type system, where the implied default is *unannotated*, which is handled differently from nonnull when built with the nullability compiler flags.
There is a simple Obj-C macro that automatically adds *explicit nonnull* annotations to all members in a header: `NS_ASSUME_NONNULL_BEGIN` / `NS_ASSUME_NONNULL_END`. If we add this to *all* RN-generated headers, however, we run into issues:
1) We may erroneously assume any previously-unannotated header was meant to be nonnull and cause future bugs
2) Another compiler flag (`-Wnullable-to-nonnull-conversion`) statically analyzes Obj-C implementation code to prevent us from ever passing null to one of these headers. Much existing Obj-C code will break here, and it's ambiguous if these are true or false positives because of the first point.
Instead, in this diff we add a new BUCK flag `ios_assume_nonnull` to let module authors opt into automatic nonnull for unannotated members so that Obj-C headers are generated correctly in alignment with Flow's type system. We can migrate all libraries individually as needed and eventually make this the RN native codegen default.
Reviewed By: RSNara
Differential Revision: D28396446
fbshipit-source-id: ad3a3a97ab19183df4ef504b1c3140596c8f69ca
Summary:
This should ensure that nothing is stripped at compile-time.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26094738
fbshipit-source-id: 8dd62c289deafdcceb3de4b09c12132aaceafa94
Summary:
Changelog: [Internal]
Adds react_debug dependency in Android.mk where it was missing
Reviewed By: mdvacca
Differential Revision: D26617400
fbshipit-source-id: 5ac799269b106eadd881d30490ac34bd2134a9b7
Summary:
Building ReactAndroid from source on Windows has recently hit the limitation of maximum path lengths.
At build time, during the `:ReactAndroid:buildReactNdkLib` task, the linker tries to access several of the intermediate binaries located deep in the tmp folder hierarchy, eg.
```
D:\r\ReactAndroid\build\tmp\buildReactNdkLib/local/armeabi-v7a/objs/react_render_components_progressbar/D_/r/ReactAndroid/__/ReactCommon/react/renderer/components/progressbar/android/react/renderer/components/progressbar/AndroidProgressBarMeasurementsManager.o
```
**Suggested fix:** for modules such as `react_render_components_progressbar` and `react_render_components_picker`, rename them to `rrc_progressbar` etc.
**NOTE**: this assumes that the fix from https://github.com/facebook/react-native/issues/30535 is in place. This regression happened while https://github.com/facebook/react-native/issues/30535 has been pending checkin.
**Other mitigations I've tried:**
- setting [`LOCAL_SHORT_COMMANDS`](https://developer.android.com/ndk/guides/android_mk#local_short_commands) for the problematic modules or `APP_SHORT_COMMANDS` for the root project. Turns out those commands don't work on the NDK version RN requires, but even after manually applying a [patch ](https://android-review.googlesource.com/c/platform/ndk/+/1126440) to my local copy of the NDK, these flags had no effect.
- moving the repo directory higher in the file system tree, and using short directory names `D:\r\...` was not enough
- creating virtual drive letters for specific long paths with the [`sust`](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/subst#examples) command is not workable, since they depend on the source folder structure, and get partly generated by the build system, which I can't plug into
- just enabling long path support on Windows is not enough, since the compiler toolchain doesn't support them.
## 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] [Fixed] - Fix source build on Windows machines vol. 2
Pull Request resolved: https://github.com/facebook/react-native/pull/30776
Test Plan:
Run `.\gradlew installArchives`
Before:
Now:
Differential Revision: D26194286
Pulled By: mdvacca
fbshipit-source-id: 778b5a0515148e2ace19e7902f74301831ebed94
Summary:
NativeModule getConstants() methods on Java might not be used within Java. So, they can be stripped by proguard. This diff adds the DoNotStrip annotation to the getConstants() method.
Changelog: [Internal]
Reviewed By: keoskate
Differential Revision: D26265874
fbshipit-source-id: b405ee32406e829212e5c9641750a6b5795899c3
Summary:
To ensure these Pojos don't get dead code eliminated, this diff adds a DoNotStrip annotation to each Props pojo object.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26041103
fbshipit-source-id: 02031f39f5fc5ef1bb9f11b729e68437bfe95452
Summary:
The Pojo data structure now keeps a flag `isRoot`, so that we can customize code-generation for the Props pojo vs its helper pojos.
In the following diff (i.e: D26041103), we'll add a DoNotStrip annotation to the props pojo. That doesn't need to exist on the helper pojos, because they'll all be referenced in the root props pojo.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26041102
fbshipit-source-id: ae2e1ba346d038853b5ff30cd5524a809ef97053
Summary:
## What This Does
- **Phase 1:** Given a component, convert its props (and all its ObjectTypeAnnotations) into this Pojo data structure under some namespace. This is a recursive operation.
- **Phase 2:** Loop over each Pojo data structure, and serialize it to Java class.
So...
- Each Component has its own namespace (i.e: its hasteModuleName) for Java Pojo objects.
- Each Component generates 1 Pojo object, for its props.
- Each Component generates 1 Pojo object for every ObjectTypeAnnotation in its props.
## Decisions
By design, [JNI can read/write to private properties on Java objects](https://stackoverflow.com/a/12208643). So, each Pojo, which represents an ObjectTypeAnnotation, contains only a private member variable for each of its properties, and a getter to retrieve the data from each of its private members.
## Todos
- Improved type-safety:
- ReservedTypeAnnotation (e.g: PointPrimitive). These currently map to ReadableMap.
- String enums, and Int enums don't actually generate Java enums.
- Verify if there are any compilation issues by wiring this up to the Codegen buck infra.
- To actually use the Pojos, we'll need C++/Jni codegen to transform C++ props into these Pojos. Building this out will give a more accurate assessment of the app-size cost of Pojos. However, we can do that if we deem that the app-size increase from adding just the Pojo classes is negligible enough to **not** rule out this entire approach.
- ~~Add some annotations to prevent these Pojo classes from being stripped at compile-time.~~ D26041103
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26038189
fbshipit-source-id: c137c4ca6b043ee76adb354105aff6e0f270df86
Summary:
Right now, running the codegen parser on regular JavaScript files causes it to throw an error:
https://www.internalfb.com/intern/diffusion/FBS/browsefile/master/xplat/js/react-native-github/packages/react-native-codegen/src/parsers/flow/index.js?commit=1e93f27aac8890f1731650fdcc38b702ae8874e2&lines=59-63%2C106-107
This makes the parser less usable, because you can't simply loop over a list of JavaScript files, and run codegen on them. You need to do some filtering beforehand, or surround each invocation of the parser with a try/catch.
Our codegen schema supports the idea of an empty schema:
```
{
modules: {}
}
```
To improve the parser's ergonomics, this diff migrates the codegen parser over to returning the empty schema when it cannot detect a Component or NativeModule spec inside a JavaScript file.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D26034052
fbshipit-source-id: c2f15aba9c0e052012396eaed2034537f5918e33
Summary:
## Problem
Suppose we have this NativeModule spec, that uses Object literals that contain a property called "id":
```
export interface Spec extends TurboModule {
// Exported methods.
+getConstants: () => {|
id: string,
|};
+getObject: (arg: {id: Object}) => Object;
}
```
For both object literals, we'll generate C++ structs, backed by NSDictionaries. The method in each struct will be named "id_" to avoid a name clash with ObjC's `id` identifier. However, calling that id_ method should still access the "id" property in the corresponding NSDictionary.
## Expected Output
```
inline id<NSObject> JS::NativeSampleTurboModule::SpecGetObjectArg::id_() const
{
id const p = _v[@"id"];
return p;
}
inline JS::NativeSampleTurboModule::Constants::Builder::Builder(const Input i) : _factory(^{
NSMutableDictionary *d = [NSMutableDictionary new];
auto id_ = i.id_.get();
d[@"id"] = id_;
return d;
}) {}
```
## Actual Output
```
inline id<NSObject> JS::NativeSampleTurboModule::SpecGetObjectArg::id_() const
{
id const p = _v[@"id_"]; // <-- HERE!
return p;
}
inline JS::NativeSampleTurboModule::Constants::Builder::Builder(const Input i) : _factory(^{
NSMutableDictionary *d = [NSMutableDictionary new];
auto id_ = i.id_.get();
d[@"id_"] = id_; // <-- HERE!
return d;
}) {}
```
NOTE: This code was generated by running `jf get --version 119805822 && buck build //xplat/js:FBReactNativeSpec_Sample-flow-types-ios --show-output`
This diff fixes this mistake.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D25907493
fbshipit-source-id: cb37cbf49db4f871b3f4046f7397a7b1b7df0357
Summary:
Changelog: [internal]
Codegen was generating code with return value number instead of boolean.
Reviewed By: RSNara
Differential Revision: D25863062
fbshipit-source-id: 780f88dd2d83e303b03d1ed9cc837ac6733f1702
Summary:
This new type will be valid in Flow strict mode and can be used by native modules and components to replace `Object`, with the same semantics.
This unblocks the migration of the most modules in the React Native package to Flow strict.
Changelog: [Internal] Add UnsafeObject type compatible with Flow strict mode to use in native modules and components
Reviewed By: RSNara
Differential Revision: D25540631
fbshipit-source-id: 60b80bbc84a53aecc747e3a1799cdf551e1859cd
Summary:
## Changes
All `rn_library(codegen_modules = True)` must now also specify native_module_android_package_name, like so:
```
rn_library(
name = "FBAuth"
codegen_modules = True,
native_module_spec_name = "Foo",
native_module_android_package_name = "com.facebook.fbreact.specs",
)
```
This will generate the FBAuth Java spec files under the appropriate directory: "com/facebook/fbreact/specs". It will also make the code-generated specs have the appropriate package name: "com.facebook.fbreact.specs".
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D25723176
fbshipit-source-id: 6efec1cbee43d70110c0ef23e2422e08609b61d4
Summary:
NativeModule methods are meant to be called from JavaScript. As such, they may not necessarily have call-sites in Java. This means that they're succeptible to being stripped by proguard.
This diff annotates all exported NativeModule methods with DoNotStrip, so that proguard doesn't strip them. We already do this in the legacy codegen.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25723801
fbshipit-source-id: a7c8701e0a5d03a970f5f19cc6ae6b320a2e99a1
Summary:
This test was used to compare the old codegen output with the new codegen output. It was written predominately to test the ObjC++ generator. A few reasons why we should delete this:
1. We do not want the old and the new codegen targets co-existing because it will slow down buck query.
2. The new ObjC++ codegen output is different from the old. In the new ObjC++ generator, we aren't generating dead structs. Therefore, this test simply won't work on the most sophisticated generator (i.e: the generator it was designed to run on). The other generators are really simple. We've also been running the ObjC++ and the Java generators in production for over a month for react-native-github specs. These are arguably the most complicated specs we maintain, so generator correctness isn't too much of a concern.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D25683069
fbshipit-source-id: b2175f34f50a078d80ef738e59024f546628219a
Summary:
Generate Fabric C++ files along side TM spec files for RNTester. The combined .so then has both TM and Fabric files.
This commit also removed the checked-in JNI files.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25674313
fbshipit-source-id: 8091d5a00f42849a74cab50e8d24f4010d500e5b
Summary:
For core components, we can start using the codegen output during build time instead of the checked in files in: https://github.com/facebook/react-native/tree/master/ReactAndroid/src/main/java/com/facebook/react/viewmanagers
Note: Some files seemed to be handwritten, so this only removed those that use codegen.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D25453157
fbshipit-source-id: f7eabddfd3fd668bef0c4aef3fddcb38c8b046a0
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:
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:
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:
## 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
Ramanpreet Nara
Nicola Corti
Tim Yung
Sota Ogo
Moti Zilberman
Neil Dhar
Joshua Gross
Andrei Shikov
Daniel Sainati
Erich Graham
Luna Wei
Igor Klemenski
Samuel Susla
Rubén Norte
Kevin Gozali
