Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38987
As now we do have the buildTools version 34 in the docker container,
I'm bumping compileSdkVersion for all the targets to 34.
I'm also cleaning up the `test_windows` setup as it had old references
of NDK 20, build tools 33 and was installing the Android SDK but not
actually using it.
Changelog:
[Android] [Changed] - Bump Android compile-sdk to 34
Reviewed By: cipolleschi
Differential Revision: D48311828
fbshipit-source-id: c5b1d20a6183b577fba520af95b33e7656477101
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38958
changelog: [internal]
This is an unnecessary abstraction, let's remove it.
It originally served as a retry mechanism for C++ state update but it no longer serves that purpose. It obscures visibility into StateWrapper state.
jest_e2e[run_all_tests]
Reviewed By: mdvacca, luluwu2032
Differential Revision: D47993140
fbshipit-source-id: 81e81153d2de90f69d1495b14db66ee66670ba0f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38988
- Upgrade to RN CLI `12.0.0-alpha.9`, including Metro bump to `0.78.0`.
- Update test scripts, since this CLI release made a breaking change to the `/status` response.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D48311214
fbshipit-source-id: bb0be3c32edb629355b9fbbd754b28f9878f47ef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39004
Adds `flow` to this file. Even thought it is a stub, it still deserves to be checkable by Flow.
Changelog:
[Internal]
Reviewed By: SamChou19815
Differential Revision: D48325186
fbshipit-source-id: a3417bfa12258b85c1eb51744348a1c8aba63a8c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38990
This PR adds auto-generation of Typescript definitions from Flow source code for packages using the shared monorepo build setup (https://github.com/facebook/react-native/pull/38718).
Today, these are the following Node.js packages:
- `packages/community-cli-plugin`
- `packages/dev-middleware` (⬅️ `emitTypeScriptDefs` enabled)
This also improves emitted Flow definitions (`.js.flow`), by using [`flow-api-translator`](https://www.npmjs.com/package/flow-api-translator) to strip implementations.
**All changes**
- Include `flow-api-translator` and configure this to emit type definitions as part of `yarn build`.
- Add translation from Flow source to TypeScript definitions (`.d.ts`) adjacent to each built file.
- Improve emitted Flow definitions (`.js.flow`), by using `flow-api-translator` to strip implementations (previously, source files were copied). The Flow and TS defs now mirror each other.
- Add `emitFlowDefs` and `emitTypeScriptDefs` options to build config to configure the above.
- Integrate TypeScript compiler to perform program validation on emitted `.d.ts` files.
- This is based on this guide: https://github.com/microsoft/TypeScript-wiki/blob/main/Using-the-Compiler-API.md#a-minimal-compiler.
- Throw an exception on the `rewritePackageExports` step if a package does not define an `"exports"` field.
- Add minimal `flow-typed` definitions for `typescript` 😄.
**Notes on [`flow-api-translator`](https://www.npmjs.com/package/flow-api-translator)**
This project is experimental but is in a more mature state than when we evaluated it earlier in 2023.
- It's now possible to run this tool on our new Node.js packages, since they are exclusively authored using `import`/`export` syntax (a requirement of the tool).
- As a safety net, we run the TypeScript compiler against the generated program, which will fail the build.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D48312463
fbshipit-source-id: 817edb35f911f52fa987946f2d8fc1a319078c9d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38706
Fabric has a mechanism to resolve conflicts when there are race conditions committing new versions in different threads. This mechanism forces commits to be done in order, retrying commits when they didn't have time to finish before another concurrent commit.
{F1061612667}
This mechanism has an important drawback. If we have a continuous stream of short commits (e.g.: animations via Reanimated) and we want to do a large commit (e.g.: coming from React), the large commit could exhaust all attempts to finish and ultimately fail. Every time we tried to commit the large one, another small one would have had a chance to finish, forcing another retry.
{F1061614717}
In most of the cases where this happens, we didn't even need to fail the commits in the first place!
**The only reason why we retry commits is so we make sure we are propagating the last state** (when state propagation is enabled in that commit). We don't reconcile the contents of the commits themselves (the tree we retry is exactly the same, if we exclude state).
We can reduce the number of reconciliation failures (and completely remove them in the case of animations) if instead of checking if the base revision for a commit changed, we checked if the version of the state we propagated changed.
We would have 3 scenarios when doing that:
1. Commit creating state vs. commit reusing state. If the commit creating the state went first, we would have to retry the commit reusing the state (to make sure we're reusing the new state). If the commit reusing the state went first, we wouldn't have conflicts, and we would just apply the new state on top of it. {F1061617730}
2. Commit reusing state vs. another commit reusing state. In this case the order doesn't matter and we don't need to trigger a conflict. Commits would be updated in the order in which they are applied. {F1061618406}
3. Commit creating state vs. commit creating state. In this case, we are not propagating state, so retrying the commits wouldn't do anything. We can ignore the conflicts in this case too. {F1061618689}
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D47915384
fbshipit-source-id: bb4510c59bf32ca342c02f3bdb7029b545f56d99
Co-authored-by: Samuel Susla <samuel.susla@gmail.com>
Co-authored-by: David Vacca
Co-authored-by: Tomek Zawadzki <tomasz.zawadzki@swmansion.com>
Co-authored-by: Krzysztof Piaskowy <krzysztof.piaskowy@swmansion.com>
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38886
This change introduces a property called `react.internal.useHermesNightly`
This allows users building RN-Tester or just ReactAndroid to fetch Hermes from the latest
nightly, without having to build it from source.
The change could be useful to speedup local development, but it should not be enabled on CI or when doing releases.
Changelog:
[Internal] [Changed] - Introduce react.internal.useHermesNightly
Reviewed By: mdvacca, cipolleschi
Differential Revision: D48188769
fbshipit-source-id: cb4330cb9082e9db0c7ba82e48b2d10030637353
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38924
## The Problem
We're currently compiling React Native with two JDK, 11 and 17.
This is necessary as we use PowerMock to mock static classes in our tests. PowerMock is effectively unmaintained and is preventing us from using only JDK 17.
Using two JDKs requires a bigger docker container and leads to build failures when contributors try to contribute to RN so we should be moving to use only a single JDK (also we can expect Google to bumpthe requirement to JDK 21 at some point in the future).
## The Solution
Practically, Mockito 3 offers the same capabilities that PowerMock offers.
I've removed PowerMock from our codebase and bumped Mockito to 3.
I've verified that all the un-ignored tests are green both with Gradle and Buck.
I've updated the Ignore-d tests to don't use PowerMock (as the project won't compile otherwise).
When we un-suppress them we will have to make sure everything works.
I've also left some TODOs referencing the old code for the future.
Changelog:
[Internal] [Changed] - Bump Mockito to 3.x and remove PowerMock
Reviewed By: cipolleschi
Differential Revision: D48228603
fbshipit-source-id: 5d4af902d813f347f19fc17361d53a73b685544d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38885
We do have several Gradle Properties that are used to configure the build.
I've refactored them all and moved them inside the PropertyUtils file:
https://github.com/facebook/react-native/blob/main/packages/react-native-gradle-plugin/src/main/kotlin/com/facebook/react/utils/PropertyUtils.kt
Specifically properties should be 'scoped' under `react.` if public, and `react.internal.` if for internal usage.
Property that I cleaned up are:
- REACT_NATIVE_MAVEN_LOCAL_REPO becomes react.internal.mavenLocalRepo
- REACT_WINDOWS_BASH becomes react.internal.windowsBashPath
- GROUP becomes react.internal.publishingGroup
I've also added support for scoping for public properties with backward compat (so both the scoped and unscoped properties are accepted):
- react.newArchEnabled
- react.hermesEnabled
- react.nativeArchitectures
Changelog:
[Android] [Changed] - Cleanup and scope all the Gradle Properties
Reviewed By: mdvacca
Differential Revision: D48188310
fbshipit-source-id: 1a92d31105270a4c2f80029b7d36bcb33916d0fb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38973
Original commit changeset: 6c00c2fcfdfd
Original Phabricator Diff: D47852371
When #38674 and #38959 are combined, they cause Android apps on Fabric to crash. #38959 is the more urgent fix, so backing out #38674.
## Changelog:
[General] [Fixed] - Rolling back change that broke e2e tests until we can figure out why the e2e tests are broken
Reviewed By: NickGerleman
Differential Revision: D48288752
fbshipit-source-id: b52e28936bbebd21bd3b2f49f9a233f295ba6248
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38968
A previous change introduced a bug where elevation was no longer being parsed on Android, which caused views that were previously flattened to no longer get flattened. This is a hotfix that could be pushed to affected builds without native code changes, but will not restore the shadow UX.
## Changelog:
[General] [Internal] - Internal
Reviewed By: bvanderhoof
Differential Revision: D48271545
fbshipit-source-id: ebbecd8073a074525ff7b95a6298612d0bb304c6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38940
## Changelog:
[Internal] - make notch detection more future proof
current implementation of `isIPhoneX_deprecated` is not completely correct and is already 2 iphones behind. i update the implementation so we don't have to change it with every new iphone that comes out.
Reviewed By: cipolleschi
Differential Revision: D48254737
fbshipit-source-id: a7f45d70b06ab6c6d4fe036885c8a623fed0958e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38962
Changelog: [General][Changed] Math.floor the top and bottom dimensions of a cell item when determining viewability.
Reviewed By: NickGerleman
Differential Revision: D48212402
fbshipit-source-id: 0ba7d5c218477c257a4504391940d916e4832f91
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38674
Changelog: [Internal] - Refactor conditional pointer event emitting to the C++ layer
Some background: early on in the implementation of Pointer Events a concern was brought up that events related to hovering pointers could saturate the JS thread if they were fired all the time unconditionally, so as a mitigation we would check in native to see if listeners in the tree were listening for those events and only fire them if there were listeners.
Now since we're going to be moving some of the event derivation logic to the C++ layer we need to receive all the events — but recreate the conditional firing in the C++ layer so we can still avoid saturating the JS thread. That's what this diff does.
The only change I see being potentially contraversial is the fact that I needed a way to turn an `EventTarget` (the only information I receive regarding which node the event is firing on) to its cooresponding `ShadowNode` which I did in the method `GetShadowNodeFromEventTarget`. It essentially does the exact same thing the `getNodeFromInternalInstanceHandle` method in `ReactNativePublicCompat.js`, but in C++ against the JSI API. I don't know if there's a better way to do this but this was the best one I came up with that actually works.
Reviewed By: NickGerleman
Differential Revision: D47852371
fbshipit-source-id: 6c00c2fcfdfd49314c96d044d36272e028e074ff
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38955
Jest introduced "modern" timers based on `sinon/fake-timers` in Jest 26 ([release announcement](https://jestjs.io/blog/2020/05/05/jest-26#new-fake-timers)), and they became the default in Jest 27, in May 2021.
Modern timers have more capabilities - they were introduced with support for `queueMicrotask`, mocking `Date`, etc., and they've continued to receive more attention from the Jest team since - they're now much more comprehensive and more configurable than legacy timers.
Importantly, because they're not based on Jest mocks, they're not affected in surprising ways by eg `jest.resetAllMocks()` (a particularly confusing side-effect when fake timers are enabled globally, as in our setup).
This migrates RN's own tests and config to modern fake timers, or real timers where that's more appropriate.
NOTE: In cases where non-trivial changes to the tests are required, four test files are individually opted-in to `legacyFakeTimers` with a `TODO(legacy-fake-timers)`. I'll open these up for community contributions to fix.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D48189907
fbshipit-source-id: 2e7ce74cc60e80679d81d7c16d599ad1bbe2c921
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38945
Another pass of moving version numbers into a single place.
This time I've moved all the native dependencies from gradle.properties to the version catalog
Changelog:
[Internal] [Changed] - Consoliate Native deps version inside the Version Catalog
Reviewed By: cipolleschi
Differential Revision: D48263910
fbshipit-source-id: 0743908282dc658e2da347052e3b721704859f12
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38949
I've done another pass and moved all the compileSdk/minSdk/targetSdk and buildToolVersion in a single place so that we can easily bump one for all the projects.
Changelog:
[Internal] [Changed] - Consoliate Android SDK version inside the Version Catalog
Reviewed By: cipolleschi
Differential Revision: D48263891
fbshipit-source-id: bb9565cded37bae986865f37f4891575396128d0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38946
I'm doing another pass of moving all the various version numbers of the Gradle Plugin inside the `[plugins]` section of the version catalog.
Changelog:
[Internal] [Changed] - Consolidate Gradle Plugin versions inside the version catalog
Reviewed By: mdvacca
Differential Revision: D48233147
fbshipit-source-id: afd12e5377d2d88c53cef4e6913b5c49b3da5bbb
Summary:
Migrate MyNativeViewManager to kotlin as part of ☂️https://github.com/facebook/react-native/issues/38825
## 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][Changed]: Migrate MyNativeViewManager to kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/38916
Test Plan: Verify RN Tester runs with `yarn android`
Reviewed By: cortinico, NickGerleman
Differential Revision: D48221141
Pulled By: mdvacca
fbshipit-source-id: 1cc5dc4346f265883e79893b69f0da5e8c632f2a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38927
I've done a pass and fixed most of the warnings for Gradle 9:
- project.buildDir is deprecated in favor of project.layout.buildDirectory
- I've updated 3rd party Gradle Plugins that we depend on
There are still two warnings which are outside of our control:
1. One is inside AGP and will be fixed with AGP 8.2 - Source https://issuetracker.google.com/issues/279306626
2. Another one is inside nexus-publish and should ideally be fixed by 2.0 https://github.com/gradle/gradle/issues/25206 Will bump the release once it's out
Changelog:
[Internal] [Changed] - Fix warnings for Gradle 9
Reviewed By: mdvacca
Differential Revision: D48231760
fbshipit-source-id: 27d704324ea33cfc8aa0164fa437b80aab425960
Summary:
{D47225928} introduced a bug affecting `TextInput` on iOS that prevented native text editing capabilities. This reverts the change to a previous incarnation of the diff where javache created a new `blockNativeResponder` option instead of piggybacking off the existing `cancelable` option.
Changelog:
[iOS][Changed] - Restored `cancelable` option in `Pressability` configuration to not block native responder, and instead introduced a new optional `blockNativeResponder` boolean option to accomplish the same thing.
Reviewed By: mdvacca
Differential Revision: D48246530
fbshipit-source-id: 8a406d462cce0e5e5a108607e1ac1d3203ea229c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38930
As we migrate java to kotlin I noticed that we've introduced few warnings here and there.
I'm introducing a way to configure allWarningsAsErrors in gradle
changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D48238321
fbshipit-source-id: 745847bc6e6df94decc54afa8c9041552d91dfee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38505
Changelog: [Internal] - Add initial Pointer Capture API implementation
This diff introduces the first baseline implementation of pointer capturing through intercepting/modifying Pointer Events in flight through the `PointerEventsProcessor` class.
Firstly: This adds and exposes the imperative methods `setPointerCapture`, `releasePointerCapture`, and `hasPointerCapture` which is added to the host `ReadOnlyElement` ref API. These methods are used to manage/query the `pendingPointerCaptureTargetOverrides_` map as [defined in the spec](https://www.w3.org/TR/pointerevents/#setting-pointer-capture).
The code is fairly self-explainatory when it comes to retargeting the events in `PointerEventsProcessor::interceptPointerEvent` but when it comes to firing the `gotPointerCapture` and `lostPointerCapture` events those are handled in `PointerEventsProcessor::processPendingPointerCapture` and is a fairly direct implementation of [the spec's pseudocode](https://www.w3.org/TR/pointerevents/#process-pending-pointer-capture).
Finally at the end of `interceptPointerEvent` I've included the basics of implicit pointer capture *release* as per [the spec](https://www.w3.org/TR/pointerevents/#implicit-release-of-pointer-capture) (note that implicit pointer capture is not yet implemented).
Reviewed By: rozele
Differential Revision: D47533366
fbshipit-source-id: 1786f9703a88201bc9c7bde61af76eb4b07a20ee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38928
## Changelog:
[Internal] -
This moves the call to bind the `nativePerformanceNow` function to the common place in C++ code (`JSIExecutor::initializeRuntime`), as opposed on relying on calling it from every platform-specific implementation.
I believe the reason why it was don this way, to begin with, was historical, since we did use to have a different implementation of this function on every platform. Now we have a common one in C++, anyway, so there is no reason whatsoever to have this binding platform-specific.
Reviewed By: rubennorte
Differential Revision: D48232883
fbshipit-source-id: 164dc464ab7f89e993d83a4562906e033aabb3b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38795
## Context
RFC: Decoupling Flipper from React Native core: https://github.com/react-native-community/discussions-and-proposals/pull/641
## Changes
Inits new package `react-native/community-cli-plugin`. This migrates [`react-native-community/cli-plugin-metro`](https://github.com/react-native-community/cli/tree/main/packages/cli-plugin-metro) into the React Native repo, to enable faster iteration by the React Native core team. Specifically:
- This package contains several `metro` dependencies, which when removed from CLI will no longer require us to ship new CLI releases to get Metro patches and features to users.
- This package contains the `start`, `bundle`, and `ram-bundle` commands (central to the React Native development experience), for which we have incoming debugging-related changes.
- This package now **only** exports commands to be attached via a RN CLI plugin. With this move, we're aiming to **internalise** the default implementations of these dev commands within React Native — other RN CLI plugins can continue to override these, but must do so wholesale. (See also the recent fix for this: https://github.com/react-native-community/cli/pull/1999.)
In V15:
- (Microsoft feedback) Re-export `unstable_buildBundleWithConfig`, marking as unstable. This gives us a time buffer to consider how we repackage this functionality in future.
The package source has been converted from TypeScript to Flow, with a number of new `flow-typed/` defs added to meet type coverage requirements.
## To dos
- For now, we aren't removing the existing [`react-native-community/cli-plugin-metro`](https://github.com/react-native-community/cli/tree/main/packages/cli-plugin-metro) source — until later PRs consolidate this move by changing dependencies in the `react-native` package.
- **Exported API is reduced!**: I'm working with szymonrybczak to decouple references from RN CLI packages https://github.com/react-native-community/cli/pull/2021.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D46801501
fbshipit-source-id: 7f6b72941a69f487fb437768cdba125a9aa3418d
Summary:
`mFirstVisibleView` is a weak ref so it can also be null when dereferencing.
This was reported on the original PR here https://github.com/facebook/react-native/pull/35049#discussion_r1288195469
## Changelog:
[ANDROID] [FIXED] - Fix null crash when using maintainVisibleContentPosition on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/38891
Test Plan: Not sure exactly in what cases this can happen, but the fix is trivial and makes sense.
Reviewed By: cortinico
Differential Revision: D48192154
Pulled By: rshest
fbshipit-source-id: 57a38a22a0e216a33603438355bde0013c014fbf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38848
In order to parallelize the Android CI, I've moved most of the building to a `build_android` step which executes before the `build_npm_package` step.
As currently, building Hermes for Android is on the critical path, this should reduce much of the execution time on CI.
Changelog:
[Internal] [Changed] - Introduce a build_android step
Reviewed By: mdvacca
Differential Revision: D48148418
fbshipit-source-id: bfe3175fcc11d96e264eb31d8d5555bd1f83c01d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38776
in this diff I'm moving BridgelessReactPackage from com.facebook.react to com.facebook.react.bridgeless.
the goal is to hide this class from the API
changelog: [internal] internal
Reviewed By: cortinico, arushikesarwani94
Differential Revision: D48050453
fbshipit-source-id: 54ac042d491a7b8fe83e543c94e0d06bd9b88cda
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38882
This turns on local caching for Gradle builds.
From now on, some of the tasks of the build will be cached inside the `.gradle` folder.
This will benefit 'clean builds' and builds happening after branch/context switch.
CI will also benefit from this improvement as we're storing the cache folder on CircleCI.
After this we'll have to follow-up and enabling `Cacheable` on each of our task as
they're currently all disabled.
Changelog:
[Internal] [Changed] - Enable local caching for Gradle
Reviewed By: mdvacca
Differential Revision: D48187656
fbshipit-source-id: 25734ed692a69874721e86c50498b075af0fda19
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38798
Changelog:
[General][Internal] - Add example to compare perf with set state in unnecessary effect.
Reviewed By: rshest
Differential Revision: D47857125
fbshipit-source-id: f0e9f71cf2f549012394959a9087117f02e2d056
Nicola Corti
Samuel Susla
Alex Hunt
Tim Yung
Rubén Norte
Intl Scheduler
Eric Rozell
Bogusz Kaszowski
Phillip Pan
Luna Wei
Vincent Riemer
Rob Hogan
tarunrajput
Nick Gerleman
Arushi Kesarwani
David Vacca
Ruslan Shestopalyuk
Janic Duplessis
Xin Chen