Summary:
This makes the build configuration compatible with OSS Buck (but doesn't provide the complete capability).
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24414408
fbshipit-source-id: 4632933b8659389543ed72ae7c11c63d86bb3dce
Summary:
For now, separate the definition of `modules` generator per platform to avoid file output collision. Additionally:
* For Android, produce files under java/ (plus nested subdirs based on packageName) and jni/ (for C++ files) - JavaPoet version already does it
* Allow configuring packageName for Android - JavaPoet version has this
* Avoid tmp directory dance in the CLI script, given the proper modules separation
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24410864
fbshipit-source-id: 9bd6bc1d65bec037bfca32ec478f3af50d72e927
Summary:
## Rationale
Previously, the NativeModule spec parser would throw an error the first time it encountered an invalid Flow type. While this is ideal from a parsing standpoint, from a linting standpoint, however, we may want to display all errors that make the NativeModule spec invalid.
## Changes
This diff extends the NativeModule spec parser to collect all parsing errors in an array. In the codegen, if after building the schema, any parsing errors were detected, we throw the first one. In the ESLint rule, if after building the schema, any parsing errors were detected, the plan is to display them all.
## Notes
- All ParserErrors keep a track of the invalid AST Node
- When a Parsing error occurs, the Parser tries its best to continue parsing the rest of the source. For function parameters, it'll move on to the next param. For object proroperties, it'll move to the next property. It'll form a half-baked schema in the process, when a parsing error occurs. However, higher up in the stack, we have a check that discards the half-baked schema, if any ParsingErrors were collected.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24379511
fbshipit-source-id: 1989433da9b356b9ad5d9dcf901b429f585803c2
Summary:
## Why
We want to reuse these functions inside the ESLint rule. Therefore, it's better to make them accept the AST node object, as opposed to a custom type defined in codegen.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24379512
fbshipit-source-id: 9f7378fc6c5f48cce34da109f5a7c017332b302a
Summary:
In our Codegen generators, we were using `codegenModuleName` to refer to the name of the spec file. Calling this `hasteModuleName` makes it more clear what this name refers to (i.e: the name of the spec file). This diff performs that rename.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24386282
fbshipit-source-id: fe2beda9a0abf63a5cf88fa0664f83416c9f1aa2
Summary:
The specific file filtering in the CLI only covers the case where the input is a directory. We should filter when files are provided as well.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24399225
fbshipit-source-id: 186e39c157faf90bdd825ec5c5860017d49e9404
Summary:
The GenerateModuleJavaSpec.js mistakenly treated nullable getConstants() properties as required, such that the Java spec will throw an exception when the properties are missing. This fixed it.
Note that the JavaPoet-based generator got this correct already.
Changelog: [Internal]
Differential Revision: D24381941
fbshipit-source-id: c95d2181c66443e2191318f09b6454a5296009e4
Summary:
The NativeModules spec parser uses `moduleName` to refer to the name of the NativeModule spec. This is confusing, because the NativeModules spec also has a `moduleNames` array, which refers to names of the NativeModules that get required in the spec.
This diff renames `moduleName` to `hasteModuleName` within the NativeModule spec parser.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24386279
fbshipit-source-id: 8e4eb8dfc647241bf2bdae54dc8d9ab0122f49f9
Summary:
If a native module schema has `excludedPlatforms` defined, honor it and skip the module that doesn't belong to the platform.
E.g. NativeImagePickerIOS shouldn't generate anything for Android codegen output.
Similarly, IntentAndroid shouldn't generate anything for iOS codegen output.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24373092
fbshipit-source-id: cfeb455a18c92f60191d988af2e9ce7ea5021304
Summary:
Some existing NativeModules have either Android or IOS suffix to denote the exclusive intent for that platform. For now, note this in the codegen schema output, so that the generator can skip irrelevant modules. Long term, each Flow type for module Spec should denote the intended/excluded platforms directly.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24370568
fbshipit-source-id: 8f725bdb39107d73c1aba0689db7f47ed7c374b0
Summary:
NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack).
## Changes
1. NativeModule generators now use the new RN Codegen NativeModule schema.
2. Tangential: We're no longer removing the `Native` prefix from the NativeModule filename, assuming that that's the module name (problem: wrong), and prefixing again with Native (problem: redundant), when we're generating code. Instead, like the internal codegen, we simply pass the filename to the Codegen output. Our linters enforce that all NativeModule specs are contained with files that start off with `Native`.
3. `GenerateModuleCpp` was fixed to use the actual module name as opposed to the spec name. I added a comment inline.
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: PeteTheHeat
Differential Revision: D24236405
fbshipit-source-id: ccd6b5674d252c350be0ec8a86e7ca5f2f614778
Summary:
NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack).
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: PeteTheHeat
Differential Revision: D24236504
fbshipit-source-id: 0ca70101a855fb713fa15ed63849b138eb73dc6c
Summary:
NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack).
## Changes
Previously, the "Module" schema could either contain a `components` property, or a `nativeModules` property. The existence of the `components` property was used to determine (1) if the generators would run and (2) filter schemas on which the generators would run. Now, we simply check whether the type of the "Module" schema is `Component`.
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: PeteTheHeat
Differential Revision: D24236508
fbshipit-source-id: 68cb3f25178b6757c9a4aee767bb6173db4932a6
Summary:
NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack).
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: PeteTheHeat
Differential Revision: D24236507
fbshipit-source-id: 2ffa0414db731a6ee844a2d1a5b07dc32bc763cb
Summary:
NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack).
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: PeteTheHeat
Differential Revision: D24236502
fbshipit-source-id: 288c6d9588bde177732fe8165d3374eeacad999d
Summary:
NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack).
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: PeteTheHeat
Differential Revision: D24236509
fbshipit-source-id: 1b603e8728d7be1e8bdede5878f57d6556b5c52f
Summary:
NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack).
## Changes
1. Update the RN Codegen Module Parser
2. Update all RN Codegen Module Parser Jest tests & snapshots.
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: PeteTheHeat
Differential Revision: D24236505
fbshipit-source-id: e24a39b4837c75a90fb4c957c56dfcf789511cc9
Summary:
NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack).
## Changes
1. Update the RN Codegen Component Parser
2. Update all RN Codegen Component Parser snapshots.
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: PeteTheHeat
Differential Revision: D24236503
fbshipit-source-id: 975d97dd29bb5ca08e5de96e7814290c3dc4357b
Summary:
NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack).
## Description
The Codegen deals with "Modules". Hence:
```
type SchemaType = {
modules: {
[moduleName]: ...
}
};
```
Each "Module" has a name, and represents a file. The `moduleName` is the base name of the file. This file can contain a component specification or a NativeModule specification. Hence:
```
type SchemaType = {
modules: {
[moduleName]: ComponentSchema | NativeModuleSchema
}
};
```
The `ComponentSchema` can contain specifications for many different components. Hence:
```
type ComponentSchema = {
type: 'Component'
components: {
[componentName]: ComponentShape
}
}
```
The `NativeModuleSchema` contains
1. Type aliases (no surprises/nothing new).
2. One Flow interface that extends `TurboModule`.
3. Potentially many different NativeModule requires (for now) via `TurboModuleRegistry.get(Enforcing)?<specName>('moduleName')`.
Hence, the shape looks like:
```
type NativeModuleSchema = {
type: 'NativeModule',
aliases: NativeModuleAliasMap, // nothing new
spec: NativeModuleSpec,
moduleNames: $ReadOnlyArray<string>
}
type NativeModuleSpec = {
properties: $ReadOnlyArray<...>,
}
```
## Major Notes
1. We now parse the NativeModule requires (TurboModuleRegistry.get(Enforcing)?<Spec> calls) and record them in the schema.
2. A Codegen "Module" can contain either a Component schema, or a NativeModule schema, but **not** both.
## Snapshot Updates
The changes to the schema are visible in the snapshots updated in D24236505.
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: fkgozali
Differential Revision: D24236510
fbshipit-source-id: bd344d67136418725d840e7332fd2f6957326bb4
Summary:
The codegen output for the native modules in `Libraries/` has been verified to work with RNTester.
Publishing a new version as a prerequisite to start using the codegen at build time in open source.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24314972
fbshipit-source-id: edd0066c1cf33ba8e536cc5f145c057ca992eec1
Summary:
According to Node's documentation: https://nodejs.org/api/util.html#util_util_inspect_object_showhidden_depth_colors
> The util.inspect() method returns a string representation of object that is intended for debugging. **The output of util.inspect may change at any time and should not be depended upon programmatically.**
Therefore, this diff switches over our RN Codegen snapshot tests to use a `JSON.stringify` call, followed by a replace of `"` with `'`. This gets the job done without compromising readability.
**Question:** Why do we not use `"`? A: Jest escapes all `"` in the snapshots, which makes reading the snapshots/using them in the console harder.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24157056
fbshipit-source-id: 2f1aa2df28ac3ed4aa17bcdbcd23846ddbf804cf
Summary:
Remove extraneous newlines before and after structs, before copyright headers, and other locations.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24117137
fbshipit-source-id: 194996019b4cadef9239a78334f31c0bc89e3901
Summary:
Fixes an issue where, if a spec uses an array of elements where the element is a type alias, the generated code would use the wrong variable name.
An example of such a spec can be found in `NativeExceptionsManager.js`:
```
+reportSoftException: (
message: string,
stack: Array<StackFrame>,
exceptionId: number,
) => void;
```
The fix ensures the local variable name is passed through, ensuring that either p or itemValue_N is used when appropriate.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24116429
fbshipit-source-id: f39b75adb604c751d70a284a11a7fa6649b1344d
Summary:
This will make sure that the snapshot tests for the generators work with NullableTypeAnnotation.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24027246
fbshipit-source-id: cee93e40be7585ec527087d114f8326c2ecb9ddd
Summary:
Previously, all our type annotations contained a `nullable` property. This diff removes that property from all our NativeModule type annotations, and instead introduces a `NullableTypeAnnotation`.
**Some Benefits:**
- In all our serialization functions, we use Flow exhaustive checking to ensure that all type-annotations can be serialized. Since nullability is now recorded as a type annotation, Flow will ensure we always explicitly handle nullability. Previously, with nullability as a property, we could ignore it without any feedback from flow.
- This aligns the NativeModule schema with the ESTree spec.
- After this diff, we're one step closer to sharing type annotations with Codegen's schema. Many NativeModule type annotations now have the same shape as their Codegen counterparts. They will be merged in a subsequent diff.
**Downsides:**
- If you want to check whether a type annotation is of type `T`, you have to remember to unwrap the type annotation *yourself*. Flow won't warn you if you forget to unwrap the type, which can lead to incomplete handling to nullable types in our generators.
- When you're creating type annotations in code, previously, you *had* to specify nullability, since it was a property on all type annotation objects. Now, it's very possible for you to forget to wrap the type annotation, which will just lead to nullability bugs.
**Notes:**
- In the scheam, exported type annotations are *always* required. They can be made nullable using the new `Nullable` genric type.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24026887
fbshipit-source-id: 9e71e2c6102dc506824403dbb712488ca8507d08
Summary:
The Flow Parser's snapshots, which are serializations of the CodegenSchema object, are extremely difficult to read. In this diff, I explicitly serialized the schema objects using Node's `util.inspect`.
**Benefits:**
- The snapshots are more readable now.
- You can copy-paste the objects from the snapshot files directly into the Chrome console, or into other JavaScript files. This is a very useful feature, when we're testing the generators, or other infra that depends on the codegen.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24063112
fbshipit-source-id: 2c6ec3424aac8bab2688dc6ae286b73f90e4bef1
Summary:
The sample module is meant for demo only, but it lives alongside other core modules in react-native repo.
For now, exclude it in the Flow-type parsing, just like `NativeUIManager.js`
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24005108
fbshipit-source-id: 9ef524bfe2778dd983c94d1701f9ce49da5e0a68
Summary:
Making this change because I see this error when compiling Internationalization
```
➜ fbsource buck build //xplat/js/RKJSModules/Libraries/Internationalization:generated_objcpp_modules-InternationalizationApple
buck-out/gen/33fbdb84/xplat/js/RKJSModules/Libraries/Internationalization/generate_module_mm-Internationalization/FBReactNativeInternationalizationSpec-generated.mm:15:9: fatal error: 'FBReactNativeInternationalizationSpec.h' file not found
#import "FBReactNativeInternationalizationSpec.h"
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
Command failed with exit code 1.
command: [/Applications/Xcode_11.6.0_fb.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++, @/Users/ramanpreet/fbsource/buck-out/bin/33fbdb84/xplat/js/RKJSModules/Libraries/Internationalization/generated_objcpp_modules-InternationalizationApple#compile-FBReactNativeInternationalizationSpec-generated.mm.o...
```
Since the header namespace is "FBReactNativeInternationalizationSpec", we can only import the header file via "FBReactNativeInternationalizationSpec/FBReactNativeInternationalizationSpec.h", according to this buck documentation: https://buck.build/rule/cxx_library.html#headers. Not entirely sure how this target compiled before.
The legacy codegen buck target also set the header namespace to "": https://fburl.com/diffusion/3p85qhf9.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23978436
fbshipit-source-id: c9cd7c710edf94df6df10778f8603870f92275a7
Summary:
Adjust generated ObjC++ code to resolve a few build time and run time errors:
* Suppress CONSTANTS struct implementations
* Use type alias name as struct name when serializing arguments that involve a type alias
* Use actual number of arguments for a method when generating method map.
With these changes in place, RNTester can be built and run using the code that is generated by the new codegen.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23926500
fbshipit-source-id: 88fcbb795fd71dc8155eb26348db943975e13e84
Summary:
* Removed extraneous closing brace.
* Fixed static method signature, replacing double colon with an underscore (`static facebook::jsi::Value __hostFunction_Native${moduleName}SpecJSI::${methodName}()` -> `static facebook::jsi::Value __hostFunction_Native${moduleName}SpecJSI_${methodName}()`).
* Wrap `getConstants` selector name with `selector()`.
* Pass through `getConstants` and `constantsToExport` to allow de-duping of `getConstants` method in generator output.
Note that the FBReactNativeSpec that is output by the generator still has some issues that need to be addressed before it can be used.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D23910505
fbshipit-source-id: 37d884885b8878f38d40637377c2a74a728c3a13
Summary:
Just updated the generator to work with the new RN Codegen Flow Parser types.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D23667253
fbshipit-source-id: ef94e75287d37dfd7b80f61455a1bfa34bddeb28
Summary:
Just updated the generator to work with the new RN Codegen Flow Parser types.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D23667250
fbshipit-source-id: f36b5418101c40331964d1f9ede7c6bd7924383d
Summary:
Just updated the generator to work with the new RN Codegen Flow Parser types.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23667255
fbshipit-source-id: 40b7747aad89f6d5bbb9f42d59a4df9633060c66
Summary:
Just updated the generator to work with the new RN Codegen Flow Parser types.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D23667252
fbshipit-source-id: 34404a478ddd67446d82b5f98e1051300064e95c
Summary:
Just updating this generator to understand the new RN Codegen Module parser flow types.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D23667254
fbshipit-source-id: 558dd7ac5b4541edf40248b8ab8bb50d31fa8624
Kevin Gozali
Ramanpreet Nara
Héctor Ramos
Christoph Nakazawa
Frieder Bluemle