Summary:
This PR fixes a few issues with the Appearance API (as noted here https://github.com/facebook/react-native/issues/28823).
1. For the Appearance API to work correctly on Android you need to call `AppearanceModule.onConfigurationChanged` when the current Activity goes through a configuration change. This was being called in the RNTester app but not in `ReactActivity` so it meant the Appearance API wouldn't work for Android in newly generated RN projects (or ones upgraded to the latest version of RN).
2. The Appearance API wasn't working correctly for brownfield scenarios on Android. It's possible to force an app light or dark natively on Android by calling `AppCompatDelegate.setDefaultNightMode()`. The Appearance API wasn't picking up changes from this function because it was using the Application context instead of the current Activity context.
3. The Appearance API wasn't working correctly for brownfield scenarios on iOS. Just like on Android its possible to force an app light or dark natively by setting `window.overrideUserInterfaceStyle`. The Appearance API didn't work with this override because we were overwriting `_currentColorScheme` back to default as soon as we set it.
## 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
-->
### Fixed
https://github.com/facebook/react-native/issues/28823
* [Android] [Fixed] - Appearance API now works on Android
* [Android] [Fixed] - Appearance API now works correctly when calling `AppCompatDelegate.setDefaultNightMode()`
* [iOS] [Fixed] - Appearance API now works correctly when setting `window.overrideUserInterfaceStyle`
Pull Request resolved: https://github.com/facebook/react-native/pull/29106
Test Plan: Ran RNTester on iOS and Android and verified the Appearance examples still worked [correctly.](url)
Reviewed By: hramos
Differential Revision: D31284331
Pulled By: sota000
fbshipit-source-id: 45bbe33983e506eb177d596d33ddf15f846708fd
Summary:
allow-large-files
RN Tester is using an old version of Flipper. This will help testing regressions in the latest version (which is installed when starting a new project). This also fixes an issue where libevent is incompatible between the one in flipper and when using hermes on iOS. To fix it I changed to use the version published on cocoapods instead of using a local podspec (see https://github.com/facebook/flipper/issues/1916).
[General] [Changed] - Update flipper
Pull Request resolved: https://github.com/facebook/react-native/pull/31010
Test Plan:
- Tested that RN tester builds and flipper works with hermes enabled / disabled and fabric on iOS
- Tested that RN tester builds and flipper works on Android
Reviewed By: fkgozali
Differential Revision: D26592317
Pulled By: PeteTheHeat
fbshipit-source-id: 2cd278c7a51b1859dab0465846b061221f07d3f6
Summary:
This addesses a few issues I noticed while migrating my app to the new build-time codegen on iOS.
1. I noticed random failures because of codegen on iOS. This is mostly due to the fact the codegen output files are not specified in the xcode script. The only reason it works relatively fine currently is because the codegen output is inside the input files directory. This has the side effect of causing files to be regenerated every build, then causes all core modules to be recompiled which adds up a significant amount of time to rebuilds. To fix this I added the generated files to the script phase output and moved the FBReactNativeSpec dir outside of the codegen source (Libraries). I moved it to the React directory as this seemed to make sense and is where a lot of iOS files are as well as the core modules. Note this might require internal changes. This removes the circular dependency between our build phase input and output so consecutive builds can be cached properly.
2. Add `set -o pipefail` to the xcode script, this helped propagate errors properly to xcode because of the `| tee` pipe so it fails at the script phase and not later with a header not found error. Also add `2>&1` to pipe stderr to stdout so errors are also captured in the log file.
3. Add the `-l` flag to the bash invocation to help finding the yarn binary. With my setup yarn is added to the system PATH in my user .profile. Adding this file will cause bash to source the user environment which xcode scripts does not by default. I think this will help with most setups.
4. If yarn is not found the `command -v yarn` would make the script exit without any output because of the -e flag. I made a change to ignore the return code and check later if YARN_BINARY is set and have an explicit error message if not.
[iOS] [Fixed] - Make codegen more reliable on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/30792
Test Plan:
Tested various project states to make sure the build always succeeds in RN tester:
- Simulate fresh clone, remove all ignored files, install pods, build
- Build, delete FBReactNativeSpec generated files, build again
- Build, build again, make sure FBReactNativeSpec is cached and not rebuilt
- Make the script fail and check that xcode shows the script error logs properly
Note: Did not test fabric
Reviewed By: fkgozali
Differential Revision: D26104213
Pulled By: hramos
fbshipit-source-id: e18d9a0b9ada7c0c2e608d29ffe88087f04605b4
Summary:
The codegen helper script, `generate-specs.sh`, is being used to generate code for the FBReactNativeSpec and React-Fabric/rncore pods. The script now supports overriding several defaults by setting the following environment variables:
- SRCS_DIR: Path to JavaScript sources, defaults to $RN_DIR/Libraries/
- LIBRARY_NAME: Defaults to FBReactNativeSpec
- MODULES_OUTPUT_DIR: Defaults to Libraries/$LIBRARY_NAME/$LIBRARY_NAME
- COMPONENTS_LIBRARY_NAME: Defaults to rncore
- COMPONENTS_OUTPUT_DIR: Defaults to ReactCommon/react/renderer/components/$COMPONENTS_LIBRARY_NAME
The CocoaPods codegen integration has been updated to take advantage of these.
**Example CocoaPods usage:**
```
# packages/rn-tester/NativeModuleExample/RNTesterSpecs.podspec
Pod::Spec.new do |s|
s.name = "RNTesterSpec"
# ...
use_react_native_codegen!(s, { :srcs_dir => __dir__, :modules_output_dir => __dir__ })
end
```
Changelog:
[Internal]
Reviewed By: fkgozali
Differential Revision: D25738466
fbshipit-source-id: c68f5a3cd0996283a7af287e992e2f973024f44c
Summary:
Consolidate CocoaPods codegen scripts under a single `use_react_native_codegen!` method in `react_native_pods.rb`.
This is the first step towards making the codegen scripts library-agnostic. There are still a handful of hardcoded assumptions in place (e.g. the output directory structure, the use of a separate directory for components), but with some work one would be able to add codegen support to arbitrary CocoaPods podspecs.
The codegen script no longer takes a CODEGEN_PATH argument, and will instead attempt to use the local react-native-codegen package if available, and fallback to using the node_modules/react-native-codegen package if not.
## Usage
The `use_react_native_codegen!` method has two arguments:
- `spec`, a pod [Specification](https://www.rubydoc.info/github/CocoaPods/Core/Pod/Specification) object.
- `options`, an optional object. Supported keys:
- `:srcs_dir`, the path to your JavaScript sources. Your native module or component specs should be located somewhere in this directory.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D25728053
fbshipit-source-id: feec587b656d5b220598ce6196ea6bb34a9580a9
Summary:
Original PR contents:
This pull request updates the Podspecs and associated build scripts, and some source files so they build on OSS. RNTester now compiles with `fabric_enabled` again.
The following changes have been made:
* Various spots that were pointing to the old `ReactCommon/fabric` location have now been updated to `ReactCommon/react/renderer`
* Files that were attempting to use internal FB header `FBRCTFabricComponentsPlugins.h` were changed to use `RCTFabricComponentsPlugins.h`
* `RCTFabricComponentsPlugins` in OSS was updated to include the `Image` fabric component (thanks tsapeta)
* Replaced old `generate-rncore.sh` build script with new `generate-rncore.js` script which does not require `flow-node` and uses the `react-native-codegen` API directly, so there is no longer any need for an interim `schema-rncore.json` file.
* Updated Yoga podspec which wasn't fully synced with changes from the main Yoga repo
* Updated Fabric podspec with additional needed subspecs
Additions to PR by hramos:
* Replaced use of generate-rncore scripts with the original generate-native-modules-specs.sh script, which is now generate-specs.sh and supports both codegen for Native Modules and Components now (TurboModules/Fabric).
* Codegen now runs at build time as part of the Xcode build pipeline instead of as part of `pod install`. The build script is injected by the FBReactNativeSpec pod, as the pod is part of both Fabric and non-Fabric builds.
[General] [Fixed] - RNTester compiles with `fabric_enabled` again
Pull Request resolved: https://github.com/facebook/react-native/pull/29810
Test Plan:
RNTester now compiles and runs in the simulator again when `fabric_enabled` is set to `true`.
```
cd xplat/js/react-native-github/packages/rn-tester
USE_FABRIC=1 pod install
open RNTesterPods.xcworkspace
```
Reviewed By: fkgozali
Differential Revision: D24058507
Pulled By: hramos
fbshipit-source-id: 8b2ea3694e6cb9aa23f83f087e2995fd4320e2bb
Summary:
Move the codegen invocation out of Podfiles and into the FBReactNativeSpec Pod itself. With this change, developers do not need to modify their existing project's Podfiles, and yet the codegen will be integrated into their projects automatically by way of the FBReactNativeSpec Pod.
This is accomplished in part by injecting a script build phase into the Pods Xcode project that is generated by CocoaPods. The build phase will save the output of the codegen script to a log in the derived files directory. The codegen will be executed if the codegen log file is not present, or if the contents of the Libraries directory has changed.
The codegen will thus be invoked in these situations:
**RNTester:**
* When `packages/rn-tester/RNTesterPods.xcworkspace` is built, if the codegen output logfile is not present or if the input files have changed.
**OSS React Native apps:**
* When `ios/AwesomeProject.xcworkspace` is built, if the codegen output file is not present or if the input files have changed. Normally, this should not happen, as we do not expect folks to update the contents of `node_modules/react-native/Libraries`.
Pull Request resolved: https://github.com/facebook/react-native/pull/30449
Changelog: [Internal] - Moved codegen invocation out of Podfile and into FBReactNativeSpec Pod
Reviewed By: fkgozali
Differential Revision: D25138896
fbshipit-source-id: 4779f822459cea2c30fd544eee19a49e8d80153d
Summary:
Use pre-built react-native-codegen library from npm in the iOS app template.
Built react-native-codegen from source when used with RNTester.
Published react-native-codegen@0.0.6.
Changelog:
[iOS][Added] - Use react-native-codegen in iOS app template
[Internal] - Bump react-native-codegen: 0.0.6
Reviewed By: fkgozali
Differential Revision: D25128036
fbshipit-source-id: f294c23b9b911aae6f404edc01b62426fb578477
Summary:
Add the `react-native-codegen` source to the `react-native` npm package.
Instead of using `react-native-codegen` from npm, the iOS app template will now build the package from source. Doing so removes the need to carefully time `react-native-codegen` npm releases to oss `react-native` releases, as the codegen and the oss release will be cut at the same time.
Changelog: [Internal] - Removed react-native-codegen dependency from iOS app template
Reviewed By: TheSavior
Differential Revision: D24904655
fbshipit-source-id: a07932bc748e2afb9359de584181bcb9dd0810ea
Summary:
When running yarn install from the codegen directory it will reinstall all dependencies for the react-native workspace inside the react-native package. In my case this caused issues with metro because it would now have 2 copies of it (node_modules/metro and node_modules/react-native/node_modules/metro).
To avoid this copy the react-native-codegen source in a temporary directory and yarn install from there, then copy the built files back.
## Changelog
[Internal] - Build rn-codegen in a temporary directory
Pull Request resolved: https://github.com/facebook/react-native/pull/30292
Test Plan: Tested the script in an app with codegen enabled. Fresh install with rn-codegen not built, made sure no extra modules are installed under node_modules/react-native/node_modules.
Reviewed By: yungsters
Differential Revision: D24893216
Pulled By: fkgozali
fbshipit-source-id: 2c372b755632ea6f50ad5d4562248612b349a9a6
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
Brent Kelly
Lorenzo Sciandra
Mike Grabowski
Janic Duplessis
Héctor Ramos
empyrical
Luke Walczak
Kevin Gozali
Dulmandakh
Ramanpreet Nara
Rick Hanlon
Keith Melmon
Joshua Gross
