Summary:
## New Functionality
- Detect if the JS file represents a NativeModule spec.
- **Note:** A JS file is a NativeModule spec if it contains a flow `interface` that extends `TurboModule`. This logic is copied over from the OSS Codegen, here: https://github.com/facebook/react-native/blob/7ccb67a49c087e7ee536c2ffb71717e68a79324b/packages/react-native-codegen/src/parsers/flow/index.js#L60-L75
- For all NativeModule specs, generate the spec's schema using the OSS Codegen for Modules, and conditionally inline it into every `TurboModuleRegistry.get(Enforcing)?` call in the spec, like so:
**Before:**
```
/**
* flow
*/
import type {TurboModule} from 'RCTExport';
export interface Spec extends TurboModule {
//...
}
export default TurboModuleRegistry.get<Spec>('FooModule');
```
**After:**
```
/**
* flow
*/
import type {TurboModule} from 'RCTExport';
export interface Spec extends TurboModule {
//...
}
export default TurboModuleRegistry.get<Spec>('FooModule', __getModuleShape());
function __getModuleShape() {
if (!(global.RN$EnableTurboModuleJSCodegen === true)) {
return undefined;
}
return {...};
}
```
Changelog: [General][Added] Extend react-native/babel-plugin-codegen to generate TurboModule JS codegen
Reviewed By: TheSavior
Differential Revision: D22803845
fbshipit-source-id: 18c157a1dbfcc575012184de31c38908acd53c36
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
Summary:
The names of events and props flow type annotations are singular. The names of the commands flow types are however plural. This diff renames all "Commands*" flow types to be singular.
**Motivation:** Consistency
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24708276
fbshipit-source-id: 5d5d2123426ca1139953169d0ea764b82b2f3809
Summary:
All throughout the Codegen schema, we re-declare the following shape:
```
{
type: 'ObjectTypeAnnotation',
properties: $ReadOnlyArray<{
name: string,
optional: boolean,
typeAnnotation: ...
}>
}
```
This diff introduces an `ObjectTypeAnnotation<T>` utility type and replaces those re-declarations with instantiations of this type.
**Motivation:** To reduce noise in the CodegenSchema. This should be a pure refactor, and shouldn't actually change any behaviour.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24707963
fbshipit-source-id: 6b4eb711ddd041f3a041109ade5ad5644fb16924
Summary:
This diff re-organizes CodegenSchema to declare the larger types first, which use smaller undeclared types. The smaller types are declared further down the file, and they themselves use even smaller undeclared types.
**Motivation:** Increase the readability of CodegenSchema.js. Now, if people want to understand the shape of the Codegen Schema, they can just read the file from top to bottom.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24701424
fbshipit-source-id: 181e87bff5e32d998463221891f459b0df26ef52
Summary:
Reserved type annotations can appear in three different contexts: commands, props, and NativeModules. For now, commands and NativeModules share the same reserved type annotations. In the future, we may want to merge these reserved type annotations with the props reserved type annotations.
**Motivation:** The meaning of FunctionValue in FunctionValueTypeAnnotation isn't clear - in fact, it's downright confusing. Therefore, this diff renames this Flow type to ReservedTypeAnnotation, which I believe sufficiently captures the intent of the type annotation.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24701322
fbshipit-source-id: bde0273b4a89c9e7175c60ed3468ed870b320044
Summary:
Our CodegenSchema is littered with types that have the following shape
```
{
name: string,
optional: boolean,
typeAnnotation: ...
}
```
In all these types, the only difference is the typeAnnotation. This diff introduces a new utility type called `NamedShape`, that just creates this shape, given a type annotation. This should help reduce the amount of noise in the CodegenSchema, and make it a bit easier to read.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24701331
fbshipit-source-id: a30d3e22933116e3dabf7929615905febacecba3
Summary:
All ObjectTypeAnnotation *properties* in the codegen have the following shape:
```
{
name: string,
optional: boolean,
typeAnnotation: ...
}
```
EventObjectTypeProperty is a property of some ObjectTypeAnnotation, yet it doesn't follow this pattern. This diff cleans up EventObjectPropertyType. This is a part of a larger effort to clean up the Component Schema and unify the notion of a "type annotation" across the Component and Module schemas.
Reviewed By: yungsters
Differential Revision: D24701027
fbshipit-source-id: edc7dc632a217fb5a82ffd8a62aef990baf398c2
Summary:
This PR makes it possible to build iOS applications with Hermes. Note that it doesn't work with `use_frameworks!` just yet.
Fixes https://github.com/facebook/react-native/issues/27845 (by downgrading iOS deployment target for RCT-Folly to 9.0)
Fixes https://github.com/facebook/react-native/issues/28810 (as above)
Checklist:
- [x] Adjust release scripts to create Hermes bytecode bundle
- [x] Release new Hermes npm package that includes iOS files (unreleased right now, if you want to try locally, you have to clone Hermes and `yarn link` its master to this project)
- [x] Test on a new React Native application in both Debug and Release (Device)
- [x] Test on an RNTester application in both Debug and Release (Device)
- [x] Add missing `i386` to Hermes framework and enable Bitcode
- [x] Inspect CI failures for possible regressions
- [x] Resolve Folly issue as reported https://github.com/facebook/react-native/issues/27845 and https://github.com/facebook/react-native/issues/28810
- [x] Release new Hermes and test against it that everything works
## Changelog
[IOS] [FEATURE] - Enable Hermes on iOS
[INTERNAL] - Upgrade to CocoaPods 1.10.0 to resolve Xcode 12.0 issues
[INTERNAL] - Upgrade to Xcode 12.0 on the CircleCI
[INTERNAL] - Fix building RNTester in Release mode
[INTERNAL] - Fix build-time errors of `libevent` with `use_frameworks!`
[INTERNAL] - Introduce `USE_HERMES` variable and test all RNTester configurations on the CI
[INTERNAL] - Do not fetch CocoaPods repository since we're using CDN anyway
Pull Request resolved: https://github.com/facebook/react-native/pull/29914
Test Plan:
Turn on `hermes_enabled` to true in your `Podfile`, install pods, and run the iOS application. Your app should be running Hermes now.
Preview: (note "Engine: Hermes")
<img width="395" alt="Screenshot 2020-09-09 at 19 22 32" src="https://user-images.githubusercontent.com/2464966/92631584-d7c01d80-f2d1-11ea-9b40-33d73db96a53.png">
Reviewed By: hramos
Differential Revision: D24684845
Pulled By: cpojer
fbshipit-source-id: 900cbe3bf9398a6fd4a773d552899a001bf5146b
Summary:
Bump Gradle Wrapper to 6.7, to keep tooling on edge. Here are the highlights of this release:
- File system watching is ready for production use
- Declare the version of Java your build requires
- Java 15 support
## Changelog
[Android] [Changed] - Bump Gradle Wrapper to 6.7
Pull Request resolved: https://github.com/facebook/react-native/pull/30200
Test Plan: RNTester builds and runs as expected. Also my apps.
Reviewed By: cpojer
Differential Revision: D24560233
Pulled By: fkgozali
fbshipit-source-id: 0d94b4527b2ee5b28b22478128c25761929fbdc7
Summary:
Android Studio 4.1 release with Android Gradle Plugin 4.1.0, thus I expect developers will update to newer version and expect React Native support. Thus release include many fixes and improvements, see[release notes](https://developer.android.com/studio/releases/gradle-plugin#4-1-0), but most importantly Google released it's API documentation at https://developer.android.com/reference/tools/gradle-api. We lacked the API documentation to develop proper React Gradle Plugin.
## Changelog
[Android] [Changed] - bump Android Gradle Plugin to 4.1.0
Pull Request resolved: https://github.com/facebook/react-native/pull/30201
Test Plan: RNTester builds and runs as expected, also my apps.
Reviewed By: cpojer
Differential Revision: D24560213
Pulled By: fkgozali
fbshipit-source-id: 9cf1e2373f278885b35b4f9176c7ad736ec50f6b
Summary:
Pass the ReactAndroid project build directory as a variable to the ndk build so it can be used instead of assuming that the build directory is under ReactAndroid/build.
## Changelog
[Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/30222
Test Plan: Tested in an app with a custom build directory
Reviewed By: yungsters
Differential Revision: D24560643
Pulled By: fkgozali
fbshipit-source-id: cc65a70582f546ca2e2ca9fb6a2ff03ea70ca9d8
Summary:
The recursive copy statement fixed here behaved differently in MacOS vs Linus (CI), because of the missing dot (.)
The trailing slash on the source directory behaves differently on Mac (BSD) than Linux (GNU):
> If the source_file ends in a /, the contents of the directory are copied rather than the directory itself.
This should fix the CI failure: https://app.circleci.com/pipelines/github/facebook/react-native/6847/workflows/36d59aab-bc4a-4d21-9ce1-a8348e71aea3/jobs/173681
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24560543
fbshipit-source-id: c3ab2c28616b717891bcf5d2ad762340cfb97e3d
Summary:
## Context
We currently run ESLint using `flow-node`. This is a very recent change that was introduced in these two diffs:
- Switch VSCode ESLint plugin using flow-node: D24454702.
- Switch all ESLint scripts to use flow-node: D24379783 (https://github.com/facebook/react-native/commit/ad5802cf916c1cbe3e142385a29810a0d7205c6c).
## Problem
Because `react-native/eslint-plugin-codegen` (written in vanilla JavaScript) requires two files from `react-native-codegen` (written with Flow typings), we force all requires executed while initializing ESLint to compile out Flow types. Issues:
- In the grand scheme of things, this is such a tiny and isolated problem. It shouldn't be the reason why we switch over to using flow node. That's a larger decision that should be discussed outside of this diff.
- On VSCode cold start, in D24454702, I measured that using flow-node adds approximately 320ms to JavaScript file lint time. So, this is just slow.
## Solution
- Switch ESLint back to using regular node:
- Revert the changes to VSCode's ESLint plugin: D24454702
- Revert the changes to the internal ESLint scripts: D24379783 (https://github.com/facebook/react-native/commit/ad5802cf916c1cbe3e142385a29810a0d7205c6c).
- Inside the ESLint plugin, register a temporary require hook to remove Flow types from the NativeModule spec parser, before we require it. We de-register this hook after the requires finish.
## Implementation Notes:
- The `with-babel-register/` is a fork of `babel/register`, except I simplified the implementation based on the assumption that we're using it literally to only compile `react-native-codegen`.
- `with-babel-register/` uses a disk cache, so we only call transformSync when a the input file (1) hasn't been transformed before, or (2) the cache entry was created before the file was last modified.
- I ported over the source-map logic, so that when the NativeModule spec parser throws non-parsing errors, we get the correct stack trace. **Note:** I'm not sure if the source maps will work if there's a babel/register earlier during initialization. However, I don't think this will pose an actual problem, since we don't use a babel/register hook earlier. So, I think we should punt on this investigation.
## Alternative: Why aren't we using babel/register?
Every time you call babel/register, it replaces the last registered hook. We don't want the ESLint plugin to be changing any existing require hooks that people have set up. Abandoned diff with babel/register: D24519349.
Changelog: [Internal]
Reviewed By: cpojer
Differential Revision: D24551549
fbshipit-source-id: bbd7c5be44f74c0e9adbb20fe86e09802410b123
Summary:
This does a few things:
* Remove USE_CODEGEN flag so that TurboModule is enabled by default for RNTester
* Use the codegen output for Java/JNI spec files
* Remove the checked in com.facebook.fbreact.specs Java/JNI files
Changelog: [Changed][Android] RNTester now enables TurboModule by default using codegen.
Reviewed By: RSNara
Differential Revision: D24382083
fbshipit-source-id: 87e3e0581bac3287ef01c1a0deb070c1d7d40f2d
Summary:
The Gradle codegen integration requires the JS CLI to be first built via `yarn run build`. This commit puts that logic in a `build.sh` script, then defines a Gradle task to build it.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24556992
fbshipit-source-id: 7092de7c1126edc157b122f4b2243e55f7188846
Summary:
This fixed a bug in the JS Java spec generator. Optional methods were still marked `abstract` before this fix. Instead it should be a normal method with potentially falsy return value.
The JavaPoet version does this correctly already, but there was a minor typo with void return type vs optional.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24524432
fbshipit-source-id: 57a248580a78bc255f34d0492ebe3a4691e66667
Summary:
This defines a separate codegen entrypoint for the entire react-native repo, picking up all JS files under Libraries/ subdir. Buck can then build the codegen library targets. This is a pre-req for removing the checked in Java spec files for NativeModules.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24518569
fbshipit-source-id: 2ece53c7274698e2431a00e590fad213e3a0bece
Summary:
We don't currently support object spreads in `ObjectTypeAnnotation`s. This diff adds an explicit error for the case in the parser, so that when people use object spreads in ObjectTypeAnnotations, they get feedback from the linter rule and parser.
Previously, the Linter would crash, and the parser would fail, but the error wouldn't be immediately obvious.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24543650
fbshipit-source-id: 76f389c72f858ee6281c5aff5ce797f3be685096
Summary:
Ensure the react-native-codegen package is built before the codegen is invoked during RNTester's pod install.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24515852
fbshipit-source-id: eeb1237f601d83a79a5274261c374bb5fc5689eb
Summary:
This moves the test script that generates **all outputs using all generators** to a dedicated "generate-all" CLI. This allows us to use it via Buck, at FB and OSS.
Also renamed the target to be more specific: "rn_codegen" => "generate_all_from_schema"
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24513995
fbshipit-source-id: 8435d3d065718eb1309c1c61fe28fb592787311a
Summary:
Our NativeModule spec parser parses the TurboModuleRegistry.get<Spec>(...) calls to figure out what the name of the NativeModule is. The parser assumes the argument is a string literal. Therefore, we should lint to validate this case.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24500412
fbshipit-source-id: 5aa5e9255db5a2e0cd86d6dd96e6787caa673fc4
Summary:
TurboModule specs should have exactly one TurboModuleRegistry.get or TurboModuleRegistry.getEnforcing call. When a JS file contains more than one call into TurboModuleRegistry, this lint rule will report an error on all calls.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24499286
fbshipit-source-id: 2c47185165a2a81c4b7b7ad9a7b8458e9aa8c018
Summary:
This diff guts the React Native Modules ESLint rule, and makes it instead call into the NativeModule spec parser. After calling into the parser, the lint rule loops over all collected errors, and reports them.
## Benefits
- There is now one source of truth of what is a "correct" NativeModule spec: The NativeModule spec parser.
- Every change we make to the NativeModule spec parser will reflect in the lint rule. We have a number of changes planned for the NativeModule parser that will change what it means for a NativeModule spec to be correct. These changes now won't have to be duplicated in the ESLint rule.
- The linter will *never* show any false positive errors. If there's an error in the linter, you *need* to fix it. Otherwise, the codegen *will* fail. This is huge. Previously, people were used to ignoring the linter, because it over-reported errors. This behavior won't slide after this stack lands.
NOTE: This will run the NativeModules parser on all our NativeModule specs. We may have to check the specs, or the parser. Therefore, this could take some time to land.
## How does the lint rule work now?
In every JavaScript file, the ESLint rule looks for `CallExpression` AST Nodes. Once it detects a `CallExpression` that corresponds to a `TurboModuleRegistry.get` or `TurboModuleRegistry.getEnforcing` it:
1. Marks the file as a TurboModule spec
2. Validates the `CallExpression` to verify that it is called with the <Spec> type parameters (i.e: like this: TurboModuleRegistry.get<Spec>(...)).
When we're done the visition for the JavaScript file (i.e: in `Program:exit`), if the JavaScript file was a TurboModule spec:
1. Report a lint error if the filename doesn't start with Native.
2. We parse the source using flow-parser, and run the NativeModule spec parser on it. We capture all ParserErrors and report them via ESLint.
## When can I start using this lint rule in VSCode?
I made the ESLint VSCode plugin use flow-node in D24454702. It'll take 3-4 weeks for this change to be shipped to everyone's VSCode. After the update, the linter will automatically start working in VSCode. Until then, we'll only get feedback on Sandcastle/Landcastle for lint rule violations.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24379783
fbshipit-source-id: 222778d8a84d7010eb7b3ad71b34a7fe1f52e509
Summary:
Introduced a helper macro `rn_codegen_cli()` that defines ":write_to_json" and ":rn_codegen" targets differently based on the environment. When run at FB, it uses FB-specific setup. When run in OSS as a standalone repo, we use `yarn install` and `yarn run build` directly, then use `node` to run the output CLI.
This way, the same target can be used in both environments on other Buck targets.
Motivation: we need this to define rn_codegen_modules() to use codegen to produce Java TurboModule specs, that can be built by CircleCI (we build ReactAndroid via Buck as well). That way we can finally removed the checked-in .java spec files.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24442468
fbshipit-source-id: b1e5fce275100cfe3a1b3ae6d61c1c6d4b25651b
Summary:
Added a few FB vs OSS polyfills:
* react_native_root_target() to refer to the root FB react-native-github/ dir or repo dir in OSS
* react_native_xplat_synced_target() for anything xplat
* a few others
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D24437245
fbshipit-source-id: ee290a87a98a8e9be67b102a96f2faac2a2cb92b
Summary:
Removes the generated FBReactNativeSpec files from source control.
## Generating FBReactNativeSpec files
The files will be generated automatically by CocoaPods when the `RNTesterPods` Xcode workspace is generated:
```
cd packages/rn-tester
pod install
```
The spec files can be re-generated by invoking the script directly:
```
./scripts/generate-native-modules-specs.sh
```
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24261167
fbshipit-source-id: acb7ac856e5e519932e4f587f79e24f49cd84a91
Summary:
Just published react-native-codegen to npm. This diff bumps the version in package.json
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24433252
fbshipit-source-id: 35327b11ca4db270f207b6f778dabf86dd7dcb4c
Summary:
This change adds a testID to each item in the RNTester list. This helps Appium find items in the list for automated tests. The change was added in react-native-windows as part of end-to-end test infrastructure changes. See https://github.com/microsoft/react-native-windows/pull/5555
We'd like to remove this forked file, upstreaming this change will enable us to do that.
## 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
-->
[General] [Changed] - add testID to items in RNTester test list, helps test automation tools find the items
Pull Request resolved: https://github.com/facebook/react-native/pull/30138
Test Plan: Change is currently running in react-native-windows CI loop.
Reviewed By: cpojer
Differential Revision: D24434352
Pulled By: appden
fbshipit-source-id: 998916d8fe4e4e4cd6ac764baabb9fd5f2e312c7
Summary:
This diff updates the minsdkversion of RN OSS template to API level 21.
Changelog: [Android][Deprecated] Deprecate support of Android API levels 19 and 20. The new minSDK version will be 21+ moving forward.
Reviewed By: fkgozali
Differential Revision: D24379607
fbshipit-source-id: 6801cdcd363065807cdc11006bd94217f914fac7
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:
Move FBReactNativeSpec codegen invocation to shared `react_native_pods.rb` script and trigger codegen to run as part of `pod install` in both RNTester as well as React Native for iOS projects.
These files need to be generated before CocoaPods generates the Pods project, so the codegen is invoked as part of a `pre_install` hook during `pod install`.
The codegen hook can now take optional paths to allow it to run within different contexts (as part of a `react-native` repo checkout with access to the codegen source, or as part of a React Native iOS project that depends on the `react-native-codegen` npm package).
## Motivation
The FBReactNativeSpec ObjC++ source files (FBReactNativeSpec.h and FBReactNativeSpec-generated.mm) can be generated on demand from the native module specs in `Libraries/` using `react-native-codegen`. They can therefore be removed from the repository, but before we do so, we must ensure they get generated when a React Native iOS workspace is created or updated.
Invoking the codegen as part of the `pod install` step that creates a React Native iOS Xcode workspace ensures the specs are available in the following scenarios:
* Whenever a new React Native iOS project is created. The `react-native init` command invokes `pod install`.
* Whenever a React Native iOS project is upgraded. The `react-native upgrade` command invokes `pod install` as well.
* For contributors to the open source project running the RNTester application, the codegen will be invoked when the RNTester workspace is generated by CocoaPods using `pod install` in `packages/rn-tester`.
In any other case, the codegen can still be invoked directly via `scripts/generate-native-modules-specs.sh`.
> **Note:**
> The codegen will only process native modules in React Native's own Libraries directory.
Changelog:
[iOS][Changed] - Generate FBReactNativeSpec ObjC++ source files using CocoaPods.
Reviewed By: fkgozali
Differential Revision: D24348111
fbshipit-source-id: d62ae5c6f8ce6358bf96a2801c3cdb3d94dd868d
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
Ramanpreet Nara
Christoph Nakazawa
Kevin Gozali
Moti Zilberman
Mike Grabowski
Héctor Ramos
Dulmandakh
Janic Duplessis
Rick Hanlon
Keith Melmon
Joshua Gross
