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:
Fixes a NPE in debug mode. This will only impact developers who have explicitly turned this debug flag on, so it's a very low-pri fix.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D24410825
fbshipit-source-id: 08c8a0c6d0e0fb7c132725ad6af9460b91a7edf3
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
Summary:
In our Codegen generators, we were using `codegenModuleName` to refer to the name of the spec file. Calling this `hasteModuleName` makes it more clear what this name refers to (i.e: the name of the spec file). This diff performs that rename.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24386282
fbshipit-source-id: fe2beda9a0abf63a5cf88fa0664f83416c9f1aa2
Summary:
The previous implementation always replaced the prop set on every props update coming from Animated. Now, we merge the new set of props with the previous one.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D24370751
fbshipit-source-id: 779272d47c776cc42071d3c93d06443b6c96a877
Summary:
The specific file filtering in the CLI only covers the case where the input is a directory. We should filter when files are provided as well.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D24399225
fbshipit-source-id: 186e39c157faf90bdd825ec5c5860017d49e9404
Summary:
On Hermes, RN can directly use the Promise from global w/o the need of polyfilling it.
PromiseRejectionTrackingOptions are extracted to its own file so it can be shared by
both codepaths and preserve the behaviors that it's only imported on dev.
Some zero-overhead type gymnastics are used to flow-type it properly.
Changelog:
[General] - made promise polyfill conditionalized on Hermes
Reviewed By: cpojer
Differential Revision: D24068716
fbshipit-source-id: 3e0b1675493908324f27cc5b7300d8cc42a03acc
Summary:
In Chrome, there's a garbage can icon in the memory profiler page that you can
click to force a garbage collection.
Hermes was previously not responding to that button. Add support for this inspector
message type.
The collection it starts is fully synchronous and will block JS from running. It typically
completes quite fast for small heaps, and about 1 second for heaps over 100 MB big.
Changelog:
[Internal][Added] Add support for garbage collection during heap profiling with Hermes
Reviewed By: neildhar
Differential Revision: D24349262
fbshipit-source-id: fe62b8df4d2b67ab3930e5d57f94478b2a88a549
Summary:
So that it's easier for C++ targets to depend on libglog.so for debugging purpose.
Changelog: [Internal]
Differential Revision: D24382033
fbshipit-source-id: 00ad6b2365d571583d6d1aaa40fac2c96974abf1
Summary:
The GenerateModuleJavaSpec.js mistakenly treated nullable getConstants() properties as required, such that the Java spec will throw an exception when the properties are missing. This fixed it.
Note that the JavaPoet-based generator got this correct already.
Changelog: [Internal]
Differential Revision: D24381941
fbshipit-source-id: c95d2181c66443e2191318f09b6454a5296009e4
Summary:
Fixed URL of ChainReactConf website on the ECOSYSTEM.md
## 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
-->
[Internal] [Fixed] - Fix URL of ChainReactConf Website
Pull Request resolved: https://github.com/facebook/react-native/pull/30199
Test Plan: URL leads to the ChainReactConf website
Reviewed By: makovkastar
Differential Revision: D24386708
Pulled By: cpojer
fbshipit-source-id: 27a48e84547ef3bc067845b3c302dd57decc34b2
Summary:
#changelog: [internal]
When I built ThreadStorage I didn't know about existence of `thread_local` keyword. Because it achieves the same goal, using built in c++ features is preferred over building our own.
Reviewed By: JoshuaGross, shergin
Differential Revision: D24380680
fbshipit-source-id: e961fc34c6d3f085fc9b918b20bb4827de0d5624
Summary:
The NativeModules spec parser uses `moduleName` to refer to the name of the NativeModule spec. This is confusing, because the NativeModules spec also has a `moduleNames` array, which refers to names of the NativeModules that get required in the spec.
This diff renames `moduleName` to `hasteModuleName` within the NativeModule spec parser.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24386279
fbshipit-source-id: 8e4eb8dfc647241bf2bdae54dc8d9ab0122f49f9
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:
Some existing NativeModules have either Android or IOS suffix to denote the exclusive intent for that platform. For now, note this in the codegen schema output, so that the generator can skip irrelevant modules. Long term, each Flow type for module Spec should denote the intended/excluded platforms directly.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24370568
fbshipit-source-id: 8f725bdb39107d73c1aba0689db7f47ed7c374b0
Summary:
The manual lookup logic was needed before we properly parse the module names from the spec js files. This is no longer necessary after the commit stack starting with https://github.com/facebook/react-native/commit/3a75b376cc3c44f9693d99b33046cf76d6fafa89
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D24370567
fbshipit-source-id: fc307d93cdda240a977e37dfe602502bd3f7c2a4
Summary:
Fabric has a feature that preallocates views before mounting even need them. We never tested the impact of this feature thought. This diff adds a way to enable/disable it and run an experiment.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D24355612
fbshipit-source-id: fefd653e57232044cd7b28b160e12a4ef85dbb8b
Summary:
Changelog:
[General][Added] - Adds the Hermes runtime bytecode version number to the JS bundle requestURL. This allows Metro with Bytecode to work with prebuilt binaries.
Reviewed By: cpojer
Differential Revision: D24327852
fbshipit-source-id: e8ee8db4f9b01f0500ab9dd851b5818c4adf3303
Summary:
Adding support to the pointData to Android React Native
Changelog: [internal]
Reviewed By: swillard13
Differential Revision: D24256346
fbshipit-source-id: b970f771047cff580d9ebe7d6e2ad737394d6416
Summary:
NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack).
## Changes
1. NativeModule generators now use the new RN Codegen NativeModule schema.
2. Tangential: We're no longer removing the `Native` prefix from the NativeModule filename, assuming that that's the module name (problem: wrong), and prefixing again with Native (problem: redundant), when we're generating code. Instead, like the internal codegen, we simply pass the filename to the Codegen output. Our linters enforce that all NativeModule specs are contained with files that start off with `Native`.
3. `GenerateModuleCpp` was fixed to use the actual module name as opposed to the spec name. I added a comment inline.
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: PeteTheHeat
Differential Revision: D24236405
fbshipit-source-id: ccd6b5674d252c350be0ec8a86e7ca5f2f614778
Summary:
NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack).
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: PeteTheHeat
Differential Revision: D24236504
fbshipit-source-id: 0ca70101a855fb713fa15ed63849b138eb73dc6c
Summary:
NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack).
## Changes
Previously, the "Module" schema could either contain a `components` property, or a `nativeModules` property. The existence of the `components` property was used to determine (1) if the generators would run and (2) filter schemas on which the generators would run. Now, we simply check whether the type of the "Module" schema is `Component`.
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: PeteTheHeat
Differential Revision: D24236508
fbshipit-source-id: 68cb3f25178b6757c9a4aee767bb6173db4932a6
Summary:
NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack).
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: PeteTheHeat
Differential Revision: D24236507
fbshipit-source-id: 2ffa0414db731a6ee844a2d1a5b07dc32bc763cb
Summary:
NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack).
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: PeteTheHeat
Differential Revision: D24236502
fbshipit-source-id: 288c6d9588bde177732fe8165d3374eeacad999d
Summary:
NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack).
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: PeteTheHeat
Differential Revision: D24236509
fbshipit-source-id: 1b603e8728d7be1e8bdede5878f57d6556b5c52f
Summary:
NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack).
## Changes
1. Update the RN Codegen Module Parser
2. Update all RN Codegen Module Parser Jest tests & snapshots.
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: PeteTheHeat
Differential Revision: D24236505
fbshipit-source-id: e24a39b4837c75a90fb4c957c56dfcf789511cc9
Summary:
NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack).
## Changes
1. Update the RN Codegen Component Parser
2. Update all RN Codegen Component Parser snapshots.
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: PeteTheHeat
Differential Revision: D24236503
fbshipit-source-id: 975d97dd29bb5ca08e5de96e7814290c3dc4357b
Summary:
NOTE: Flow and Jest won't pass on this diff. Sandcastle, should, however, be green on D24236405 (i.e: the tip of this stack).
## Description
The Codegen deals with "Modules". Hence:
```
type SchemaType = {
modules: {
[moduleName]: ...
}
};
```
Each "Module" has a name, and represents a file. The `moduleName` is the base name of the file. This file can contain a component specification or a NativeModule specification. Hence:
```
type SchemaType = {
modules: {
[moduleName]: ComponentSchema | NativeModuleSchema
}
};
```
The `ComponentSchema` can contain specifications for many different components. Hence:
```
type ComponentSchema = {
type: 'Component'
components: {
[componentName]: ComponentShape
}
}
```
The `NativeModuleSchema` contains
1. Type aliases (no surprises/nothing new).
2. One Flow interface that extends `TurboModule`.
3. Potentially many different NativeModule requires (for now) via `TurboModuleRegistry.get(Enforcing)?<specName>('moduleName')`.
Hence, the shape looks like:
```
type NativeModuleSchema = {
type: 'NativeModule',
aliases: NativeModuleAliasMap, // nothing new
spec: NativeModuleSpec,
moduleNames: $ReadOnlyArray<string>
}
type NativeModuleSpec = {
properties: $ReadOnlyArray<...>,
}
```
## Major Notes
1. We now parse the NativeModule requires (TurboModuleRegistry.get(Enforcing)?<Spec> calls) and record them in the schema.
2. A Codegen "Module" can contain either a Component schema, or a NativeModule schema, but **not** both.
## Snapshot Updates
The changes to the schema are visible in the snapshots updated in D24236505.
Changelog: [Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: fkgozali
Differential Revision: D24236510
fbshipit-source-id: bd344d67136418725d840e7332fd2f6957326bb4
Summary:
changelog: [internal]
Prevents 2 type converions:
1. int <-> size_t
2. int <-> int32_t
# Why is using size_t better when working with indexes.
## 1. Type conversion isn't for free.
Take this example
```
size_t calculate(int number) {
return number + 1;
}
```
It generates following assembly (generated with armv8-a clang 10.0.0):
```
calculate(int): // calculate(int)
sub sp, sp, #16 // =16
str w0, [sp, #12]
ldr w8, [sp, #12]
add w9, w8, #1 // =1
mov w8, w9
sxtw x0, w8
add sp, sp, #16 // =16
ret
```
That's 9 instructions.
If we get rid of type conversion:
```
size_t calculate(size_t number) {
return number + 1;
}
```
Assembly (generated with armv8-a clang 10.0.0):
```
calculate(unsigned long): // calculate(unsigned long)
sub sp, sp, #16 // =16
str x0, [sp, #8]
ldr x8, [sp, #8]
add x0, x8, #1 // =1
add sp, sp, #16 // =16
ret
```
Compiler now produces only 7 instructions.
## Semantics
When using int for indexing, the type doesn't say much. By using `size_t`, just by looking at the type, it gives the reader more information about where it is coming from.
Reviewed By: JoshuaGross
Differential Revision: D24332248
fbshipit-source-id: 87ef982829ec14906ed9e002ea2e875fda4a0cd8
Summary:
In D24324247 (https://github.com/facebook/react-native/commit/56c363e39af6488904cbfd2046314c45babeb0f4), I split NativeLinking into NativeLinkingManager and NativeIntentAndroid. There was this line in NativeLinking.js, that I didn't migrate correctly:
```
export default ((Platform.OS === 'android'
? TurboModuleRegistry.getEnforcing<Spec>('IntentAndroid')
: TurboModuleRegistry.getEnforcing<Spec>('LinkingManager')): Spec);
```
I separated this conditional statement into two others:
```
export default TurboModuleRegistry.getEnforcing<Spec>('IntentAndroid');
export default TurboModuleRegistry.getEnforcing<Spec>('LinkingManager');
```
The problem here is that now on iOS, we're hard requiring IntentAndroid, and on Android, we're hard requiring LinkingManager. Understandably, this started throwing errors in our e2e infra. This diff fixes this problem by:
1. Changing the relevant `getEnforcing` calls into `get` calls.
2. Wrapping all usages of NativeIntentAndroid, and NativeLinkingManager, which are already guarded by `Platform.OS` checks, by a nullthrows. This should satisfy flow. **Note:** NativeIntentAndroid is only used on Android, where it must be available. Similarly, NativeLinkingManager is only used on iOS, where it must be available.
Changelog: [Internal]
build-break
overriding_review_checks_triggers_an_audit_and_retroactive_review
Oncall Short Name: fbandroid_sheriff
Differential Revision: D24338558
fbshipit-source-id: b0d22cba77e67837834269deaa317dc73d2457dc
Summary:
We will need it soon.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D24290775
fbshipit-source-id: a312e537a3c3954e709a10c8792b3462b574054a
Summary:
RCTSurfaceTouchHandler is not a thread-safe object and must be used (and initialized) on the main thread. Therefore we need to move the initialization to `view` method which is guaranteed to be called on the main thread.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D24290776
fbshipit-source-id: fc1f2f157599aff6fca053451f89bf7cca3c812a
Summary:
Changelog: [internal]
Fabric uses view commands instead of setNativeProps. This diff removes what's left of setNativeProps from the core.
Reviewed By: JoshuaGross
Differential Revision: D24309999
fbshipit-source-id: 70e54f0a984f8c36f77ba2cd59f59fc6923bc832
Summary:
Although the interface for both NativeModules is the same, we'd like to enforce 1 `TurboModuleRegistry.get` call per NativeModule spec file. Therefore this diff splits the one spec into two.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24325260
fbshipit-source-id: f18718e4235b7b8ccbfc44a7e48571ecf483a36c
Summary:
The iOS and Android NativeModules are very different. It's better to split the two interfaces, than to have one merged interface.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D24324247
fbshipit-source-id: 097273829ffc719eff006ed2dde55f0dd6bd7d95