Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48595
Historically React Native used to include the JitPack repository be default in the default repositories.
This sadly exposes React Native projects to supply chain attacks as explained here:
https://blog.oversecured.com/Introducing-MavenGate-a-supply-chain-attack-method-for-Java-and-Android-applications/
Moreover, artifacts on Jitpack are not GPG signed it's complicated to verify the identity of artifact authors.
I'm introducing a Gradle property to control if Jitpack should be included by default or not.
User can control this behavior by changing their `gradle.properties` file as such:
```
includeJitpackRepository=false
```
The default value of this property is currently true, but we're looking into changing it to false in the future.
Changelog:
[Android] [Added] - Make the addition of JitPack repository configurable
Reviewed By: cipolleschi
Differential Revision: D68016028
fbshipit-source-id: 392513fef389a4835b4e00a8184459e00d51fdd0
Summary:
Adding .kotlin to gitignore. This folder starts to get used with K2 (with Kotlin 2.0) so we should be
adding it to the gitignore files
## Changelog:
[INTERNAL] - Add .kotlin to gitignore
Pull Request resolved: https://github.com/facebook/react-native/pull/48598
Test Plan: N/A
Reviewed By: cipolleschi
Differential Revision: D68018000
Pulled By: cortinico
fbshipit-source-id: 78be3597071d07d105145d8ba94cd83cbf4f21bc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48592
Changelog: [General][Added] Add support for the second parameter of `console.table` to specify a list of columns to print in the table.
Reviewed By: javache
Differential Revision: D67803665
fbshipit-source-id: 354476404bad7cd2d280c8b3d963d5acba41f86b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48591
Changelog: [General][Changed] Improved formatting of values logged via `console.table` (including Markdown format).
This provides several improvements over the format of tables logged via `console.table`:
* Markdown format for easy integration in existing documents.
* Increased alignment with the spec and Chrome/Firefox implementations:
* Added index columns.
* Logged all available columns.
* Format for all types of values (including objects, functions, etc.).
Reviewed By: javache
Differential Revision: D67794858
fbshipit-source-id: 464c938ed51f28a8e071bc46f0f5b0d970005873
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48589
Changelog: [internal]
Added basic tests for the current implementation of the `console.table` polyfill (not the CDP implementation).
Reviewed By: sammy-SC
Differential Revision: D67791579
fbshipit-source-id: 80d64903a92e87e0724ed302ec0521419f45f9a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48588
Changelog: [internal]
This has proved to be very CI and makes it fail a lot, so we're removing this for now.
Reviewed By: javache
Differential Revision: D67985917
fbshipit-source-id: 5ec7c1387ddfb8fb2a4e90450a98cb3caea9399f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48541
Shows how to use tintColor in conjunction with new XML file format, and serves as a good E2E test bench to ensure that drawables don't accidentally reuse the same state (if the underlying implementation isn't careful enough to call `buildCopy`, both icons will render red)
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D64136753
fbshipit-source-id: 3bd0933e587364425ac14a0635690d4b274a55fe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48523
Current AndroidTextInputShadowNode logic measures the height of the TextInput by fitting text into the constraints of the TextInput box. This results in the wrong height for single line TextInputs, since a single line TextInput is infinitely horizontally scrollable (whearas the outer TextInput component itself has a fixed width).
After this change, we measure text under single line textinputs with an infinite width constraint, then clamp to the final constraints of the TextInput, to better emulate what is happening under the hood.
iOS ended up solving this in a slightly different way, by measuring paragraph with `maximumNumberOfLines={1}` when not multiline, but think this is a bit more fraught. E.g. up until recently, it would have meant that the width could have been less than max width, depending on where line-breaking happened. I ended up duplicating the new logic to use for both instead (D66914447 will eventually deduplicate).
Changelog:
[Android][Fixed] - Fix incorrect height of single line TextInputs without definite size
Reviewed By: christophpurrer
Differential Revision: D67916827
fbshipit-source-id: b827185c4640835481794cb985c2b62dcf643abe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48570
Changelog: [internal]
We're still iterating on this feature and making sure it reports stable results, so marking it as `unstable` to set expectations.
Reviewed By: andrewdacenko
Differential Revision: D67975844
fbshipit-source-id: 41e93cb9cb0c887a96178e4a4d5078d1899b2478
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48573
changelog: [internal]
remove main.cpp for cxxreact/tests. It is not needed for tests to work and it breaks build for C++ only tests.
Reviewed By: javache
Differential Revision: D67975182
fbshipit-source-id: b9cbc5b5b6a87aafc69448e99877e664ed2d5af2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48560
changelog: [internal]
add tests for width and height and margin style. Covering percentage-based dimensions and invalid inputs.
The test coverage is needed to make removal of folly::tryTo safe.
Reviewed By: rubennorte
Differential Revision: D67942139
fbshipit-source-id: c1e517dfb102eea892c998cf6ff4190fa69cdfa7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48555
Changelog: [internal]
Small move to align with the existing convention.
Add `README.md` file for feature flags in JS directory, to link to canonical docs.
Reviewed By: huntie
Differential Revision: D67897751
fbshipit-source-id: d5091ab4537701ee5cfdf29ebd0fe79e858e3134
Summary:
We currently see this error message on console:
This will silence it by piping stderr to /dev/null
## Changelog:
[INTERNAL] - Silence the `eden info` output from react-native-codegen
Pull Request resolved: https://github.com/facebook/react-native/pull/48540
Test Plan: CI
Reviewed By: robhogan
Differential Revision: D67948411
Pulled By: cortinico
fbshipit-source-id: f805634a65713f4f9bc2dce6d781664e7564bc96
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48428
Changelog: [internal]
Adding a few more tests for `ReactNativeElement` for symmetry with future tests for when it implements `EventTarget`.
Reviewed By: javache
Differential Revision: D67738147
fbshipit-source-id: 04c8f3539fefd15f7c778986eb9e39f2c2386b6a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48545
RootViewManager is meant to be used by the internals of React Native, ther are no external usages. I'm internalizing it
changelog: [internal] internal
Reviewed By: christophpurrer
Differential Revision: D67952865
fbshipit-source-id: 4c7f7de01c4de7ae00f62bd4f5b49e0082ec3f2b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48533
Replaces the custom `XmlFormat` introduced in https://github.com/facebook/react-native/pull/46711 with the built-in support from Fresco. Fresco utilizes a very similar approach to load binary XML files and offers the XML format as part of its built-in `DefaultImageFormats`
Changelog:
[Android][Changed] - Replaced custom XML decoder with Fresco's built-in decoder
Reviewed By: NickGerleman
Differential Revision: D66553842
fbshipit-source-id: 096e60140f893d461be1cdb48e250749e58bbb4c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48542
Updates Fresco from 3.5.0 to 3.6.0. Picks up a few new features and bug fixes for XML drawables, including a required fix that [automatically supplies the XML drawable factory to Fresco's PipelineDraweeControllerBuilder](https://github.com/facebook/fresco/commit/e6b052610aab461601cfabc00f7240758a415878). Without this change, we cannot switch from RN's custom XmlFormat to Fresco's built-in format
Changelog:
[Android][Changed] - Update Fresco to 3.6.0
Reviewed By: NickGerleman, rshest
Differential Revision: D67950225
fbshipit-source-id: 9afd87565a5f069493c9c5ef87977cbd6d7cf3d4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48525
Fixes https://github.com/facebook/react-native/issues/48249
`TextMeasureCacheKey` hash and equality functions only incorporates the maximum width constraint. I'm guessing this was an attempt at an optimization, but it can lead to incorrect results in pretty trivial cases. E.g. if Yoga knows a definite size of `Text` in one dimension, and measures via `YGMeasureModeExactly`, we can have a minimum size corresponding specific to the style in which the text was laid out.
Changelog:
[General][Fixed] - Fix TextMeasureCacheKey Throwing Out Some LayoutConstraints
Reviewed By: christophpurrer
Differential Revision: D67922414
fbshipit-source-id: 0ee0220059fc4e4645b1684c42a0587fe728bedd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48511
{D60499583} added a new`onUserDrivenAnimationEnded` listener that requires `AnimatedValue` instances to have up-to-date values reported by `onAnimatedValueUpdate` (if native driver is in use).
Previously, the only way to ensure `onAnimatedValueUpdate` events were always fired to update JavaScript values in `AnimatedValue` instance was to attach a listener — even an empty one. This is exactly what D60499583 did: it traverses `props` for `AnimatedNode` instances and attaches listeners to them.
However, this is really inefficient and makes the code extra convoluted. Instead, this diff changes `AnimatedValue` so that it always subscribes to changes in `__attach`, and then it cleans up the extraneous props traversal and "empty listener" logic.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D67872307
fbshipit-source-id: e7d7e486bbfd9ef03e2dd9f201089e2f68b2dbb2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48529
These classes are identical and we already have a dependency on :uimanager in fabric.
Looking at OSS, I found no usages of `fabric.GuardedFrameCallback`.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D67913226
fbshipit-source-id: 97d7a9b45b877b98e9549c71135bd9b21386d78c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48520
Both `ReactScrollViewHelper.parseSnapToAlignment` and `ReactScrollViewHelper.parseOverScrollMode` accept a nullable string. This is a precursor to migrating these files to Kotlin (since they're already marked as nullsafe). The prop itself is a nullable string so this should be reflected in the native types as well
Changelog: [Internal]
Reviewed By: tdn120
Differential Revision: D67911553
fbshipit-source-id: aabe55c2dc65a933b170d76b89f62f25493ab0ee
Summary:
This PR guards code that enables/disables keyboard shortcuts only on iOS (iPadOS included).
## Changelog:
[IOS] [FIXED] - enable/disable keyboard shortcuts only on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/48518
Test Plan: CI Green
Reviewed By: rshest
Differential Revision: D67900442
Pulled By: javache
fbshipit-source-id: 249a7c3124d02d2c30303d218e2b26e987ae1f0f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48514
Currently, `AnimatedNode` implements logic to start listening to updates on the current native node if a listener is added.
However, the `startListeningToAnimatedNodeValue` native module method only supports native tags for instances of `AnimatedValue`, which is a subclass of `AnimatedNode`. In fact…
* On Android, [`startListeningToAnimatedNodeValue`](https://fburl.com/code/bdsl4sro) throws if the node is not an instance of `ValueAnimatedNode`.
* On iOS, [`startListeningToAnimatedNodeValue`](https://fburl.com/code/hlpk1rzk) does nothing if node is not an instance of `RCTValueAnimatedNode`.
As such, this refactors `AnimatedNode` to never manage this subscription for native nodes. Instead, the logic is moved into the `AnimatedValue` subclass, ensuring that we never accidentally try to `startListeningToAnimatedNodeValue` with non-`AnimatedValue` native tags.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D67884973
fbshipit-source-id: 5601efd8c29104a991301eabd97ddb88fd03c4a3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48513
While refactoring `Animated`, I noticed that many subclasses of `AnimatedNode` override `__attach` without invoking the superclass method, even though we do this for `__detach`.
In order to minimize surprise (e.g. if someone were to add logic into `AnimatedNode.prototype.__attach`), this diff updates all method overrides to invoke `super.__attach()`.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D67884975
fbshipit-source-id: f3a5456cf944d4d70ba1cfe7c44897c110e5fc7e
Summary:
Some of these parameters were incorrectly marked as nullable during the Kotlin migration
Changelog: [Internal]
Reviewed By: tdn120
Differential Revision: D67091825
fbshipit-source-id: c660164e41ba7d47f1d1d3dc28a01b79b7c8cb03
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48337
`SurfaceRegistryBinding` refers to a forked `SurfaceRegistry` we had for a while in bridgeless but which was merged back into `AppRegistry`. Align the native name as well to make it explicit that all this class does is call into `AppRegistry`.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D67342499
fbshipit-source-id: 797d8080611cb2576a2052999c2bf46d2eea9f72
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48336
`RN$AppRegistry` and `RN$stopSurface` are always set on the init path, regardless of bridgeless or not, so we can remove the fallback path and cleanup this code.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D67342498
fbshipit-source-id: db47e52fee5075f11258364d82474579d2bb21f4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48335
This API was never adopted or implemented on iOS, and is not compatible with bridgeless.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D67342500
fbshipit-source-id: a6740514d0347c0f497e1aa2f850328cc4607d24
Summary:
Time to migrate some of Hermes's instruments. I see that HermesMemoryDumper(`react/hermes/instrumentation/HermesMemoryDumper.h`) implements the interface on C++, ~but not sure if i need to update the `getId` call to just `id` (same with `getInternalStorage`) or if the interop between Kotlin and Java applies to these things as well. cortinico Any thoughts on your side would be appreciated.
HermesSamplingProfiler just became an object, since it was a singleton and a static anyway.
Here is what HermesMemoryDumper.h looks like:
<img width="1840" alt="Screenshot 2024-12-24 at 10 03 00" src="https://github.com/user-attachments/assets/d18e378a-9b23-47a9-83c9-402d29aeaa5f" />~
*Updated*: I ended up making them match the function signature on Cxx, because even if it does have that implicit behavior, doesn't feel right to tap into it like this.
## Changelog:
[INTERNAL] [FIXED] - Migrate HermesMemoryDumper and HermesSamplingProfiler to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/48378
Test Plan:
`/gradlew test`:
<img width="1840" alt="Screenshot 2024-12-24 at 09 54 29" src="https://github.com/user-attachments/assets/1b23fb6f-9da8-42e4-a348-7da868df77c1" />
Reviewed By: cortinico
Differential Revision: D67657481
Pulled By: philIip
fbshipit-source-id: 4fb5e003789d51d464d0cca5800704ea51324b69
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48487
[Changelog] [Internal] - Add getSurfaceProps helper method to SurfaceManager
When reload a reactHost we need to know which surface properties have been applied when starting the surface. This adds a utility function for that.
Reviewed By: rshest
Differential Revision: D67822459
fbshipit-source-id: 6d1f182514ed6e7ae8e31d3e1ca052c93bac2843
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48476
Command param array types were generating invalid schemas due to untyped parser code. The invalid schemas occurred for any alias type, including custom objects and basics like Int32. This was also inconsistent between Flow and TypeScript.
We already had one component utilizing this issue, so this just codifies that support into the schema so it reflects reality. This is only a partial solution. The more full solution would be to fully encode the custom types in the schemas like we do for Native Modules.
# More Information:
Tl;dr, DebuggingOverlay is abusing a FlowFixMe in codegen commands.
## The problem:
The [CodegenSchema](https://www.internalfb.com/code/fbsource/[d3ab2f79b377]/xplat/js/react-native-github/packages/react-native-codegen/src/CodegenSchema.js?lines=220) should be the source of truth for anything that can be in the schema. If something is in the schema that isn't allowed by the types, that's a bug. We have a bug. I'm adding compat-check support for components and it's blowing up on prod schemas because DebuggingOverlay causes an invalid schema.
## The details:
Support for Arrays as arguments in commands was added to the Codegen in D51866557. [Code Pointer](https://fburl.com/code/8yy1rm0p)
The intention appears to be to support arrays of primitives. There is a TODO for supporting complex types.
```
interface NativeCommands {
+addOverlays: (
viewRef: React.ElementRef<NativeType>,
overlayColorsReadOnly: $ReadOnlyArray<string>,
)
}
```
This support was added to TypeScript in D52046165 where it types the allowed Array arguments to be only
```
{
readonly type: 'ArrayTypeAnnotation';
readonly elementType:
| Int32TypeAnnotation
| DoubleTypeAnnotation
| FloatTypeAnnotation
| BooleanTypeAnnotation
| StringTypeAnnotation
};
```
However, because the Parsers are treating the input type as `any`, it isn't safe to pass through an input value into the schema as Flow won't catch mismatches.
The Flow parser just passes it through:
```
{
type: 'ArrayTypeAnnotation',
elementType: {
// TODO: T172453752 support complex type annotation for array element
type: paramValue.typeParameters.params[0].type,
}
```
Whereas the TypeScript parser has the more correct behavior of validating the inputs and returning specific outputs. Unfortunately, the return type is also typed here as $FlowFixMe, losing most of the benefits.
```
function getPrimitiveTypeAnnotation(type: string): $FlowFixMe {
switch (type) {
case 'Int32':
return {
type: 'Int32TypeAnnotation',
};
case 'Double':
return {
type: 'DoubleTypeAnnotation',
};
case 'Float':
return {
type: 'FloatTypeAnnotation',
};
case 'TSBooleanKeyword':
return {
type: 'BooleanTypeAnnotation',
};
case 'Stringish':
case 'TSStringKeyword':
return {
type: 'StringTypeAnnotation',
};
default:
throw new Error(`Unknown primitive type "${type}"`);
}
}
```
[DebuggingOverlay](https://fburl.com/code/zfe3ipq7) is abusing this gap in the Flow parser by sticking an Array of Objects in.
```
export type ElementRectangle = {
x: number,
y: number,
width: number,
height: number,
};
...
+highlightElements: (
viewRef: React.ElementRef<DebuggingOverlayNativeComponentType>,
elements: $ReadOnlyArray<ElementRectangle>,
) => void;
...
```
This isn't allowed in the schema, but it seems to fall through the holes of the flow parser and generators.
The resulting schema from Flow is this. Note the GenericTypeAnnotation which isn't allowed to be in the schema.
```
{
"name": "highlightElements",
"optional": false,
"typeAnnotation": {
"type": "FunctionTypeAnnotation",
"params": [
{
"name": "elements",
"optional": false,
"typeAnnotation": {
"type": "ArrayTypeAnnotation",
"elementType": {
"type": "GenericTypeAnnotation"
}
}
}
],
"returnTypeAnnotation": {
"type": "VoidTypeAnnotation"
}
},
```
The TypeScript parser fails with `Error: Unsupported type annotation: GenericTypeAnnotation`.
The generators don't seem to check beyond the ArrayTypeAnnotation so they fall through to generating generic arrays.
```
// ios
elements:(const NSArray *)elements
// android
ReadableArray locations
```
## So how do I fix this?
I think there are a couple of different options here. The key problem is that the Schema types need to represent reality of what can be in the schema.
1. We revert DebuggingOverlay to not use features that aren't supported (I assume nobody would be happy with this, but the change shouldn't have been made in the first place)
2. **(This is the approach taken in this diff)** We add MixedTypeAnnotation to the allowed types in Command arrays and have it generate that and add official support for that to the TypeScript parser as well. That is probably the quickest and easiest approach. It leaves the same type unsafety we have today on the native side.
3. NativeModules seem to have a lot more complex type safety here. They persist the alias type in the schema so that the CompatCheck can check them on changes. And then in C++ they generate structs and RCTConvert functions although for Java and ObjC it looks like they just use the same untyped native code. The matching approach here would be to add `aliasMap` and the whole data to the schema for commands, use that for the compat check, and still generate the same unsafe native code.
```
export type ObjectAlias = {|
x: number,
y: number,
|};
export interface Spec extends TurboModule {
+getAlias: (a: ObjectAlias) => string;
}
```
stores the ObjectAlias in the schema
```
{
"aliasMap": {
"ObjectAlias": {
"type": "ObjectTypeAnnotation",
"properties": [
{
"name": "x",
"optional": false,
"typeAnnotation": {
"type": "NumberTypeAnnotation"
}
},
{
"name": "y",
"optional": false,
"typeAnnotation": {
"type": "NumberTypeAnnotation"
}
},
]
}
},
"spec": {
"methods": [
{
"name": "getAlias",
"optional": false,
"typeAnnotation": {
"type": "FunctionTypeAnnotation",
"returnTypeAnnotation": {
"type": "StringTypeAnnotation"
},
"params": [
{
"name": "a",
"optional": false,
"typeAnnotation": {
"type": "TypeAliasTypeAnnotation",
"name": "ObjectAlias"
}
}
]
}
}
]
}
}
```
and then generates the appropriate structs on the native side and generates [this](https://www.internalfb.com/code/fbsource/[d3ab2f79b377]/xplat/js/react-native-github/packages/react-native-codegen/src/generators/modules/__tests__/__snapshots__/GenerateModuleHObjCpp-test.js.snap?lines=818)
```
Reviewed By: hoxyq
Differential Revision: D67806838
fbshipit-source-id: 31f20455c816fdb6b1a86f8f9d0f6f7d0a452754
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48475
This will be needed for the compat-check.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D67806831
fbshipit-source-id: b660c9557cafbfa2e713e85a0fd2bdc9edabf537
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48474
The previous definition said that you could put prop types into commands, which definitely isn't allowed.
For example, the schema would have allowed `WithDefault` types.
```
interface NativeCommands {
+methodInt: (viewRef: React.ElementRef<NativeType>, a: WithDefault<string, 'hi'>) => void;
}
```
This change separates out the things that are allowed in commands from what's allowed in props.
Commands should be very similar to what's allowed in native modules, but it isn't exact enough to be able to merge those.
## Changelog:
[General][Breaking] - Codegen: Separate component array types and command array types
Reviewed By: cipolleschi
Differential Revision: D67806818
fbshipit-source-id: 58e504fe2e2e5efa612e836b18af22a167e7ae2f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48473
This is such a simpler approach lol.
I'll need this later for when I want to pass in arrays or objects of these types to the compat check
Changelog: [internal]
Reviewed By: cipolleschi
Differential Revision: D67806812
fbshipit-source-id: 5cc361815fea901098d2931ba78293693ecc0a35
Nicola Corti
Rubén Norte
Samuel Susla
Jakub Piasecki
Peter Abbondanzo
Nick Gerleman
Alex Hunt
David Vacca
Tim Yung
Pieter De Baets
Oskar Kwaśniewski
Parsa Nasirimehr
generatedunixname89002005232357
Christoph Purrer
Eli White