Summary:
When building from source, the PrivateReactExtension is getting no defaults (or missing defaults).
Specifically root should point to ../../ (as the build from source will originate
from `./node_modules/react-native`).
Without that root specified, all the subsequent paths are broken,
specifically, the default being `../` causes the codegen to be searched inside:
```
project/node_modules/node_modules/react-native/codegen
```
which is broken
Changelog:
[Internal] [Changed] - RNGP - Fix defaults for PrivateReactExtension
Reviewed By: cipolleschi
Differential Revision: D43435590
fbshipit-source-id: 2ed5e26c1d63fd808fc2d559ea83d6d39d106ff6
Summary:
We do have a lot of changes on `main` to ship to nightlies. This change bump all the packages with pending changes.
## Changelog
[INTERNAL] [CHANGED] - [ci][monorepo] bump package versions
Pull Request resolved: https://github.com/facebook/react-native/pull/36184
Test Plan: Will rely on CI run.
Reviewed By: hoxyq
Differential Revision: D43363981
Pulled By: cortinico
fbshipit-source-id: eba5152dbe007eb3fad43f9088d145b3741fd94e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36162
Changelog: [Internal]
Adds a dedicated screen to RNTester to help manually test the handling of various invalid prop values.
Reviewed By: huntie
Differential Revision: D43270626
fbshipit-source-id: 3fbf452955b2caace7a09fbb9c83960703fd974f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36164
Changelog:
[General][Fixed] - Invalid prop values no longer trigger assertion failures in Fabric
## Context
Fabric has historically been very strict about prop parsing. It originally `abort()`ed on any prop value that failed to parse according to the expected type; this was replaced with dev-only assertions in D27540903 (https://github.com/facebook/react-native/commit/cb37562f8355b624e271c5b74416c257b0e62a00). We've received feedback that C++ assertions (and other similar mechanisms in the legacy renderer) are still too aggressive and disruptive as a diagnostic for developers working on JS code.
We are changing React Native to behave more like a browser in this regard, reflecting a new principle that **bad style values are not runtime errors**. (See e.g. D43159284 (https://github.com/facebook/react-native/commit/d6e9891577c81503407adaa85db8f5bf97557db0).) The recommended way for developers to ensure they are passing correct style values is to use a typechecker (TypeScript or Flow) in conjunction with E2E tests and manual spot checks.
More broadly, values passed from JS product code should not be able to crash the app, which is why we're not strictly limiting this change to style props. From now on, if a JS developer can trigger an internal assertion in React Native simply by writing normal application code, that is a bug.
## This diff
This diff introduces a new macro called `react_native_expect` which serves as a drop-in replacement for `react_native_assert`, but logs (to glog / logcat / stdout) instead of asserting. This way we don't need to fully delete the existing call sites. This will be helpful if we decide that we want to repurpose these checks for a new, more visible diagnostic.
I'm *intentionally* opting for the simplest possible improvement here, which is to silence the assertions - not to print them to the JS console, not to convert them to LogBox warnings, etc. The hypothesis is that this is already strictly an improvement over the previous behaviour, will help us get to feature parity between renderers faster, and allow us to design improved diagnostics that are consistent and helpful.
## Next steps
1. There are still places where Fabric can hit an unguarded assertion in prop conversion code (e.g. unchecked casts from `RawValue` with no fallback code path). I will fix those in a separate diff.
2. Paper on iOS needs a similar treatment as it calls `RCTLogError` liberally during prop parsing (resulting in a native redbox experience that is nearly as bad as an outright crash). I will fix that in a separate diff.
3. I'll add some manual test cases to RNTester to cover these scenarios.
4. We will eventually need to take a clear stance on PropTypes, but since they provide reasonable, non-breaking diagnostics (recoverable JS LogBox + component stack) it is less urgent to do so.
Reviewed By: sammy-SC
Differential Revision: D43184380
fbshipit-source-id: 0c921efef297d935a2ae5acc57ff23171356014b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36143
Changelog: [Internal]
Currently, some `__tests__` are included in `react-native/virtualized-lists`, added them to ignore list, so that we will remove it in the next publish
Reviewed By: christophpurrer
Differential Revision: D43159337
fbshipit-source-id: 27ed0adf85387a2e8ac902da57888f0b188b0b91
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36030
Generate enum types in c++ turbo modules.
For enums in the ts schema file such as:
```
export enum NumEnum {
ONE = 1,
TWO = 2,
}
```
This would export enums and the relevant Bridging to js and from js code to the spec H files such as:
```
#pragma mark - SampleTurboModuleCxxNumEnum
enum SampleTurboModuleCxxNumEnum { ONE, TWO };
template <>
struct Bridging<SampleTurboModuleCxxNumEnum> {
static SampleTurboModuleCxxNumEnum fromJs(jsi::Runtime &rt, int32_t value) {
if (value == 1) {
return SampleTurboModuleCxxNumEnum::ONE;
} else if (value == 2) {
return SampleTurboModuleCxxNumEnum::TWO;
} else {
throw jsi::JSError(rt, "No appropriate enum member found for value");
}
}
static jsi::Value toJs(jsi::Runtime &rt, SampleTurboModuleCxxNumEnum value) {
if (value == SampleTurboModuleCxxNumEnum::ONE) {
return bridging::toJs(rt, 1);
} else if (value == SampleTurboModuleCxxNumEnum::TWO) {
return bridging::toJs(rt, 2);
} else {
throw jsi::JSError(rt, "No appropriate enum member found for enum value");
}
}
};
```
That code would allow us to use these enums in the cxx files like this:
```
NativeCxxModuleExampleCxxEnumInt getNumEnum(
jsi::Runtime &rt,
NativeCxxModuleExampleCxxEnumInt arg);
```
Changelog: [General] [Added] Generate enum types that would be allowed to be used as well as string/number in c++ turbo modules generators
Reviewed By: christophpurrer
Differential Revision: D42884147
fbshipit-source-id: d34d1fc7ba268b570821dc108444196f69a431b2
Summary:
Add minimum necessary .d.ts files to react-native-codegen.
I found .d.ts files will be copied to `lib` so I guess no additional script is needed.
## Changelog
[GENERAL] [CHANGED] - Add minimum necessary .d.ts files to react-native-codegen
Pull Request resolved: https://github.com/facebook/react-native/pull/36102
Test Plan: `npm run build` in `packages/react-native-codegen` and see all .d.ts files appear in `lib`.
Reviewed By: cortinico
Differential Revision: D43157233
Pulled By: cipolleschi
fbshipit-source-id: 6f122f0f4cda693ba22af6dd534e9d34d069ecac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36128
This commit fixes a problem which is making harder to use the New Architecture in monorepos.
Specifically if a user specifies a `codegenDir` in their app, libraries should honor it.
This is not the case today.
The fix is to register an extension on the root project which will "pass" values from app
to libraries.
I've also cleaned up some of the logic in `readPackageJsonFile` function restricting
the access to those functions only to `.root` which is the only field they're accessing.
Fixes#35495
Changelog:
[Android] [Fixed] - Better Monorepo support for New Architecture
Reviewed By: cipolleschi
Differential Revision: D43186767
fbshipit-source-id: 5c5ca39397306120b6b6622cb728633bd331e021
Summary:
Changelog:
[Internal] [Changed] - Remove unused variable in a test in RNGP
Created from CodeHub with https://fburl.com/edit-in-codehub
Reviewed By: cipolleschi
Differential Revision: D43185910
fbshipit-source-id: b1f328592e0b38654fd2e0a36304ce8f1d433b44
Summary:
Fix typo in the initialNumToRenderOrDefault description's comment : function's parameter should be this.props.initialNumToRender instead of this.props.initialNumToRenderOrDefault
## Changelog
[GENERAL] [FIXED] - Fixed typo in the initialNumToRenderOrDefault description's comment
Pull Request resolved: https://github.com/facebook/react-native/pull/36110
Test Plan: Typo in a comment - no testing required
Reviewed By: christophpurrer
Differential Revision: D43160548
Pulled By: cortinico
fbshipit-source-id: 0555c7752102f431fb327b920434faaf4de4ff81
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36107
Having concurrentRoot disabled when Fabric is enabled is not recommended.
This simplifies the setup and makes sure that both are either enabled or disabled.
Changelog:
[Android] [Breaking] - Hardcode concurrentRootEnabled to true when Fabric is enabled
Reviewed By: cipolleschi
Differential Revision: D43127625
fbshipit-source-id: 88e5e800b55d5df228fb072bedf8533b0ab6c20d
Summary:
Changelog:
[iOS][Fixed] - Unrecognized fontFamily values no longer trigger a redbox
## Context
We are starting to roll out a new consistent approach to style errors in React Native, where malformed or semantically invalid style values will never be treated as runtime errors. Instead, bad style values will consistently fall back to known defaults; the incorrect visual rendering will serve as the main runtime diagnostic for developers. We will advise developers to rely on static types for additional diagnostics.
This work will take place over multiple commits and possibly multiple releases of React Native.
## This diff
Here we fix this issue as it applies to the `fontFamily` style prop. The legacy (Paper) renderer on iOS is the only concrete implementation that had to change. Fabric and Android already implement the correct behaviour.
h/t EvanBacon for the report: https://twitter.com/Baconbrix/status/1623039650775371792
Reviewed By: huntie
Differential Revision: D43159284
fbshipit-source-id: 6afeef3abc5781e18671708f642073d25f2347e9
Summary:
State updates can be batched together idependent of `this.state`, so we should do any calculation deriving state from state within a `setState()` callback. This fixes a bug where we were relying on potentially stale state, a RenderMask derived from `this.state` instead of the `state` callback parameter, when triggering updates from focus.
Note that this is not exercised on Android/iOS, but it on desktop/web. I noticed this a while back while making another change, but that change got abandoned, so this is the independent fix.
Changelog:
[General][Fixed] - Calculate VirtualizedList render mask for focused cell during batched state updates
Reviewed By: javache
Differential Revision: D43073415
fbshipit-source-id: dee4197ec925a6d8d427b63fb063aa4e3b58c595
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36080
For Android release builds on Windows, gradle release build fails if there are spaces in path (https://github.com/facebook/react-native/issues/34878). This is due to gradle improperly handling arguments with spaces (this is also [an open issue](https://github.com/gradle/gradle/issues/6072) on Gradle). Since the Hermes compilation and other Gradle exec invocations involve arguments which will contain spaces (if there are spaces in your path), this also means it is hard to get around this by simply escaping the spaces (eg: by using double quotes), since these arguments are not properly handled by Gradle itself.
As a workaround, this PR uses relative paths for all Gradle commands invoked for Android. As long as there aren't any spaces in the react-native directory structure (i.e this repo), this fix should work.
## Changelog
[Android][Fixed] - Used relative paths for gradle commands
Pull Request resolved: https://github.com/facebook/react-native/pull/36076
Test Plan: `npx react-native run-android` builds and runs the app successfully on Android device, when run inside an RN0711 project with a path containing spaces (and with the changes in this PR applied) on Windows. This includes release builds (i.e with the `--variant=release` flag).
Reviewed By: cipolleschi
Differential Revision: D43080177
Pulled By: cortinico
fbshipit-source-id: 7625f3502af47e9b28c6fc7dfe1459d7c7f1362d
Summary:
This change reverts D41745930 (https://github.com/facebook/react-native/commit/2e3dbe9c2fbff52448e2d5a7c1e4c96b1016cf25) as part of a stack to splice back source history which was lost (Git registered the file moves as additions).
It is expected this diff will individually fail. The entire stack should be applied at once.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D43068113
fbshipit-source-id: c8398629fe5dcc1ca4bf02f550adc00c78a8487a
Summary:
This is a small refactor designed to make future merges for React Native macOS easier. It was found while merging React Native 0.71 into React Native macOS.
In React Native macOS, we ifdef iOS out API's and replace them with macOS APIs, reusing as much code as possible. `CGContext` is a type that is available on both iOS and macOS, but `UIGraphicsImageRendererContext` is not. A simple refactor makes it easier to reuse this code in React Native macOS without affecting iOS :)
Resolves https://github.com/microsoft/react-native-macos/issues/1676
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [CHANGED] - Pull out CGContext early in UIImage+Diff
Pull Request resolved: https://github.com/facebook/react-native/pull/35940
Test Plan: Build should pass.
Reviewed By: matrush
Differential Revision: D42761424
Pulled By: javache
fbshipit-source-id: 5ce79a5e7c60484dd37d0b2c3f58ff0897d662df
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36044
> **Notice**: This commit does not change any behaviour.
Parse and collect enum members in module specs instead of the current behaviour of parsing enum members as 'string' / 'number' and ignoring the member names.
This commit would allow us to generate native Enums corresponding to the schema's enums.
Prior to this commit, enum params were parsed as:
```
{
'name': 'qualityParam',
'optional': false,
'typeAnnotation': {
'type': 'EnumDeclaration',
'memberType': 'StringTypeAnnotation'
}
},
```
The name of the enum type and the members of the enum type were ignored.
After this commit, parsed modules would hold a new object member called `enumMap` that would look like this:
```
'enumMap': {
'QualityEnum': {
'name': 'QualityEnum',
'type': 'EnumDeclarationWithMembers',
'memberType': 'StringTypeAnnotation',
'members': [
{
'name': 'SD',
'value': 'sd'
},
{
'name': 'HD',
'value': 'hd'
}
]
},
// ...
}
```
And enum params would be exported as:
```
{
'name': 'qualityParam',
'optional': false,
'typeAnnotation': {
'name': 'NativeModuleEnumTypeAnnotation',
'type': 'EnumDeclaration',
'memberType': 'StringTypeAnnotation'
}
},
```
Combining the two new outputs would allow us to generate Native enums in the Native generators.
Changelog: [Internal] Parse and collect enum members in turbo module specs
Reviewed By: cipolleschi
Differential Revision: D42778258
fbshipit-source-id: 56479342e085bc4e13c5a3e12b265b140e49893c
Summary:
Handling of `EnumDeclaration` was introduced in D38967241 (https://github.com/facebook/react-native/commit/745f3ee8c571560406629bc7af3cf4914ef1b211) so it is no longer a type expected to fail generators.
Changelog: [Internal] remove 'EnumDeclaration' as a type expected to throw error in module generators
Reviewed By: cipolleschi
Differential Revision: D42917947
fbshipit-source-id: 16fcb915ccd42c613ca4d30b815d6365681f5fa1
Summary:
* Added an e2e test fixture with all the supported enum variations
* Added H and C file TM generators to the TM e2e tests
Changelog: [Internal] Added an e2e test fixture for Enums and .H+.C TM e2e snapshot tests
Reviewed By: cipolleschi
Differential Revision: D42917330
fbshipit-source-id: 8e4adb86b6eb4e2b29a9e6d0cd6e4fd5b002ad1a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36042
Pull Request resolved: https://github.com/facebook/react-native/pull/36028
Use aliasMap both in parsers and generators instead of using aliasMap in half of the places and aliases in the other.
This would also allow us to introduce "enumMap" more easily in the next commit.
Changelog: [Internal] rename module exports from "aliases" to "aliasMap"
Reviewed By: christophpurrer, cipolleschi
Differential Revision: D42888752
fbshipit-source-id: cf1929fcebde994d07e5c6bda5ab71106d417b21
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36039
This change bumps AGP to 7.4.1 so we can remove a lot of the unnecessary changes
we had to do to support AGP 7.3.x
I've also removed the explicit version in the template as now the AGP version
is provided by RNGP. That means that the user will get the correct version they need.
This also bumps the default CMake version in user space to 3.22 which resolves a lot
of warning when users are building with the New Architecture enabled.
Changelog:
[Android] [Changed] - Bump AGP to 7.4.1
allow-large-files
Reviewed By: cipolleschi
Differential Revision: D42960353
fbshipit-source-id: 9065f975c1694d266a86b2d3fe805e6e2b1c4aa1
Summary:
The [previous pull request](https://github.com/facebook/react-native/pull/35812) enables defining interfaces and using them in a turbo module, but all members are flattened, this is not the best option for codegen for object oriented languages.
In this pull request, an optional member `baseTypes` is added to aliased objects. Members are still flattened for backward compatibility, if a codegen doesn't care about that nothing needs to be changed.
### Example
```typescript
interface A {
a : string;
}
interface B extends A {
b : number;
}
```
#### Before the previous pull request
`interface` is not allowed here, you must use type alias.
#### At the previous pull request
`interface` is allowed, but it is translated to
```typescript
type A = {a : string};
type B = {a : string, b : number};
```
#### At this pull request
Extra information is provided so that you know `B` extends `A`. By comparing `B` to `A` it is easy to know that `B::a` is obtained from `A`.
## Changelog
[GENERAL] [CHANGED] - Turbo module codegen support interface with inheritance in module
Pull Request resolved: https://github.com/facebook/react-native/pull/36011
Test Plan: `yarn jest react-native-codegen` passed
Reviewed By: rshest
Differential Revision: D42882650
Pulled By: cipolleschi
fbshipit-source-id: 32d502e8a99c4151fae0a1f4dfa60db9ac827963
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35992
Fixes https://github.com/software-mansion/react-native-gesture-handler/issues/2382
I've just realized that the default value fo `jsRootDir` is not entirely correct.
That's the root of the folder where the codegen should run.
For apps, it should be defaulted to `root` (i.e. ../../)
For libraries, it should be defaulted to `../` (currently is root).
This causes a problem where libraries without either a `codegenConfig` or a `react{ jsRootDir = ... }`
specified in the build.gradle will be invoking the codegen and generating duplicated symbols.
Changelog:
[Android] [Fixed] - RNGP - Properly set the `jsRootDir` default value
Reviewed By: cipolleschi
Differential Revision: D42806411
fbshipit-source-id: ffe45f9684a22494cc2e4d0a19de9077cb341365
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35982
This reflects better what the former `emitPartial` was doing - emitting an object with set props.
Changelog: [Internal] - Renamed emitPartial to emitObject
Reviewed By: christophpurrer
Differential Revision: D42740958
fbshipit-source-id: 4f974c6911bc129e698323a8039bbd7aa7602461
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35981
This reflects better what the former `emitObject` was doing - emitting a generic object.
It would also allow us to rename `emitPartial` to `emitObject` in the next diff whence the function name `emitObject` will be free.
Changelog: [Internal] - Renamed emitObject to emitGenericObject
Reviewed By: christophpurrer
Differential Revision: D42740871
fbshipit-source-id: 1b9112464695b8abeccc95eed908b0b45a0e3bf2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35984
[Changelog][Internal]
Codegen for props parsing was failing to add a required include for the case when the type is an array of objects, which in turn use non-trivial types.
Something like:
```
export type NativeProps = $ReadOnly<{
...ViewProps,
bounds: $ReadOnlyArray<
$ReadOnly<{
height?: Float,
left?: Float,
top?: Float,
width?: Float,
}>,
>,
}>;
```
would cause compilation errors on C++ side, since the required header for the `Float` conversion wasn't included.
Reviewed By: cipolleschi
Differential Revision: D42781128
fbshipit-source-id: d5b133b931a60e414761db0b3ed09893d3fcc9aa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35953
DimensionValue is a reserved prop type that can be a number or string (such as '50%'). On Java, it will get converted to a YogaValue (converter added to this diff); on C++ it will get converted to a YGValue (converter already exists as it's used in Fabric).
Changelog:
[Internal][Added] - Add codegen support for DimensionValue for components
Reviewed By: cipolleschi
Differential Revision: D42650799
fbshipit-source-id: 1d2bc30bbd93837dedbbb4c74f814963c8140957
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35961
Pull Request resolved: https://github.com/facebook/react-native/pull/35960
This fixes#35864
This feature allows using `$Partial<Obj>` in flow and `Partial<Obj>` in TypeScript based on the spec mentioned here: https://flow.org/en/docs/types/utilities/#toc-partial.
We currently only allow passing an Obj to Partial so
```
export type SomeObj = {
a: string,
b?: boolean,
};
export type PartialSomeObj = Partial<SomeObj>;
```
should work.
and also-
```
export type PartialSomeObj = Partial<{
a: string,
b?: boolean,
}>;
```
But not
```
export type PartialSomeObj = Partial<Partial<{
a: string,
b?: boolean,
}>>;
```
This can be improved in the future by a recursive unwrapping of the value inside the `Partial` annotation.
Changelog:
[General] [Added] - Allow the use of "Partial<T>" in Turbo Module specs.
Reviewed By: christophpurrer, cipolleschi
Differential Revision: D42640880
fbshipit-source-id: 03a3fccc38ccfc7a5440fe11893beb68e77753f3
Summary:
Just a couple of minor fixes in the `template/` folder:
- Remove a trailing space in `rn_edit_text_material.xml` (this was the _only_ trailing space present in a newly generated RN project), which results in the check against the empty tree object failing:
```
$ git diff --check 4b825dc -- template/
template/android/app/src/main/res/drawable/rn_edit_text_material.xml:23: trailing whitespace.
+ <!--
```
- Add missing newline at end of file in `.watchmanconfig` and `app.json` - Both are text files, and each line (including the last) is expected to end with a newline character (flagged by Git, and also visible as a warning on GitHub):
<img width="369" alt="image" src="https://user-images.githubusercontent.com/743291/214195867-81c8e622-2130-44d4-bdaf-588e3510c109.png">
## Changelog
[GENERAL] [FIXED] - Fix whitespace and newline at EOF in template
Pull Request resolved: https://github.com/facebook/react-native/pull/35939
Reviewed By: christophpurrer
Differential Revision: D42698256
Pulled By: rshest
fbshipit-source-id: 765fd41d4f501aec578755c754ea0ecb290ae6ca
Summary:
This adds support for `maintainVisibleContentPosition` on Android. The implementation is heavily inspired from iOS, it works by finding the first visible view and its frame before views are update, then adjusting the scroll position once the views are updated.
Most of the logic is abstracted away in MaintainVisibleScrollPositionHelper to be used in both vertical and horizontal scrollview implementations.
Note that this only works for the old architecture, I have a follow up ready to add fabric support.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Added] - Add maintainVisibleContentPosition support on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/35049
Test Plan:
Test in RN tester example on Android
https://user-images.githubusercontent.com/2677334/197319855-d81ced33-a80b-495f-a688-4106fc699f3c.mov
Reviewed By: ryancat
Differential Revision: D40642469
Pulled By: skinsshark
fbshipit-source-id: d60f3e2d0613d21af5f150ca0d099beeac6feb91
Summary:
Changelog:
[Internal][Added] - Add support for props of type Array<EdgeInsetsValue>
Reviewed By: christophpurrer
Differential Revision: D42651078
fbshipit-source-id: 3b8683ab199c3d590136cec0e6a67e9e85aaa2c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35790
This diff apply to RNTester the same logic we have in the template to control the `use_framework!` setting
This is a preliminary change to solve the `use_frameworks!` problems in the New Architecture for both the Template and RNTester.
## Changelog:
[iOS][Changed] - Align RNTester usage of the USE_FRAMEWORKS flag to the template
Reviewed By: cortinico, dmytrorykun
Differential Revision: D42387701
fbshipit-source-id: 28baf5a65b727269d55382de286a17de30e8895b
Nicola Corti
Pieter Vanderwerff
Moti Zilberman
Ana Margarida Silva
Ruslan Shestopalyuk
Riccardo Cipolleschi
Ruslan Lesiutin
Vitali Zaidman
Zihan Chen (MSFT)
Skander Ellouze
Christoph Purrer
Nick Gerleman
Deepak Jacob
shivenmian
Janic Duplessis
Gabriel Donadel Dall'Agnol
Saad Najmi
Genki Kondo
MaeIg
Frieder Bluemle
Marshall Roch
Mikhail Mikhaylov
