Summary:
In this diff I'm integrating 'org.jetbrains.kotlinx.binary-compatibility-validator' into RN Android build gradle system.
The tool allows dumping binary API of a JVM part of a Kotlin library that is public in the sense of Kotlin visibilities and ensures that the public binary API wasn't changed in a way that makes this change binary incompatible
More context on https://github.com/Kotlin/binary-compatibility-validator#building-the-project-locally
bypass-github-export-checks
Reviewed By: cortinico
Differential Revision: D51262577
fbshipit-source-id: 1894f4e55a4019e3ce1585e9df12dee69944e5ce
Summary:
When working with Verdaccio (testing the template, releasing packages) - I've stumbled upon a lot of changes in the repo:

## Changelog:
[INTERNAL] [ADDED] - Add verdaccio generated files to .gitignore
Pull Request resolved: https://github.com/facebook/react-native/pull/41783
Test Plan: CI Green
Reviewed By: christophpurrer
Differential Revision: D51808583
Pulled By: huntie
fbshipit-source-id: fec2a13883590d0c6af179c3804fba9d4235dde2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41767
Changelog: [Internal]
Adds a simple example showing a direct recursive node in a Cxx TM.
Currently we can't auto-generate [the necessary C++ Types](https://reactnative.dev/docs/next/the-new-architecture/cxx-custom-types#struct-generator) - but we can add it later if this scenarios becomes really common.
Direct recursive nodes, can't be value types - it would require infinite memory. Hence they are nullable and managed by a smart pointer.
Reviewed By: rshest
Differential Revision: D51784136
fbshipit-source-id: f6f0710d03583bdf1e6e72ba42d8df7f8ff8d915
Summary:
Was stepping with debugger through the code & noticed few typos.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[ANDROID] [FIXED] - Typos in `ReactCompoundViewGroup` comments
Pull Request resolved: https://github.com/facebook/react-native/pull/41729
Test Plan: Typos in docs
Reviewed By: cortinico
Differential Revision: D51753447
Pulled By: arushikesarwani94
fbshipit-source-id: b373d67ca8b6c9f22d80ea1ccee98ecc5151b325
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41733
I am currently implementing position: static in Yoga. I have a huge stack of changes that is ready to ship but we are waiting on the default position type to be relative before shipping. The reason being, my changes will affect a whole ton of styles where there is no position set so if we can make static no longer the default we can safely ship this new code. However, this will take a while and keeping up with this stack of diffs though merge conflicts, flakey tests, and general slowness for my IDE is getting annoying. So a solution here is to ship that stack and make it so that no one gets this functionality by changing the strict layout conformance to include the errata that is gating my changes. The end result being that the code can be shipped but will have no affect at the time being.
Right now, because that code is in a different branch and not on prod, this change will do nothing.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D51731778
fbshipit-source-id: f0b7fd8559adb19e1658b3ac64fcfc4c5f8ecdf7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41739
Refactoring `DefaultReactNativeHost` to use the new way of Fabric initialization through `FabricUIManagerProviderImpl`
Reviewed By: philIip
Differential Revision: D51719555
fbshipit-source-id: bad471a8a273accecb0641ccaa77223534cd45fd
Summary:
iOS?ios?android?Android?
Always making typos when using the local testing script with the platform argument... No more!
## Changelog:
[INTERNAL][ADDED] - Improved E2E local testing script to be more flexible
Pull Request resolved: https://github.com/facebook/react-native/pull/41751
Reviewed By: cortinico
Differential Revision: D51758529
Pulled By: huntie
fbshipit-source-id: d9e633567a59fcfac1057cf1f21714ccef27ebb2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41738
Replacing the callsite to `context.getFabricUIManager()` in UIManagerHelper instead of `getJSIModule()`
Fixing the crash by directly making `getFabricUIManager()` of `ReactContext` independent of the assertion.
Reviewed By: philIip
Differential Revision: D51719040
fbshipit-source-id: f9118b16614724a1d6dabe59d5c4d25dd4bdbc73
Summary:
Currently React Native defines `NDEBUG` flag for all pods in Fabric only. This is useful for other libraries, like Reanimated, because they have no easy way of defining their compilation flags (at least none that I know of). Therefore defining `NDEBUG` for both architectures would be beneficial.
## Changelog:
Pick one each for the category and type tags:
[IOS] [CHANGED] - Add `NDEBUG` flag for Release builds for both architectures
Pull Request resolved: https://github.com/facebook/react-native/pull/41715
Test Plan:
Run ruby test suite.
## Notes
For the time being I just copied
`prepare_pod_target_installation_results_mock`
and
`def prepare_installer_for_cpp_flags`
to `utils-test.rb` since I wasn't sure how to handle the installer mock.
Reviewed By: cortinico
Differential Revision: D51708382
Pulled By: cipolleschi
fbshipit-source-id: ff206f8fc151934dbae89aacd1bc69c57b4f28ee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41720
We currently go via the UI thread, so we can use AsyncTask to schedule the final bit of async ReactContext destruction. This is a requirement for the AsyncTask API, which is also deprecated. We should figure out a better way to schedule and re-use threads across React Native Android, but until then, we can just create a new Thread here, which is also what we do for instance creation.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D51706689
fbshipit-source-id: cf17e20e91b195b956b1701e6d91d563fdba4d15
Summary:
This PR fixes typo in CircleCI config
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [FIXED] - Typo in circleci config
Pull Request resolved: https://github.com/facebook/react-native/pull/41727
Test Plan: CI Green
Reviewed By: cipolleschi
Differential Revision: D51748329
Pulled By: cortinico
fbshipit-source-id: 99f54c5b9ec4113205642076c010b748ab6229f6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41728
Adding APIs for `getFabricUIManager()` to ReactContext and it's subclasses. This will replace the `getJSIModule()` post JSI module deletion.
Reviewed By: philIip
Differential Revision: D51718430
fbshipit-source-id: c897ab0ee9e755e3fdb3d1e5629177818870f293
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41732
Was reading the code in this file and noticed that this comment is no longer true after D51068417 (https://github.com/facebook/yoga/pull/1460). Updated the comment to reflect the current state of things
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D51730986
fbshipit-source-id: beaa5de9576d86e56def35f6e970376c7be8f7ee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41712
I fixed the const correctness of YGConfigGetErrata a while back when fixing up other YGConfig accessors.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D51689323
fbshipit-source-id: 1af3deb44ec03a8a65643fa1496c534ac8f6d057
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41436
Add a JSI API for associating some native memory with a JS object. This
is intended to provide a mechanism to trigger more frequent garbage
collection when JS retains large external memory allocations, in order
to avoid memory buildup.
This diff just adds the JSI method, without any implementations.
Changelog:
[General][Added] - Added JSI method for reporting native memory to the GC.
Reviewed By: tmikov
Differential Revision: D50524912
fbshipit-source-id: c8df0e18b0415d9523e0a00f6d0ed2faa648ac68
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41719
We leak ReactInstanceManager into a static singleton in `ReactCxxErrorHandler.setHandleErrorFunc`. Clean it up in `destroy()`.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D51706624
fbshipit-source-id: 642825ba14ff0a9710b4435f5fb6026b3a81b711
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41704
`mOnViewAttachItems` was set to be be concurrent, but this would be unexpected, as all mount item operations occur solely on the main thread.
Simplify this to be just a LinkedList and annotate the methods as being UI thread only.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D51662154
fbshipit-source-id: 9fe5784bce8a38d1339b5e3675791414676b6f4d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41711
We want the default position to be relative for a number of reasons. This should be fine for the most part but putting a killswitch around this change just in case things blow up.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D51643446
fbshipit-source-id: 4f7d1e498eb663801ef6d88ba9cd9b64c781d66b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41709
We shipped these new create()/reload()/destroy() methods to the Facebook app:
- Part 1: D50802718
- Part 2: D50803283
This diff just enables them everywhere, by default.
Created from CodeHub with https://fburl.com/edit-in-codehub
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D51590843
fbshipit-source-id: 02abeea78b7b7b844552989ad58d0a2f048424ad
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41700
The type definition of `useMergeRefs` is incorrect, which forces all callsites to use `$FlowFixMe`. This fixes the definition and removes all the `$FlowFixMe`s caused by it.
Changelog: [internal]
Reviewed By: javache
Differential Revision: D51660716
fbshipit-source-id: 4d4d3a72bdca8c409fd1dda59cc2c94113b024bb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41701
I did a hotfix for this logic in D51618512. This does a small refactor to improve the code (moving more shared code to the hook and avoiding creating a closure unnecessarily in every call to it).
Changelog: [internal]
Reviewed By: javache
Differential Revision: D51660288
fbshipit-source-id: 472836840b19958402bd0de3e2c09c7cec004156
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41695
When I went to update documentation, I kinda internalized how inconsistent the API is if we don't change iOS Paper.
The potential for breaks is if an iOS-specific component ignores a warning, and uses `onScroll` without `scrollEventThrottle`, then relies on `onScroll` only being called once.
It didn't seem like we hit this scenario in practice when migrating Fabric ComponentView behavior, and components will need to support it in new arch anyway, so this change takes the less conservative option of unifying the behavior everywhere.
Changelog:
[iOS][Changed] - scrollEventThrottle no longer needs to be set for continuous scroll events
Reviewed By: cipolleschi
Differential Revision: D51647202
fbshipit-source-id: e2a57f3501b9096e4033cb198bbc214d53e9913c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41681
## Rationale
Make initHybrid static. So that the derived class can initialize the C++ part with constructor arguments.
**Note:** This diff just applies the fix from D51550623. into CxxReactPackage.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D51642219
fbshipit-source-id: 095e452e03848379288af960969789aa5e9c0542
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41708
RN-Tester is currently instacrashing due to a method accepting a `Float?` rather than a `Float`.
`Float` from Kotlin gets converted to Java's `float`, while `Float?` gets converted to the boxed type, which is not recognized by the framework and is making the app crash.
On top of this, the implementation of `setColor` was wrong as we don't properly handle the null case. Fixing it here as well.
Changelog:
[Internal] [Changed] - Fix broken RN Tester custom ViewManager
Reviewed By: NickGerleman
Differential Revision: D51667346
fbshipit-source-id: b7498a520936f81a0524ba53dc7230ad7ef57bf8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41706
This change introduces a ReadME in the CircleCI folder.
This can be used as documentation to learn more about our CircleCI setup and will also help GitHub employees in executing the migration.
## Changelog:
[Internal] - Add CircleCI documentation
Reviewed By: cortinico
Differential Revision: D51665453
fbshipit-source-id: f61325ed26572c4a8d4a68db1cca5934d3d968fb
Summary:
Currently, when we have an additional platform in `react-native.config.js`, users cannot use custom `resolver.resolveRequest` functions as they are overwritten by `reactNativePlatformResolver`. Goal of this PR is to allow OOT platforms to use additional custom resolvers besides remapping react native imports.
## Changelog:
[GENERAL] [FIXED] - Allow Out Of Tree platforms to pass custom resolvers
Pull Request resolved: https://github.com/facebook/react-native/pull/41697
Test Plan:
1. Add additional platform in `react-native.config.js`
2. Pass custom resolver to `metro.config.js`:
```js
resolveRequest: (context, moduleName, platform) => {
console.log('resolveRequest', moduleName, platform);
return context.resolveRequest(context, moduleName, platform);
}
```
3. Check if user's `resolveRequest` function is called.
Reviewed By: huntie
Differential Revision: D51659721
Pulled By: robhogan
fbshipit-source-id: 952589b59a6fa34e9406d36c900be53a7c1a79c3
Summary:
This is my proposed solution to https://github.com/facebook/react-native/issues/41677.
Fixes https://github.com/facebook/react-native/issues/41677.
## Changelog:
[ANDROID] [FIXED] - Fix android root view group removal during instance re-creation
Pull Request resolved: https://github.com/facebook/react-native/pull/41678
Test Plan:
Both with fabric enabled and disabled (new architecture):
1. Clone repro repo: https://github.com/wschurman/rn-reload-repro
2. Build and run on android (I use android studio)
3. Click reload button, see timestamp doesn't change (indicating that the view is not removed)
4. Apply this PR as a patch.
5. Re-build and run.
6. Click reload button, see view is correctly disposed of and the new view is set.
Reviewed By: cortinico
Differential Revision: D51658524
Pulled By: javache
fbshipit-source-id: d9a026cde677ad1ec113230bc31bd9297bca8bfc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41698
With the previous changes on the Pod configuration, the build setup for the New and Old architecture are the same.
The only observable difference happens at runtime.
This change:
1. Removes the build job that are split by architecture (which is now duplicated work)
2. Add two more test jobs to run runtime tests (unit and integration test) to make sure that the two architectures continue working.
## Changelog:
[Internal] - [CI] Remove duplicated build jobs, add tests jobs
Reviewed By: cortinico
Differential Revision: D51659275
fbshipit-source-id: 769c9ee004e7f4f1a7444f39c02b7083e007b780
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41669
In some previous changes ([a607692](https://github.com/facebook/react-native/commit/a6076924bf43dff6cf4d38d51df279edba3882d0) and [6b53205](https://github.com/facebook/react-native/commit/6b5320540adfe16803ef41353f23115d08819309)) we make sure to always include all the pods (including Fabric) and we unify codegen to run in the same way on both architectures.
While doing so, we enabled codegen to run on libraries tat already migrated to Fabric.
These makes those libraries to fail when building as they were not including the Fabric code when the New Architecture is disabled.
This change will make sue that the code is always included, thus the library should always build, and it also make sure that we can control the New/Old Architecture at build time.
## Changelog
[iOS][Changed] - Make sure that libraries always include Fabric code also in the old architecture
Reviewed By: dmytrorykun
Differential Revision: D51617542
fbshipit-source-id: 883d1e258c341feb0405ad389bb8af34d64b59b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41496
Refactoring `DefaultReactNativeHost` to use the new way of Fabric initialization through `FabricUIManagerProviderImpl`
Reviewed By: christophpurrer
Differential Revision: D51224854
fbshipit-source-id: 2af8021404365fa2adc9388f44bcc7c6301137dc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41676
This has been used in a significant amount of production for about 2 months, with no consistently statistically significant metric impact. Let's ship it.
Note that we would not want to keep this change in a holdout if we remove the warning, since new usages could be added that relied on the behavior not in the holdout.
It didn't seem worth the churn to make the same change to Paper, which leaves a question on how to handle the JS-side warning. Instead of jimmying in impl detection, I thought it might be more sane to remove the warning, though that also has a potential hit to Paper DevX.
Changelog:
[iOS][Changed] - `scrollEventThrottle` no longer needs to be set for continuous scroll events when using the new architecture.
Reviewed By: javache
Differential Revision: D51608970
fbshipit-source-id: 193019de208f3088519e6f6333dbec4e6b45a1eb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41693
This diff fixes app warm start time. Before this change, we cache the first time when app start timing is logged, and ignore future loggings. Some apps are warm started and the startup time should be updated.
Reviewed By: dmitry-voronkevich
Differential Revision: D50481710
fbshipit-source-id: 03e00b75ee7ac578209ae3478adabe567e92a950