Summary:
Instead of sourcing-in a .gradle file to setup codegen tasks in Gradle, let's define a proper `com.facebook.react.codegen` Gradle plugin, so that any Gradle project (lib/app) can include it via:
```
plugins {
id 'com.facebook.react.codegen'
}
```
The idea (not yet implemented in this commit) is to then allow those projects to add this section in the projects:
```
codegen {
enableCodegen = ...
jsRootDir = ...
}
```
This is more scalable and less hacky.
Important notes:
* The Gradle plugin should be prepared during the build, we're not going to publish it to Maven or other repo at this point.
* This setup is inspired by composite build setup explained here: https://ncorti.com/blog/gradle-plugins-and-composite-builds
* All android specific setup is added under `packages/react-native-codegen/android/` dir, but long term, we may want to move it up to `packages/react-native-codegen/` along side setup for other platforms.
* As part of this setup, the plugin will have an option (to be validated) to produce Java specs using https://github.com/square/javapoet
* This is the same library already used for React Native Android annotation processors
* This generator will not deal with parsing Flow types into schema, it will just takes in the schema and produce Java code
* We're evaluating whether JavaPoet is a better choice for Java code generation long term, vs building it in JS via string concatenation: https://github.com/facebook/react-native/blob/master/packages/react-native-codegen/src/generators/modules/GenerateModuleJavaSpec.js
* This commit produces a sample Java code, not the actual codegen output
Changelog: [Internal]
To try this out, run this Gradle task:
```
USE_CODEGEN=1 ./gradlew :ReactAndroid:generateJava
```
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D22917315
fbshipit-source-id: 0b79dba939b73ff1305b4b4fd86ab897c7a48d53
Summary:
This builds on the previous commit and complete all current NativeModule spec support for React Native Android:
* method param (nullable) typing
* promise return support
* sync method
* getConstants() special Android runtime validation
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22862422
fbshipit-source-id: abc6d46fb8ce5863677910de1acc8bb6a927e7da
Summary:
* Allow generate-native-modules-specs-cli.js to generate Android specific files
* Add stub impl for Java spec generation (the output are still incomplete, see the next diffs for missing impl + tests)
* Adjust the CLI to only produce modules stuffs, there's no need to produce components code
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22860936
fbshipit-source-id: 38aae390189f143f6c6216995437ac1ff15a1788
Summary:
Sometimes mobile build systems just needs to provide the JS root dir to scan for NativeModules + NativeComponents, so let's support that directly in the CLI. This way, each build system doesn't have to do its own grep/crawling/filtering of files.
This will be needed for CocoaPods/Gradle integration.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22850011
fbshipit-source-id: fe202fa5e5a490af6d76fd10e761c9c3805fc11f
Summary:
`babel-plugin-codegen` will run the NativeModules codegen on each NativeModule spec, and inline the generated schema into the spec's `TurboModuleRegistry.get(Enforcing)?` call. This diff will forward that schema to `__turboModuleProxy` function (i.e: the TurboModule C++ infra).
**Note:** Both this and D2280384 can't be landed until D22743294 (650c0f64f1) hits production (1-2 weeks).
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D22832730
fbshipit-source-id: aecaf9943f9b01be805ff6b90249a6cbc6abdd20
Summary:
This diff:
- Moves the NativeModule flow types to the bottom of `CodegenSchema.js`.
- Re-organizes the NativeModuel flow type declarations based on when they're first used. Essentially, we start off by declaring a giant 'NativeModuleShape' type, which uses smaller undeclared types. Then we declare all the undeclared children of `NativeModuleShape`, and on and on. This way, you know where to start reading the types, and you can easily tell how every type relates to every other type.
Changelog: [Internal]
Differential Revision: D22828840
fbshipit-source-id: 5b4b9466a41b9bcb92a1de159bcbc12e4dc01df3
Summary:
This diff moves fabric C++ code from ReactCommon/fabric to ReactCommon/react/renderer
As part of this diff I also refactored components, codegen and callsites on CatalystApp, FB4A and venice
Script: P137350694
changelog: [internal] internal refactor
Reviewed By: fkgozali
Differential Revision: D22852139
fbshipit-source-id: f85310ba858b6afd81abfd9cbe6d70b28eca7415
Summary:
**Motivation:**
Match the old codegen's behavior when generating structs for type alias derived objects.
**Problem description:**
Take, for example, the following spec:
```
export type MyTypeAlias = { /* ... */ }
export interface Spec extends TurboModule {
// ...
+myMethod: (paramName: MyTypeAlias) => void;
// ...
}
```
The codegen needs to generate a struct to expose the properties of the type alias object. The codegen was producing the following output:
```
- (void)myMethod:(JS::MyModule::SpecMyMethodParamName &)paramName;
```
...which does not match the output from the original codegen:
```
- (void)myMethod:(JS::MyModule::MyTypeAlias &)paramName;
```
The original codegen generates a struct using the type alias name, while the new codegen was generating a struct that uses a combination of the property and parameter names.
Now that type alias names are exposed in the schema, the new codegen can match the original codegen's behavior.
**De-duplication of structs:**
Prior to these changes, type aliases were expanded into regular object types. This meant that any spec that used a type alias more than once would lead to redundant structs getting created. With these changes, we only generate the one struct per type alias, matching the old codegen.
**Expansion of type aliases:**
A new type was introduced in D22200700 (e261f022fe), TypeAliasTypeAnnotation:
```
export type TypeAliasTypeAnnotation = $ReadOnly<{|
type: 'TypeAliasTypeAnnotation',
name: string,
|}>;
```
This type may now appear in several locations where a `{| type: 'ObjectTypeAnnotation', properties: [] |}` otherwise would have been used. A `getTypeAliasTypeAnnotation` function is introduced which, given an alias name and an array of aliases provided by the module, will produce the actual object type annotation for the given property parameter.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D22244323
fbshipit-source-id: 125fbf0d6d887bd05a99bf8b81b30bdda4f1682b
Summary:
The current parser behavior flattens out any object type aliases into ObjectTypeAnnotations. Generators can treat these as regular objects and generate the applicable native code. This, however, can lead to repetition whenever an object type alias is re-used in the same native module.
I propose we treat these as a special case, using a TypeAliasTypeAnnotation to denote them as type aliases. Generators can look up the actual signature for a given object alias by referring to the "aliases" array that is provided in the schema.
**Proposed schema change:**
Adds an "aliases" key to each module in the schema:
```
export type NativeModuleShape = $ReadOnly<{|
properties: $ReadOnlyArray<NativeModuleMethodTypeShape>,
aliases: $ReadOnlyArray<{|
name: string,
typeAnnotation:
| $ReadOnly<{|
type: 'ObjectTypeAnnotation',
properties: $ReadOnlyArray<ObjectParamTypeAnnotation>,
|}>
| $ReadOnly<TypeAliasTypeAnnotation>,
|}>,
|}>;
```
Example:
```
{
modules: {
SampleTurboModule: {
nativeModules: {
SampleTurboModule: {
aliases: [],
properties: [],
},
},
},
},
}
```
Method parameters will now support the new 'TypeAliasTypeAnnotation' wherever a param might have used a 'ObjectTypeAnnotation':
```
export type TypeAliasTypeAnnotation = $ReadOnly<{|
type: 'TypeAliasTypeAnnotation',
name: string,
|}>;
```
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D22200700
fbshipit-source-id: 15684620783c752f2fb482ba4b88d1fd1cc07540
Summary:
Moving property handling functions to their own properties.js file. No changes other than adding types to params.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D22208243
fbshipit-source-id: 4a7d2c6e19c151954da793d399af9a256a4a40b7
Summary:
Need to publish a new version now that we want to not publish Flow code
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: kacieb
Differential Revision: D22265050
fbshipit-source-id: a9a0d03b1e2c1ec72e642b0af070ba48426825f8
Summary:
Move to Utils for reuse, and change parameter to take a property object.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D22146669
fbshipit-source-id: e028821cdb11361a45226de0247aa4551b5ade1d
Summary:
Currently, the codegen supports `$ReadOnly` values, but not `$ReadOnly` properties on objects. This adds support for those (by pretty much ignoring them).
Changelog:
[General][Added] - Support `$ReadOnly` in object properties when defining native event types
Reviewed By: TheSavior
Differential Revision: D22023142
fbshipit-source-id: 7167852050925bf31392607923576f023e729f5f
Summary:
Restore legacy support for mixed union types.
These are not type safe and modules should use a different type, but we have a precedent for supporting these in the existing Linking native module. The new codegen will generate native code for these, and show a warning to encourage use of a better type.
Generate native code for elements in arrays of objects.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D21848260
fbshipit-source-id: 0b8cbf25e7a02791b4d77e349227a2b0744854f4
Summary:
When a property returns an array type, use the actual element type when generating structs and inlines.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D21651351
fbshipit-source-id: 14cadf209c38a301c9c65fcaadd8a292c1936349
Summary:
*This is a follow-up to https://github.com/facebook/react-native/issues/28645, redone using a build script based off of Metro's build script instead of using `flow-remove-types` and `flow-copy-source`.*
This pull request adds a build step to `react-native-codegen` that builds the Flow-annotated JS files so that users of the NPM module `react-native-codegen` do not need to use require hooks to be able to import it.
A new build script, `scripts/build.js` is added that builds every JS file in `src/` into a `lib/` folder, and also copies over the original Flow annotated files to `lib/` with a `.js.flow` extension, so users of `react-native-codegen` can still typecheck against it using Flow. The shell scripts in `src` are also copied over. It is based off of the [build script from Metro](00867816eb/scripts/build.js)
## Changelog
[General] [Added] - Codegen: Add prepublish script to build Flow files
Pull Request resolved: https://github.com/facebook/react-native/pull/28827
Test Plan:
I am able to make use of the Codegen scripts without needing to use the `flow-node` CLI or the `flow-remove-types/register`
require hook.
Reviewed By: cpojer
Differential Revision: D21412173
Pulled By: hramos
fbshipit-source-id: 26ae67cdd04652ca4700a069a234a25558773cb1
Summary:
Handle properties named 'id' as a special case.
An example of a native module that ran afoul of this is `ExceptionsManager`.
Observe how the ExceptionsManager spec at `Libraries/Core/NativeExceptionsManager.js` defines the ExceptionData type as containing an `id` property:
```
export type ExceptionData = {
message: string,
originalMessage: ?string,
name: ?string,
componentStack: ?string,
stack: Array<StackFrame>,
id: number,
isFatal: boolean,
// flowlint-next-line unclear-type:off
extraData?: Object,
...
};
```
Prior to this change, the generated code would redefine id in the SpecReportExceptionData struct...
```
namespace JS {
namespace NativeExceptionsManager {
struct SpecReportExceptionData {
// ...redacted...
double id() const; <---
// ...redacted...
SpecReportExceptionData(NSDictionary *const v) : _v(v) {}
private:
NSDictionary *_v;
};
}
}
```
...which would result in a build time error:
```
inline double JS::NativeExceptionsManager::SpecReportExceptionData::id() const
{
id const p = _v[@"id"];
^--- build time error here
return RCTBridgingToDouble(p);
}
```
Comparing the above example with the currently checked in `FBReactNativeSpec.h`, I see the expected output should be:
```
namespace JS {
namespace NativeExceptionsManager {
struct SpecReportExceptionData {
// ...redacted...
double id_() const;
// ...redacted...
SpecReportExceptionData(NSDictionary *const v) : _v(v) {}
private:
NSDictionary *_v;
};
}
}
```
...and...
```
inline double JS::NativeExceptionsManager::SpecReportExceptionData::id_() const
{
id const p = _v[@"id"];
return RCTBridgingToDouble(p);
}
```
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D21395463
fbshipit-source-id: e412648013ff9f70ebd294b6f5f81f1faccb4604
Summary:
Currently the schema only allows to exclude a single platform (iOS OR Android). There are cases where we need to exclude multiple. This change converts the previous `excludePlatform` string property into an `excludePlatforms` array.
Changelog:
[Internal][Changed] - Added support to exclude multiple platforms in Codegen.
Reviewed By: sammy-SC
Differential Revision: D21426950
fbshipit-source-id: eff36ffa207109274794b4b300bf6313f8286161
Summary:
Move and create an empty rule that redirects as well, to handle //arvr rules
Need to do this way, since ovrsource sync rules are in different repo.
allow_many_files
allow-large-files
Steps:
- [X] Move glog from xplat/third-party to /third-party
- [ ] Update references in ovrsource to translate to //third-party instead of //xplat/third-party
- [ ] Get rid of temporary rule
- [ ] Update fbsource/third-party/glog to 0.3.5 (what we have in ovrsource)
Changelog: [Internal] Update reference for glog from xplat/third-party to /third-party.
Reviewed By: yfeldblum
Differential Revision: D21363584
fbshipit-source-id: c1ffe2dd615077170b03d98dcfb77121537793c9
Summary:
Import folly to handle optionals (`folly::Optional<__type__>`)
Sort modules and indent generated code to match output from the old codegen. While not strictly necessary as these are generated files that should not be edited by hand, I found that matching the old codegen in this regard made it less of a chore when it came to comparing the output of both codebases.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D21395231
fbshipit-source-id: 289d617d7a2d93724456c80afea57a49c108cb9b
Summary:
`babel/preset-env` pulls in a number of unused deps, like `caniuse-lite` (3 MiB) that knows about which browsers support certain features. We do not ship to browsers and always know which version of node we are using, so we don't need to pull this in.
I changed `jscodeshift` to optionally depend on `babel/preset-env` instead of always pulling it in.
This reduces node_modules by 7 MiB.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D21374475
fbshipit-source-id: 6f55e96e990ec0ca12f17bb3657bfa5429796b93
Summary:
I removed 1 MiB from `jscodeshift` as it was shipping with docs: 5885662920
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D21368889
fbshipit-source-id: 452fd4cedcc749d972adbb69df5c95117dd55b15
Summary:
Adds support for `RootTag` in the new codegen for Native Component Commands.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D21169371
fbshipit-source-id: 3b25433f3328e9c04cfe45bb176fc06d63559f14
Summary:
Adds support for `RootTag` in the new codegen for NativeModules/TurboModules.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D21160788
fbshipit-source-id: 952189f6e8bc8fde8b403d4c0e77b5d66b3f03e4
Summary:
Adds a `RootTag` parser test for the new codegen for NativeModules/TurboModules.
I'm doing this in a prerequisite commit in order to make the diff of the diff clearer when I implement proper support for `RootTag`.
This also fixes some of the minor typos and mistakes that I noticed. I also wanted to land these benign snapshot changes independent of the upcoming behavior changes.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D21160792
fbshipit-source-id: 5f29f34035da30d7afa2369dbc19e95954553e88
Summary:
Straightforward rename to clarify the purpose of this type.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D21160791
fbshipit-source-id: 422d09243edda0660815eb2f0ce51f7e56134983
Summary:
Straightforward rename to clarify the purpose of this type.
The current naming made more sense before the codegen also produced code for NativeModules.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D21160793
fbshipit-source-id: 6787ef298e32ff1b4d506afd831af96764f5af6f
Summary:
Straightforward rename to clarify the purpose of this type.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D21160790
fbshipit-source-id: eaf5e8c9f51e16134e153a6321857234be1aa338
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/28719
The Buck dependencies for the schema rule is missing the source files for the new codegen (and specifically, the parser).
Changelog:
[Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: cpojer
Differential Revision: D21162993
fbshipit-source-id: 4addb6f257134e245a5d86dd427ee2536ed6d658
Summary:
This diff makes the ColorValue export "official" by exporting it from StyleSheet in order to encourage its use in product code.
Changelog: Moved ColorValue export from StyleSheetTypes to StyleSheet
Reviewed By: TheSavior
Differential Revision: D21076969
fbshipit-source-id: 972ef5a1b13bd9f6b7691a279a73168e7ce9d9ab
Summary:
## Summary
Please check out D21035208.
## Changes
- `ObjCTurboModule::ObjCTurboModule` changed to accept a bag of arguments `const ObjCTurboModule::InitParams` instead of an argument list.
- TurboModule iOS codegen scripts updated to generated `ObjCTurboModule` subclasses that accept a `const ObjCTurboModule::InitParams` object in their constructor, and forward it to `ObjCTurboModule::ObjCTurboModule`.
- All manually checked in code-generated ObjC++ classes (i.e: RCTNativeSampleTurboModule, RCTTestModule, FBReactNativeSpec) are updated.
## Rationale
This way, the code-gen can remain constant while we add, remove, or modify the arguments passed to ObjCTurboModule.
## Commands run
```
function update-codegen() {
pushd ~/fbsource && js1 build oss-native-modules-specs -p ios && js1 build oss-native-modules-specs -p android && popd;
}
> update-codegen
```
Changelog:
[iOS][Changed] Update ObjCTurboModule to use ObjCTurboModule::InitParams
Reviewed By: PeteTheHeat
Differential Revision: D21036266
fbshipit-source-id: 6584b0838dca082a69e8c14c7ca50c3568b95086
Summary:
Adding a README for `react-native-codegen` since the package was published.
Also added a `files` prop in package.json so unused file won't be included in the package.
## Changelog
[Internal] [Changed] - Add README for react-native-codegen.
Pull Request resolved: https://github.com/facebook/react-native/pull/28507
Test Plan: verify js files to function correctly without including files other than `src`
Reviewed By: rickhanlonii
Differential Revision: D20836113
Pulled By: cpojer
fbshipit-source-id: e860f14760e9c1dbe121f5fb95ccf72d4ddb2af1
Summary:
This is necessary to integrate TurboModule async method dispatch with the bridge's `onBatchComplete` event. See D20717931 for more details.
This diff is similar to D20480971.
**Note:** This stack doesn't really make any functional changes, since the native CallInvoker is `nullptr` right now.
Changelog:
[Internal]
Reviewed By: fkgozali
Differential Revision: D20809199
fbshipit-source-id: bf465a3a51bdddb8b56d1e696ca510fdf071f9ec
Summary:
In preparation for upgrading babel, I'm updating some of our source transform tools to the latest versions.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D20675201
fbshipit-source-id: fa4fee2652529c6677087e42cdd1325a8080e46f
Summary:
`fbsource//xplat` and `//xplat` are equivalent for FB BUCK targets. Removing extra prefix for consistency.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D20656211
fbshipit-source-id: deb91b917d349bc500acbb03d734ff621f6e1fc7
Summary:
This gets us on the latest Prettier 2.x:
https://prettier.io/blog/2020/03/21/2.0.0.html
Notably, this adds support for TypeScript 3.8,
which introduces new syntax, such as `import type`.
Reviewed By: zertosh
Differential Revision: D20636268
fbshipit-source-id: fca5833d003804333a05ba16325bbbe0e06d6c8a
Summary:
Previously, I had logic inside `RCTTurboModuleManager` to attach the `id<RCTTurboModulePerformanceLogger>` to the `ObjCTurboModule` object
```
/**
* By default, all TurboModules are long-lived.
* Additionally, if a TurboModule with the name `name` isn't found, then we
* trigger an assertion failure.
*/
auto turboModule = [strongSelf provideTurboModule:moduleName];
/**
* TODO(T63718299): Move this setter into the ObjCTurboModule constructor
*/
if (performanceLogger) {
if (auto objCTurboModule = std::dynamic_pointer_cast<facebook::react::ObjCTurboModule>(turboModule)) {
objCTurboModule->setRCTTurboModulePerformanceLogger(performanceLogger);
};
}
```
This diff removes that logic in `RCTTurboModuleManager`, and it also removes `ObjCTurboModule::setRCTTurboModulePerformanceLogger`. Henceforth, we'll instead pass the `id<RCTTurboModulePerformanceLogger>` into `ObjCTurboModule`'s constructor. I've made all the necessary changes to the codegen scripts in this diff as well.
This should also resolve T63903079 by simply eliminating the code that's crashing production FB apps.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D20480971
fbshipit-source-id: c3899981f880aa5d1354b5c3f4018c8fd57c3bae
Summary:
The new name is get_preprocessor_flags_for_build_mode.
Changelog: [Internal]
Reviewed By: d16r
Differential Revision: D20351718
fbshipit-source-id: 67628ce81e7244f0f72af2d00d92842a649ff619
Kevin Gozali
Gijs Weterings
Ramanpreet Nara
David Vacca
Jiawei Lv
Héctor Ramos
Eli White
Lulu Wu
Tim Yung
empyrical
João Vieira
Nikita Lutsenko
Christoph Nakazawa
Zack Argyle
George Zahariev
Jesse Katsumata
Chatura Atapattu
Michael Bolin
Adam Ernst