Summary:
Fixes a potential crash was introduced by https://github.com/facebook/react-native/issues/30919 that aimed to get the keyboard height on devices with a Notch. The problem is that it considers that any ReactRootView will have an insets available.
When using [react-native-navigation](https://github.com/wix/react-native-navigation) and assigning a Navigation button to the TopBar as a component, the component gets registered as a RootView but won't have any insets attach to the view.
[getRootWindowInsets()](https://developer.android.com/reference/android/view/View#getRootWindowInsets()) in fact return a `WindowInset` only available if the view is attached, so when executing `checkForKeyboardEvents` method from ReactRootView, is trying to access the `DisplayCutout` of a null object, leading to a crash.
## Changelog
[Android] [Fixed] - Fix potential crash if ReactRootView does not have insets attached.
Pull Request resolved: https://github.com/facebook/react-native/pull/32989
Test Plan:
Without the code change: Notice how the second screen being push contains a React Component on the top right of the navigation bar, and when component is unmounted (going back) the app crashes.
https://user-images.githubusercontent.com/6757047/151558235-39b9a8b5-be73-4c31-8053-02ce188637b8.mp4
crash log
```
2022-01-28 10:27:52.902 15600-15600/com.mattermost.rnbeta E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.mattermost.rnbeta, PID: 15600
java.lang.NullPointerException: Attempt to invoke virtual method 'android.view.DisplayCutout android.view.WindowInsets.getDisplayCutout()' on a null object reference
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.checkForKeyboardEvents(ReactRootView.java:778)
at com.facebook.react.ReactRootView$CustomGlobalLayoutListener.onGlobalLayout(ReactRootView.java:769)
at android.view.ViewTreeObserver.dispatchOnGlobalLayout(ViewTreeObserver.java:1061)
at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:3214)
at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:2143)
at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:8665)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1037)
at android.view.Choreographer.doCallbacks(Choreographer.java:845)
at android.view.Choreographer.doFrame(Choreographer.java:780)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1022)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loopOnce(Looper.java:201)
at android.os.Looper.loop(Looper.java:288)
at android.app.ActivityThread.main(ActivityThread.java:7839)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1003)
```
After applying the patch which is only a null check validation and does not change any previous behavior
https://user-images.githubusercontent.com/6757047/151558429-9ff1a608-abb6-4168-8db9-df0c3c71d79e.mp4
Reviewed By: cortinico
Differential Revision: D33844955
Pulled By: ShikaSD
fbshipit-source-id: ed5579ad3afeed009c61cc1851eee45c70087cf5
Summary:
Fixes https://github.com/facebook/react-native/issues/32939
It appears there is circular dependencies on the Modal component that causes the modalMock function to be an empty object. Removing the import fixes the issue.
I don't know yet why this is not happening when executing the test suite inside `Modal-test.js` but I will investigate this later.
## 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] [Fixed] - Fix error "mockModal is not a function"
Pull Request resolved: https://github.com/facebook/react-native/pull/32964
Test Plan:
On a newly initiated project using react-native 0.67.1 I created a ModalComponent:
```
import React from 'react';
import {Modal, Text} from 'react-native';
export const ModalComponent = () => {
return (
<Modal visible>
<Text>Test</Text>
</Modal>
);
};
```
and a ModalComponent.test.tsx:
```
import 'react-native';
import React from 'react';
import {ModalComponent} from '../ModalComponent';
// Note: test renderer must be required after react-native.
import renderer from 'react-test-renderer';
it('renders correctly', () => {
renderer.create(<ModalComponent />);
});
```
Running the test throws the error "TypeError: mockModal is not a function".
After modifying the mockModal inside node_modules/react-native/jest/mockModal.js it works correctly.
Reviewed By: christophpurrer
Differential Revision: D33771136
Pulled By: lunaleaps
fbshipit-source-id: c09ada8d2f864f5568b3379616a6cace9fb9921e
Summary:
The path to `Time.h` is currently hard-coded and does not take into
consideration the `--project-directory` flag when running `pod install`.
## Changelog
[iOS] [Fixed] - Fix `Time.h` patch not being applied when running `pod install --project-directory=ios`
Pull Request resolved: https://github.com/facebook/react-native/pull/32961
Test Plan:
```
git clone https://github.com/microsoft/react-native-test-app.git
cd react-native-test-app
npm run set-react-version main
yarn
cd example
pod install --project-directory=ios
../scripts/xcodebuild.sh ios/Example.xcworkspace build
```
Reviewed By: christophpurrer
Differential Revision: D33748789
Pulled By: lunaleaps
fbshipit-source-id: b125734eba30e552ae139e7ecd4e634c8fa1bcd7
Summary:
React-native Xcode build steps (such as "Build JS Bundle") rely on `find.node-sh` to find the correct node binary, using nvm if present. We do this because Xcode may run build steps in a fresh shell environment, presumably for repeatable builds.
This PR fixes `find-node.sh`, to respect any `.nvmrc` file that may be present in the build environment.
Today: `find-node.sh` will set the shell environment to the system node version, and ignores any `.nvmrc` the project may provide to pin node for repeatable builds. By ignoring `.nvmrc`, node versions may differ depending on system environment — between developer laptops, or between developer and CI environments. 😞
This problem has been been noticed before in https://github.com/facebook/react-native/issues/8887
### Should this fix happen upstream?
Unfortunately this nvm behavior [is intended](https://github.com/nvm-sh/nvm/issues/2053), for backwards compatibility
## 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
-->
[iOS] [Fixed] - find-node.sh now respects .nvmrc
Pull Request resolved: https://github.com/facebook/react-native/pull/32712
Test Plan:
Before:
```bash
# nvm isn't loaded
$ which nvm
# we're on default system node
$ which node && node --version
/usr/local/bin/node
v17.0.1
$ echo v16.13.0 > .nvmrc
$ source ./scripts/find-node.sh
# Expected: v16.13.0
$ node --version
v17.0.1
```
After:
```bash
# we're on default system node
$ which node && node --version
/usr/local/bin/node
v17.0.1
$ echo v16.13.0 > .nvmrc
$ source ./scripts/find-node.sh
# Expected: v16.13.0
$ node --version
v16.13.0
```
After (no .nvmrc, should preserve previous behavior):
```bash
# we're on default system node
$ which node && node --version
/usr/local/bin/node
v17.0.1
$ source ./scripts/find-node.sh
$ nvm ls|grep default
default -> v14.17.1
# Expected: v14.17.1
$ node --version
v14.17.1
```
Reviewed By: sota000
Differential Revision: D32889629
Pulled By: ShikaSD
fbshipit-source-id: 527384055e303a87bad43413fb66a7fd117d1a63
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32932
As the title says, we dont' want to remove `libjscexecutor.so` when
baking release builds and having JSC enable as this leads to instacrashes.
Fixes#32928Fixes#32927
Changelog:
[Android] [Fixed] - Do not remove libjscexecutor.so from release builds
Reviewed By: ShikaSD
Differential Revision: D33681932
fbshipit-source-id: 5b59fd1fb76c80c191198d65c916bbbd9232c75b
Summary:
Resolves this issue: https://github.com/facebook/react-native/issues/32304.
**NOTE:** This PR is based on a prior PR for this fix: https://github.com/facebook/react-native/pull/32305, I've co-authorized its creator for this change (paddlefish).
Without this change, calling to hide an alert, leaves a `UIWindow` that blocks user interactions with the screen.
The correct way to remove a `UIWindow` in iOS is to set its hidden property to `YES`. Also, it is required to remove all references to the window (the associated `windowScene` for example) and ARC will automatically free this `UIWindow`.
The line after this change, set the `_alertWindow` reference to `nil`, but the window is already associated with a scene (see the screenshots from [this PR](https://github.com/facebook/react-native/pull/32305#discussion_r720521707)). So we also need to remove the `windowScene` from that window, as recommended by Apple: https://developer.apple.com/documentation/uikit/uiwindowscene/3198091-windows.
>To remove the window from the current scene, or move it to a different scene, change the value of the window's windowScene property.
## 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
-->
[iOS] [Fixed] - remove alert's window when call to `hide`.
Pull Request resolved: https://github.com/facebook/react-native/pull/32833
Test Plan: See https://github.com/facebook/react-native/pull/32305
Reviewed By: hramos
Differential Revision: D33460430
Pulled By: lunaleaps
fbshipit-source-id: b13c2c7ee6404f1e1c787265bc4af8a31005bcf1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32769
Changelog: [Internal] Re-purpose bump-oss-version to guide releaser to correctly tag the release and trigger relevant CircleCI jobs
Reviewed By: sota000
Differential Revision: D33121691
fbshipit-source-id: 739f920cd9a04dfb436aff1abe9a05a51df4c32c
Summary:
Changelog: [Internal] Update the comments in publish-npm script to changes in release workflow and leverage `isTaggedLatest` utility.
A lot of this information will be moved to the Release wiki on Github
Reviewed By: ShikaSD
Differential Revision: D33110407
fbshipit-source-id: b01a555a3eed6e505a3b0ad220a0c2c54459ab03
Summary: Changelog: [Internal] - Update the source of the changes in generated files, no longer bump-oss-version but set-rn-version
Reviewed By: sota000
Differential Revision: D33110408
fbshipit-source-id: 8cd5004f5d40dde82fe4d6271d5b8598cd27ca31
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32757
Changelog: [Internal] - Update release automation to still be manually triggered as from discussion: https://github.com/reactwg/react-native-releases/discussions/7
A releaser needs to do the following on a release branch like `0.99-stable`:
* For an initial release branch cut:
* Tag the head of the branch `git tag publish-v0.99.0-rc.0`
* `git push origin 0.99-stable --follow-tags`
* For cherry-picks on the pre-release:
* Make the picks on `0.99-stable`
* Tag the head of the branch `git tag publish-v0.99.0-rc.1`
* `git push origin 0.99-stable --follow-tags`
* For promoting pre-release to stable with intention of making this the `latest` npm version:
* Tag the head of the branch `git tag publish-v0.99.0`
* Tag the head of the branch `git tag latest`
* `git push origin 0.99-stable --follow-tags`
Follow-up diff to make this codified via a script
Reviewed By: sota000
Differential Revision: D33101594
fbshipit-source-id: 74b065229a3705fccbe1a25ed7ece4a28d9aa76d
Summary: Changelog: [Internal] Add a `isTaggedVersion` function to filter out commits from release automation.
Reviewed By: sota000
Differential Revision: D32842035
fbshipit-source-id: 14bb262a1d2a96ffda87c759a3202c4f9a356141
Summary:
Changelog: [Internal] Update CircleCI to auto-deploy release branch on push
This work is part of an effort to automate the release process by using a push to a release branch as a trigger to prepare, package and deploy react-native to npm from CircleCI
The following diagram describes the context (what kind of releases we do, relevant scripts and what they do), the pre-existing process for the different types of release and how I've modified the process.
{F683387103}
This diff updates the relevant CircleCI workflows
Reviewed By: sota000
Differential Revision: D32702420
fbshipit-source-id: e20cdeb53eb4a8ce7e54e083e3e14bd89e11b789
Summary:
Changelog: [Internal] - Extract logic from bump-oss-version specific to prod releases
This work is part of an effort to automate the release process by using a push to a release branch as a trigger to prepare, package and deploy react-native to npm from CircleCI
The following diagram describes the context (what kind of releases we do, relevant scripts and what they do), the pre-existing process for the different types of release and how I've modified the process.
{F683387103}
This diff creates the `prepare-package-for-release` script referenced by extracting it out of `bump-oss-version` and leveraging `set-rn-version`. It adds some helper functions to `version-utils` with tests
Reviewed By: sota000
Differential Revision: D32556610
fbshipit-source-id: eb4ddc787498744156f985ab6d205c5d160e279b
Summary:
Changelog: [Internal] Copy over universal (across dry-run, nightly, release) work in `bump-oss-version` script
This work is part of an effort to automate the release process by using a push to a release branch as a trigger to prepare, package and deploy react-native to npm from CircleCI
The following diagram describes the context (what kind of releases we do, relevant scripts and what they do), the pre-existing process for the different types of release and how I've modified the process.
{F683387103}
This diff creates the `set-rn-version` script referenced by extracting it out of `bump-oss-version`
Reviewed By: sota000
Differential Revision: D32556608
fbshipit-source-id: 6c2868c01ddd930375279a5105bcd0d447f65734
Summary:
Changelog: [Internal] - Add getNextVersionFromTags to determine next release version off a release branch
In more detail - this work is part of an effort to automate the release process by using a push to a release branch as a trigger to prepare, package and deploy react-native to npm from CircleCI
This function is later used in `prepare-package-for-release` script in D32556610 to bump the version
Reviewed By: cortinico, ShikaSD
Differential Revision: D32556609
fbshipit-source-id: 7d93ead0b34318a58ffeb876715fbd34d6041f4e
Summary:
The `__apply_Xcode_12_5_M1_post_install_workaround` script changes the `IPHONEOS_DEPLOYMENT_TARGET` to `11.0` for all pods. This causes problems if the pods were targetting `12.0` or higher. Many expo modules are targetting `12.0`.
I fixed this issue by checking the existing version and only bumping the target if it is lower than `11.0`.
See also: this discussion post by mikehardy https://github.com/reactwg/react-native-releases/discussions/1#discussioncomment-1619523
## 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
-->
[iOS] [Fixed] - __apply_Xcode_12_5_M1_post_install_workaround causing pods targetting iOS 12 and above to fail
Pull Request resolved: https://github.com/facebook/react-native/pull/32633
Test Plan:
### Test (failing before this patch, passing after this patch)
1. pick an iOS Pod that has a minimum deployment target of iOS 12 or higher, I chose the Braintree package
2. `npx react-native init myrnapp`
3. Open `ios/Podfile` and add the pod as a dependency: `pod 'Braintree', '~> 5'` (and upgrade the Podfile target to 12 (`platform :ios, '12.0'`))
4. Compile the app.
Before applying this patch: ❌ Build fails because Braintree uses iOS 12 features and was downgraded to target 11.0
After applying this patch: ✅ Build succeeds
Reviewed By: fkgozali
Differential Revision: D32638171
Pulled By: philIip
fbshipit-source-id: 0487647583057f3cfefcf515820855c7d4b16d31
Summary:
This reverts commit fcead14b0e.
This should close https://github.com/facebook/react-native/issues/32509 . There was a bug where il8nManager.forceRTL() wouldn't work on app launch, and required an app restart. That was caused by an earlier change (https://github.com/facebook/react-native/pull/31032) which should not be necessary (the deadlock it was attempting to fix was actually caused by separate code).
## 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
-->
[iOS] [Fixed] - Fixed bug where forceRTL did not work on app launch
Pull Request resolved: https://github.com/facebook/react-native/pull/32574
Test Plan: Simple revert back to previously working code.
Reviewed By: RSNara
Differential Revision: D32315034
Pulled By: GijsWeterings
fbshipit-source-id: dae6c1f0a2481e53f2f1e80f1ac083947681ef99
Summary:
Renames `Keyboard.removeEventListener` to `Keyboard.removeListener`.
When I implemented the compatibility layer in {D26589441 (https://github.com/facebook/react-native/commit/035718ba97bb44c68f2a4ccdd95e537e3d28690c)}, I accidentally used the wrong name. Since `Keyboard.removeEventListener` was always deprecated, this removes it completely.
Changelog:
[General][Changed] - Rename deprecated `Keyboard.removeEventListener` to `Keyboard.removeListener`.
Reviewed By: lunaleaps
Differential Revision: D32282743
fbshipit-source-id: 309382af3269f85f781d38367d115a2ce3690efb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32543
Changelog: [Internal] Fix npm `latest` tag issue that occurs when we release a patch on an older minor version
Context:
* There are two types of tags, git and npm, they are unrelated.
* When we publish a stable release, we set the git tag `latest`. This logic is faulty when we release a patch to an older version.
* When publishing a package to npm, if you don't provide an explicit tag, the `latest` tag will be applied -- at least that's how I've understood the [docs here](https://docs.npmjs.com/cli/v7/commands/npm-dist-tag#description). This again is faulty logic when we release a patch to an older version.
* npm and git's `latest` tag should always point to our most recent stable version
This change:
* Introduces a `--latest` flag for `bump-oss-script` that will indicate that the release we're running (either a stable or pre-release) should really be considered "latest"
* If the version is not a pre-release and the `--latest` flag is set, we will set the git `latest` tag
* Later, in the circleCI job that we use to publish the npm package, we will see if the current commit is git-tagged as `latest`. If it is, then we'll explicitly tell npm to use `latest` tag but most importantly, if it's not, we'll set a tag of the form `{major}.{minor}-stable`.
* This type of tag (ex. `0.66-stable`) is new and the intention is that it will always point to latest of that minor version.
Reviewed By: hramos
Differential Revision: D32196239
fbshipit-source-id: 4c881851eebcad8585732ff0c07322413ac46ce5
Summary:
Changelog: [Internal] Remove unnecessary logic and new parseVersions function
Changes:
* Remove `tagsForVersions` which in the past got all the tags for the `currentCommit` to figure out which one we're releasing to. I believe this is redundant because the CircleCI envvar `CIRCLE_TAG` should already have the version that we're releasing -- this is set in `bump-oss-version`. Note: this will only be set for full-on releases, (re: not nightly or commitly)
* Re-arrange some logic to group where we set `releaseVersion` and separate where we call `bump-oss-version` script for dryRun (commitly) && nightly builds
Reviewed By: hramos
Differential Revision: D32196237
fbshipit-source-id: 10f21f71bad1ea0496c5eb9094271cc4454a2544
Summary:
Many have reported about the misguiding error `Fatal Exception: java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libhermes.so` even though they don't use Hermes (for example issues https://github.com/facebook/react-native/issues/26075#25923).
**The current code does not handle errors correctly when loading JSC or Hermes in `ReactInstanceManagerBuilder`**.
**ReactAndroid/src/main/java/com/facebook/react/ReactInstanceManagerBuilder.java:**
```java
try {
return new HermesExecutorFactory();
} catch (UnsatisfiedLinkError hermesE) {
// We never get here because "new HermesExecutorFactory()" does not throw an exception!
hermesE.printStackTrace();
throw jscE;
}
```
In Java, when an exception is thrown in static block, it will be RuntimeException and it can't be caught. For example the exception from `SoLoader.loadLibrary` can't be caught and it will crash the app.
**ReactAndroid/src/main/java/com/facebook/hermes/reactexecutor/HermesExecutor.java:**
```java
static {
// Exception from this code block will be RuntimeException and it can't be caught!
SoLoader.loadLibrary("hermes");
try {
SoLoader.loadLibrary("hermes-executor-debug");
mode_ = "Debug";
} catch (UnsatisfiedLinkError e) {
SoLoader.loadLibrary("hermes-executor-release");
mode_ = "Release";
}
}
```
This PR fixes the code so that the original exception from failed JSC loading is not swallowed. It does not fix the original issue why JSC loading is failing with some devices, but it can be really helpful to know what the real error is. For example Firebase Crashlytics shows wrong stack trace with current code.
I'm sure that this fix could have been written better. It feels wrong to import `JSCExecutor` and `HermesExecutor` in `ReactInstanceManagerBuilder.java`. However, the main point of this PR is to give the idea what is wrong with the current code.
## 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
-->
[Android] [Fixed] - Fix error handling when loading JSC or Hermes
Pull Request resolved: https://github.com/facebook/react-native/pull/30749
Test Plan:
* from this PR, modify `ReactAndroid/src/main/java/com/facebook/react/jscexecutor/JSCExecutor.java` so that JSC loading will fail:
```java
// original
SoLoader.loadLibrary("jscexecutor");
// changed
SoLoader.loadLibrary("jscexecutor-does-not-exist");
```
* Run `rn-tester` app
* Check from Logcat that the app crashed with correct exception and stacktrace. It should **not** be `java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libhermes.so`
Tested with Hermes
```
SoLoader.loadLibrary("hermes-executor-test");
```
Got this one in logcat
```
09-24 20:12:39.552 6412 6455 E AndroidRuntime: java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libhermes-executor-test.so
```
Reviewed By: cortinico
Differential Revision: D30346032
Pulled By: sota000
fbshipit-source-id: 09b032a9e471af233b7ac90b571c311952ab6342
Summary:
Fix the `scripts/update-ruby.sh` so it always use the correct [bundle config](https://bundler.io/man/bundle-config.1.html#DESCRIPTION). In the current version it wasn't using the correct configuration inside the `template/` directory, resulting in incorrect platform for `template/Gemfile.lock`.
While at that, update the gems to their latest version:
- ethon 0.14.0 -> 0.15.0
- json 0.5.1 -> 0.6.0
- zeitwerk 2.4.2 -> 2.5.1
- bundler 2.2.28 -> 2.2.29
No changelog
Pull Request resolved: https://github.com/facebook/react-native/pull/32456
Test Plan:
Run `bump-oss-version.js` and see `template/Gemfile.lock` lists `ruby` as the `PLATFORM` (no diff in that line).
- https://github.com/facebook/react-native/commit/e18cf90d71d0bef2e2a0caf30a89e53129152965#r58230816
Reviewed By: yungsters
Differential Revision: D31841524
Pulled By: charlesbdudley
fbshipit-source-id: 695c245fcb344c866afed45f747e04233e5c91e4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32418
This commit does 2 things:
* Process and store stats for *-stable branches, in addition to main
* Print out the new stats to stdout, so that CI jobs can display them for verification purpose
This also means a new field `branch` is used for the Firestore data.
Changelog: [Internal]
Reviewed By: hramos
Differential Revision: D31717251
fbshipit-source-id: 9dbfa8fb8f0243c013dcd822230400d26c09eaa4
Summary:
The size information is currently not used for release branches. Further, the CI step failed because there is no PR associated with commits in RC branch. This commit fixed that error by skipping the entire work altogether.
Sample error: https://app.circleci.com/pipelines/github/facebook/react-native/10161/workflows/3625732a-531f-435d-83b6-1dbc638e1bab/jobs/215405/parallel-runs/0/steps/0-125
In theory, we should be storing RC bundle sizes as well, but the current backing Firebase DB has not been configured with proper index:
```
Error [FirebaseError]: The query requires an index.
...
```
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D31705912
fbshipit-source-id: 26757174f7937cb23d8e55066b833ae15ec011e3
Distiller
Elias Nahum
owjsub
AntoineDoubovetzky
Luna Wei
Tommy Nguyen
Ian Grayson
Distiller
Nicola Corti
Asaf Korem
Distiller
Distiller
Simon Farshid
Distiller
Neil Dhar
Saad Najmi
Tim Yung
Rubén Norte
Lorenzo Sciandra
Tuomas Jaakola
Gustavo Sverzut Barbieri
Kevin Gozali
CodemodService FBSourceGoogleJavaFormatLinterBot