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:
`RCTPropsAnimatedNode` uses the bridge to access it's current surface presenter to perform animations.
In bridgeless mode, the surface presenter is not owned by the bridge. Instead, pass the surface presenter through the ownership chain:
`RCTNativeAnimated*Module` -> `RCTNativeAnimatedNodesManager` -> `RCTPropsAnimatedNode`
`RCTSurfacePresenter` should not be strongly held by any of these animation internals. If it gets destroyed at a higher level, animations should not be completed.
Changelog: [Internal]
Differential Revision: D23272735
fbshipit-source-id: ce08ee3b59ac2ba70e31cebb7ba8e9f3a644c848
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 adds all the packages we use to the workspace in open source, which means we can change our publish scripts to also publish the packages from the repo every time we publish the main repo. I'll work with somebody from the community on that part.
Note: We do not use `eslint-config-react-native-community` internally and it pulls in a lot of packages we don't need. It is part of the React Native repo because it is used in the RN app template but we may want to choose to move it out into a separate repo at some point.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D23208695
fbshipit-source-id: 02d401721dfdc8bbb2305f8ac3381f1e98c18f1d
Summary:
## 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
-->
This PR aims to migrate the RNTester App to `packages` directory. But is currently, open to inspect the CI issues and resolve the merge conflicts.
Currently done
- Working on iOS
- Working on Android
- Detox Tests working on iOS
Need to work on
- Errors generated by the CI builds
[General] [Changed] - Migrated the RNTester App to the packages directory.
Pull Request resolved: https://github.com/facebook/react-native/pull/29567
Test Plan: It runs on both ios and android for now and the detox iOS builds are working.
Reviewed By: cpojer
Differential Revision: D23034761
Pulled By: rickhanlonii
fbshipit-source-id: e04bb06e1c7ef15d340206090d1575a871b9e6f5
Summary:
This diff filters the iOS C++ friles that are generated by the oss-android-codegen script
Also, as part of this diff I'm inlcuding .cpp files into the output.
These files are only used and compiled in Android
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D23169268
fbshipit-source-id: 404607f3cd6e59197291ea67701774c9c492a282
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:
This new buck target will execute the code gen and copy C++ files to the output directory. This will be used to integrate these files into RN Tester
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D23115538
fbshipit-source-id: de4135be697c36cd559edf416986299511c31744
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
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 (https://github.com/facebook/react-native/commit/650c0f64f1262d26a31b61d2a7576c485f3efa13) 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:
This babel plugin will also take care of the JS TurboModule Codegen. Therefore, we should rename this into something more generic.
Changelog:
[General][Changed] Rename babel-plugin-inline-view-configs to react-native/babel-plugin-codegen
Reviewed By: rickhanlonii, cpojer
Differential Revision: D22803209
fbshipit-source-id: 416c97fea6fa0820d25bbc91033a0cbbbbbff825
Summary:
The `eslint-plugin` package intent notice at the top of the README mistakenly refers to itself, it should instead refer to `react-native-community/eslint-config`
## Changelog
[Internal] [Fixed] - Fix typo in `eslint-plugin` README
Pull Request resolved: https://github.com/facebook/react-native/pull/29337
Test Plan: 1. ensure link works properly
Reviewed By: GijsWeterings
Differential Revision: D22493834
Pulled By: cpojer
fbshipit-source-id: 16b8173d3c2add7a85e142eac4ab36aef685062b
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 (https://github.com/facebook/react-native/commit/e261f022fe6a7653b79330f878fed143725f5324), 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:
This dependency upgrade ensures that this eslint config now supports the latest TypeScript syntaxes.
## Changelog
[General] [Fixed] - Upgrade dependencies.
Pull Request resolved: https://github.com/facebook/react-native/pull/29048
Test Plan: Try this new version of the plugin on your project.
Reviewed By: GijsWeterings
Differential Revision: D21879997
Pulled By: cpojer
fbshipit-source-id: cb54c2b56361f7c20994d981c61826f7f50350de
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:
The combination of `eslint` (v7.0.0), `react-native-community/eslint-config` (v1.1.0), and `flow-typed` (v3.1.0) causes the following error (`ESLint couldn't find the plugin "eslint-plugin-prettier"`) because `flow-typed` (v3.1.0) depends on `prettier: ^1.19.1` (c.f. https://github.com/flow-typed/flow-typed/blob/master/cli/package.json#L38).
To deal with the error, developers should install `prettier` (v2.x) directly in `devDependencies`.
```
Oops! Something went wrong! :(
ESLint: 7.0.0
ESLint couldn't find the plugin "eslint-plugin-prettier".
(The package "eslint-plugin-prettier" was not found when loaded as a Node module from the directory "/Users/exkazuu/Projects/test".)
It's likely that the plugin isn't installed correctly. Try reinstalling by running the following:
npm install eslint-plugin-prettier@latest --save-dev
The plugin "eslint-plugin-prettier" was referenced from the config file in ".eslintrc.js » react-native-community/eslint-config".
If you still can't figure out the problem, please stop by https://gitter.im/eslint/eslint to chat with the team.
```
## Changelog
[Internal] [Changed] - `react-native-community/eslint-config` README recommends developers to install prettier directly
Pull Request resolved: https://github.com/facebook/react-native/pull/28930
Test Plan: This PR changes only README, so tests are not required.
Differential Revision: D21659672
Pulled By: cpojer
fbshipit-source-id: 67c775e664d539815fa78e12574d73eaa1942de1
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](https://github.com/facebook/metro/blob/00867816eb9b2f69c8af9cebb523e9e4d280671a/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
Kevin Gozali
Jordan Brown
Peter Argany
Rick Hanlon
Christoph Nakazawa
stealthanthrax
David Vacca
Ramanpreet Nara
Gijs Weterings
Jiawei Lv
Vince Picone
Dan Abramov
Héctor Ramos
Eli White
Lulu Wu
Tim Yung
William Candillon
Sakamoto, Kazunori
empyrical
