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:
We have first class support for Promises in our codegen. So, it's more appropriate to just call this PromiseTypeAnnotation, as opposed to GenericPromiseTypeAnnotation.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23645209
fbshipit-source-id: bfc0b909750e221e18be33acf197f342a2918aa9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/30014
This is the base setup to compile C++ as part of RNTester app. There is no dependencies on ReactAndroidNdk lib yet, just a bunch of ndkBuild setup in Gradle. Note: this is using Gradle's `nkdBuild` support instead of calling `ndk-build` manually like in ReactAndroid/build.gradle.
Reference: https://google.github.io/android-gradle-dsl/current/com.android.build.gradle.internal.dsl.ExternalNativeNdkBuildOptions.html
Note that `ANDROID_NDK` env var is honored to pick the right NDK version.
For now, this is gated behind `USE_CODEGEN` env variable.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D23887058
fbshipit-source-id: 7a962649461d15af46999a15b900464543e5b05c
Summary:
Now that the react-native-codegen produces the Android.mk for the JNI C++ output, let's compile them into its own shared library, to be included in the ReactAndroid final deliverable: libreact_codegen_reactandroidspec.so. This is gated behind `USE_CODEGEN` env var.
Note: RNTester specific C++ spec files are not compiled here.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D23809081
fbshipit-source-id: 7a90f420a923d5d02654facac01ffe025c321e44
Summary:
Move the directory creation logic to the CLI. This needs to be processed by RNCodegen.js eventually.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23618550
fbshipit-source-id: e7dc4f5fc37e5ad12b5c6ae8ea31fc9ef16d74b9
Summary:
The TurboModule system requires a lookup function to map the spec name (name used in JS) to the C++ TurboModule subclass. This is a pure C function. For now, generate one lookup function per set of modules found in the codegen schema.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D23618281
fbshipit-source-id: 889e07bdd4f2e5e93c4d14e60225f5b0c6683917
Summary:
The nested `.gitattributes` file in `packages/react-native-codegen/android/` caused some confusion on Linux and macOS, causing Git to show `packages/react-native-codegen/android/gradlew.bat` as modified (CRLF removed, LF added).
Instead of relying on repo-local `.gitattributes` files to convert endings in the working directory, the files should be committed to source control with the correct line endings in the first place. There is no reason to convert LF endings in .sh and many other file to CRLF on Windows (maybe this was an issue a long time ago, but unless Notepad is used this won't be a problem for practically all modern editors).
Also fixed the line endings of `scripts/launchPackager.bat` which was incorrectly committed as LF.
## Changelog
[Internal] [Fixed] - Line endings and .gitattributes
Pull Request resolved: https://github.com/facebook/react-native/pull/29792
Test Plan: Clone repo on Linux, macOS, and Windows, and make sure no modified files show up.
Reviewed By: fkgozali
Differential Revision: D23546135
Pulled By: mdvacca
fbshipit-source-id: 1572fcb959212f212b137066f1aa66f0bb6e86c3
Summary:
`-all` is the **default** for projects generated by Android Studio, and it provides **additional sources** helpful for debugging. It's also much more likely to already exist on a developer's machine (which has built other Android projects), avoiding additional downloads and saving disk space.
`-all` has also been the variant used in `react-native` for all versions prior to 5bc67b658e.
Follow-up to https://github.com/facebook/react-native/issues/29613
## Changelog
[Android] [Changed] - Use Gradle Wrapper 6.6 (-all variant)
Pull Request resolved: https://github.com/facebook/react-native/pull/29793
Test Plan: No test needed since versions are the same.
Reviewed By: fkgozali
Differential Revision: D23406546
Pulled By: mdvacca
fbshipit-source-id: b74dbbfc0317bccf1940b1e5062d866e50aed28a
Summary:
This implements the full NativeModuleResolvedType for each NativeModule spec, producing .java spec files in the output directory. The output files are now compiled during build time for :ReactAndroid and :packages:rn-tester:android:app.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23312858
fbshipit-source-id: c521b9d6602677fd275891cf44329740c6bd7387
Summary:
For each resolved type, define how to process its own type and whether it should produce generated code/file, minus the NativeModuleResolvedType (will be in the next commit).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23307961
fbshipit-source-id: 87af09867aace7a5ff060a33a00b141048630eda
Summary:
This is the base setup for ResolvedType. Each Type needs to be resolved to its final representation, which knows what Java type it needs, and what standalone Java code (e.g. class) it needs to produce. Individual resolved types are not yet implemented, this commit provides the flow to pass the parsed structure (from schema) to the resolution logic.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23288208
fbshipit-source-id: 18535d5fae8ca15f6d9374bdba38f57dfd4300e8
Summary:
Instead of recreating the schema structure, the generator only needs to collect the list of types that it needs to generate for. So instead, let's just add each parsed type into a map using TypeId as the key. This means every inner types in the schema needs its own unique TypeId. This was a change from the previous commit where we didn't assign unique names to the types. Here's the reasoning:
* In Java, any generated class needs to be in its own file.
* If a NativeModule spec defines a few aliases, and or inner types (function args, return type shape, etc) that needs representation with a dedicated class, we need to track them as well for code generation.
* This means, the schema format is no longer relevant for the code generation step, so let's produce a structure that's more efficient for code generation
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23287818
fbshipit-source-id: 7caf4e95aeafe5c8ba336af290179b85bf87ad6d
Summary:
Instead of invoking JavaGenerator when the task is registered, do it when the task actually executes. This way, it will wait until the other task it depends on to finish executing.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23276359
fbshipit-source-id: 6aea98d97121f2dcfd83b299e38debc767f08240
Summary:
This parses the JSON schema's aliases and reserved function valye types. It also assigns TypeId correctly now:
* TypeId is an identifier for a specific type, that can be referred by others
* This means only aliases should have TypeId.typeName. Properties' names are not typeNames
* NativeModule spec's typeName is hardcoded to `Spec`, see T71955395
This way, whenever we encounter an `AliasType`, we can just lookup the actual Type by a quick Map lookup with TypeId as the key.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23181432
fbshipit-source-id: 9d0ea17dbf601589d8f3fc1955e0c9406a80e244
Summary:
This parses the output JSON schema into Java Type's, without any alias resolution. Some parts of the schema have incomplete information, hence a bunch of TODOs in the code expressing the issues.
Notes:
* The type structure here could be implemented in other codegen generators as well (including the RNCodegen.js' generators) for better type safety and correctness. With this exercise, I was able to catch a few issues mentioned above.
* This commit does not produce any Java code with JavaPoet yet, just parsing the schema.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23152891
fbshipit-source-id: 9f774dd98975f7202d3faf11c3fbfb83d4c97f5a
Summary:
JavaGenerator is a Java-based implementation for generating codegen output from the parsed schema file. Right now the output is a hardcoded Java file. In the next commits, proper JavaGenerator impl will be added.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23100171
fbshipit-source-id: 1bef23e3dba4d8c222ebdece0edeb4435d388cd4
Summary:
Instead of applying configs from gradle scripts, this introduces a proper Gradle plugin to enable Codegen in an application or library project. In the build.gradle, one enables it by:
```
plugins {
id("com.android.application")
id("com.facebook.react.codegen") // <---
}
// ...
react { // <--- the new plugin extension
enableCodegen = System.getenv("USE_CODEGEN")
jsRootDir = file("$rootDir/RNTester")
reactNativeRootDir = file("$rootDir")
}
```
The plugin supports `react` plugin extension as demonstrated above. Adding this:
* automatically generates all TurboModule Java files via react-native-codegen **before the `preBuild` Gradle task**
* automatically adds the files to the `android {}` project configuration
* is done per project (build.gradle)
This will be the foundation for future React Native gradle plugin beyond just for react-native-codegen.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D23065685
fbshipit-source-id: 4ea67e48fab33b238c0973463cdb00de8cdadfcc
Summary:
Using the same copies from react-native root dir.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22936067
fbshipit-source-id: 8484991f26d51085c6c45405a940e94624b35e06
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
Kevin Gozali
Ramanpreet Nara
Frieder Bluemle