Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45556
I missed updating this, and the e2e test we had isn't running, so switching JS objects to camel case broke this.
Changelog: [internal]
Reviewed By: jorge-cab
Differential Revision: D60003747
fbshipit-source-id: 6b7b1138e3ebbfdb982f5a089804351cc4b198ba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45550
`ConcurrentModificationException` is happening from `emitScrollEvent()`.
This usually happens if we modify the collection (add/remove) while accessing collection in a foreach loop.
Seems likely add/remove is called from a different thread while in the foreach loop.
Converting to list before we do the foreach as a quick fix.
Changelog: [Internal] - quick fix for exception
Issure reported here: https://fb.workplace.com/groups/rn.support/permalink/26557068097248454/
Reviewed By: mdvacca
Differential Revision: D59991739
fbshipit-source-id: a2fcc798430acaadd07561a5be871967cc8f2c3b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45549
## Summary
Calling `getCurrentReactContext` on an unmounted `ReactRootView` could lead to a NPE. The method currently returns a nullable value so return type is the exact same. This change checks if the react instance manager is present and returns null early if not.
## Changelog:
[Android] [Fixed] - Adds a null check in react context getter
Reviewed By: zeyap
Differential Revision: D59982179
fbshipit-source-id: bac5c12e7dc4ee3296991063eb3746141b8446bc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45544
## This diff now does 5 things:
1. removes the old way we used `actions/setup-node` to manage the cache itself.
2. it creates a new `update-node-modules-cache` workflow, which is the only job that will update the node modules cache
3. it create a `yarn-install-with-cache` action that should be used install of directly calling `yarn install --non-interactive`. This will load a cache against a hash of `package.json`.
4. updated the cache reaper to aggressively remove everything but the latest `npm-{{ hash('package.json') }}`.
5. removed a `cache-setup`, which couldn't be used (we're using artefacts now).
## Why are we doing this:
The various `node-cache-` keys for platforms and on various branches accounts for a very large proportion of the cache (10-20%).
We don't frequently change these dependencies, and even when we do running `yarn install` after loading the cache will resolve any issues.
Limiting the cache to `main` and aggressively pruning older cache entries will clean up a lot of "small win" caching.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D59917944
fbshipit-source-id: 4be6f1959e8fde642a4f208f7d19aceba2c3262f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45530
Enable viewconfig validation for RNTester to catch where static and native viewconfigs are mismatched, during development or contribution time. This relies on `useNativeViewConfigsInBridgelessMode()` which is already enabled in `DefaultNewArchitectureEntryPoint` on Android, and seems to be in iOS AppDelegate `RCTRootViewFactory` as well.
We put it in an early place in the bundle before first render, since we don't have RNTester preludes right now, but I think it is still early enough?
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D59946366
fbshipit-source-id: ae0c23b13a566489a88a7b4e408f61dce314b003
Summary:
This moves the `helloworld` app to build from the artifacts produced by build_npm_package so that we don't rebuild ReactNative Android from source 8 times.
It reduces build time of such jobs from 14mins to 4mins, resulting in 80mins of build time for every test_all run.
## Changelog:
[INTERNAL] - Move helloworld to build from artifacts on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/45517
Test Plan: CI
Reviewed By: blakef
Differential Revision: D59957613
Pulled By: cortinico
fbshipit-source-id: b6c4adcf804af6c8d2661cf56549d037e09aa2c1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45543
# Changelog:
[Internal]-
Introduced recently, this confuses viewconfig validation vs the vanilla Android view managers.
So this change effectively reverts the exposure of `ScrollView.scrollIndicatorInsets` to Android, achieving the goal in a different way (via the SVC injection workaround for the specific Android platform flavour).
Reviewed By: NickGerleman
Differential Revision: D59960782
fbshipit-source-id: 3b9a49f1466426d909e94bf4d33f1d09fbf822c2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45542
As we do have several version numbers for external actions all across the codebase,
here I'm aligning all of them to just use the majors.
I'm doing it only for GitHub first party actions as we trust them,
so minor/patch changes can safely be pulled in without code changes.
Changelog:
[Internal] [Changed] - Align github/* action versions on major
Reviewed By: cipolleschi, blakef
Differential Revision: D59959978
fbshipit-source-id: bb07ce0dfd74d9502a2ac0ea90a2b32f55d6d655
Summary:
With the migration to GHA, we can remove all the duplicated jobs from CircleCI.
These are the only 4 jobs remained to migrate
## Changelog:
[Internal] - Remove all the jobs already migrated to GHA
Pull Request resolved: https://github.com/facebook/react-native/pull/45219
Test Plan: CCI is green
Reviewed By: cortinico
Differential Revision: D59156888
Pulled By: cipolleschi
fbshipit-source-id: 193f1f8fa7484154d5295ac36a63bb81a159da6e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45541
This is another round of letting react-native-bot do the job that the
generic GitHub Action bot was doing.
Changelog:
[Internal] [Changed] - Act On label as react-native-bot
Reviewed By: cipolleschi
Differential Revision: D59959468
fbshipit-source-id: 8e0f7e2e90a40ed2aa265e637c8a809064e22747
Summary:
Nightly/Release workflow are currently broken due to a wrong path reference to a composite action. This fixes it.
## Changelog:
[INTERNAL] - Fix nightly/release workflow
Pull Request resolved: https://github.com/facebook/react-native/pull/45537
Test Plan: CI
Reviewed By: cipolleschi
Differential Revision: D59959185
Pulled By: cortinico
fbshipit-source-id: 02c556d86105eac35e152b4dc09705bc42c8031a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45533
This input is unused and is causing a warning on the build pipeline.
I'm cleaning it up.
Changelog:
[Internal] [Changed] - Remove unused build-from-source input
Reviewed By: blakef
Differential Revision: D59958184
fbshipit-source-id: 23ba010da077342605afaaee122bc7ceabc89915
Summary:
Added space to $(inherited) string to avoid creation of wrong cpp flags in RCTAppDelegate podspec
<img width="1157" alt="Screenshot 2024-07-18 at 8 51 19 PM" src="https://github.com/user-attachments/assets/29d32d08-e81f-4c25-b8ee-5dccc0f620ea">
## Changelog:
[IOS] [FIXED] - Building of iOS project when RCTAppDelegate is used in the project
Pull Request resolved: https://github.com/facebook/react-native/pull/45520
Test Plan: To test this you can simply change in your node modules and run pod install, the build will now work successfully
Reviewed By: cipolleschi
Differential Revision: D59950906
Pulled By: arushikesarwani94
fbshipit-source-id: 0d58620aa0be7ac4fcbcd309f06df0eef7844016
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45529
`experimental_boxShadow` is not yet part of Android view managers, and when we enable it, we are likely to do a view manager at a time before moving to BaseViewManager.
This causes user-visible errors when viewconfig validation is turned on, since we have a static view config, but not yet a native view config.
This removes the static viewconfig for Android until we start adding setters to view manager.
It is kept in `ReactNativeStyleAttributes` (which I think can have members not in the native view-config, since it has component specific props like tintColor), and iOS base viewconfig. On Fabric iOS, this is part of BaseViewProps, and handled by RCTView, but it looks like the prop (and also `experimental_filter`, `experimental_mixBlendMode`) do not have entries in iOS RCTViewManager, which is fixed in next diff in the stack.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D59939866
fbshipit-source-id: 2781029a0c29ba111ed04edfe9940c6c72f4e5ac
Summary:
Viewconfig processors may still get called for nullish values I think. Most other processors explicitly handle these (but some don't??).
This returns an empty list, like on parse error, when we have a value, but the value is nullish.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D59933611
fbshipit-source-id: 3f1d89d21977bbe01a05e708aadf1a9451d88083
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45512
isBufferingEnabled_ can be read (by design) from multiple threads, but
it's not atomic. Make it so.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D59907026
fbshipit-source-id: ffce54a28404148b3e270fa90dfe850a334ca2f0
Summary:
This PR fixes a case where the user initializes react native in a directory that contains a space.
It was causing pod install to fail because the path to `create-dummy-hermes-xcframework.sh` script wasn't in a string.
## Changelog:
[IOS] [FIXED] - Hermes prepare_command fails with space in path
Pull Request resolved: https://github.com/facebook/react-native/pull/45316
Test Plan:
1. Create a directory with space in path
2. Initialize React Native inside
3. Install pods
4. Check if pod install doesn't fail
Reviewed By: dmytrorykun
Differential Revision: D59912979
Pulled By: cipolleschi
fbshipit-source-id: b2c08d5035a245f8b4d6bfaf562e46d9c5d127b5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45501
changelog: [internal]
Implement caching for FabricUIManager::getColor. A call to FabricUIManager::getColor takes on average 0.4ms and there can be many of them. The arguments for the call keep repeating in majority of times. Employing a simple caching mechanism here to avoid unnecessary trips via JNI to reduce overhead.
The dependencies in graphics in BUCK are incorrect. I tried to separate this into multiple files and move implementation to .cpp file but this will require a bit of a more restructuring to make it possible.
Reviewed By: mdvacca, dmytrorykun
Differential Revision: D59859754
fbshipit-source-id: 748efce7f0b8c96001b6ac1a4b457b8c9d63fe9c
Summary:
Factor out the Build NPM package job in a separate action for code reuse
## Changelog:
[Internal] - Factor out the Build NPM package job in a separate action for code reuse
Pull Request resolved: https://github.com/facebook/react-native/pull/45493
Test Plan: GHA are green
Reviewed By: robhogan
Differential Revision: D59858572
Pulled By: cipolleschi
fbshipit-source-id: 561a215ba5812352034157aa254999db56fcd31e
Summary:
With the recent changes to the CI, we need to update the test-e2e-local to work with the new artifacts
## Changelog:
[Internal] - Update local-e2e-test to run with the new Android Artifacts
Pull Request resolved: https://github.com/facebook/react-native/pull/45499
Test Plan: Tested locally.
Reviewed By: blakef
Differential Revision: D59902087
Pulled By: cipolleschi
fbshipit-source-id: 84ef78e8dba222bf8a9e3620632fb2a9d286d42b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45471
Changelog: [internal]
This is a React Native specific modification of the Long Tasks API that refines the logic to detect long tasks considering voluntary yielding checks.
In RN, as opposed to Web, we can have a very long task executing in the JS thread without causing any issues to the responsiveness of the app, as long as the task checks whether it should yield in short intervals. In this case, if the app always checks whether it should yield at least once every 50ms, the task will not be considered "long".
Check the new unit tests to see this behavior in practice.
Reviewed By: sammy-SC
Differential Revision: D55647992
fbshipit-source-id: 82ab41173d4d9deee65b8ade2268c40d7f58c6e2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45473
This is a basic implementation of the Long Tasks API (https://w3c.github.io/longtasks/).
It detects and reports long tasks when using the Event Loop (in the modern RuntimeScheduler) when a new feature flag for this purpose is enabled.
This doesn't include attribution information at the moment.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D55491870
fbshipit-source-id: e1ccad9cc6a35073b31230a8cf3a4660ab9a043d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45492
Changelog: [internal]
When testing the changes in https://github.com/facebook/react-native/pull/45473 / D55491870, I saw that the reported time spans for long tasks didn't perfectly align with the long tasks themselves in traces (Perfetto).
Taking a closer look, I realized that I wasn't doing the conversion between times and durations from `chrono` and `DOMHighResTimeStamp` (a `double`) correctly, and we're doing this conversion very often.
This moves the definition of `DOMHighResTimeStamp` to its own library and adds conversion methods to make sure we don't make this mistake in the future.
Reviewed By: rshest
Differential Revision: D59820241
fbshipit-source-id: c123920de56336da384ddc484f6ac9d287724301
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45464
Previous work would cause versions >= react-native 0.76 to exit if called through `npx react-native <cmd>`. This was intended to be full deprecated and removed. The intention was to shift users to calling react-native-community/cli directly.
This change allows commands to be proxied to react-native-community/cli but with no guarantees of success. It's up to each framework / project to explicitly create that dependency.
This also provides warnings, which won't go away, suggesting the supported method of calling the community CLI directly.
The outcome is that we're not going to break existing workflows.
closes: #45461
Changelog: [General][Fixed] allow proxying commands from react-native to react-native-community/cli with explicit warning
Reviewed By: cortinico
Differential Revision: D59805357
fbshipit-source-id: 21e23b082a9c709effa050d8e7dd04a40f5ab0e6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45483
We don't really use this functionality and is getting harder to migrate to GHA,
hence I'm removing it.
Changelog:
[Internal] [Changed] - Remove report-app-size
Reviewed By: cipolleschi
Differential Revision: D59822862
fbshipit-source-id: 2d082454aea3b3c5863bd34556a23c2fc847f841
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45510
This is just a quality of life improvement, where we test the C++ autolinking
code generation a bit more.
Changelog:
[Internal] [Changed] - Improve tests for GenerateAutolinkingNewArchitecturesFileTask
Reviewed By: blakef
Differential Revision: D59907847
fbshipit-source-id: e6367cc3b1c01700310437b73bc984e3666b3499
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45511
This adds react-native.config.js to autolinking default lockfiles
so autolinking can account for changes in that file.
Changelog:
[Internal] [Changed] - Add react-native.config.js to autolinking lockfiles
Reviewed By: blakef
Differential Revision: D59907268
fbshipit-source-id: d5893a3f7b4d5d9f6c6c13042aa6866ad16b2ea4
Summary:
This change adds a job that runs 2 hours after the nightlies. This jobs returns successfully if the nightly has been published or it report an error in case it has failed.
We will hook this signal to the internal system to be notified about Nightlies failures
## Changelog:
[Internal] - Add jobs to check for nightlies
Pull Request resolved: https://github.com/facebook/react-native/pull/45509
Test Plan: Test the Action on GHA
Reviewed By: blakef
Differential Revision: D59907442
Pulled By: cipolleschi
fbshipit-source-id: 3b35aa2ad69b376c65a765f740a1d6e6ed8ad99f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43333
This change fixes https://github.com/facebook/react-native/issues/43285.
Basically, when using a `yarn` alias to install pods, yarn creates a copy of the `node` and `yarn` executables and the `command -v node` command will return the path to that executable.
## Changelog
[iOS][Fixed] - Do not use temporary node when creating the .xcode.env.local
Reviewed By: dmytrorykun
Differential Revision: D54542774
fbshipit-source-id: 3ab0d0bb441988026feff9d5390dcfd10869a1b5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45508
The scripts/clean-gha-cache.js uses the `gh` cli too, which expects the GITHUB_TOKEN presented GH_TOKEN. Also allowed us to manually kick off this workflow.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D59901639
fbshipit-source-id: f3543cc83cbf67b6969abc3390790e038e06c305
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45503
Kebab case object literals are a pain as an API to give folks. Keep string parsing using the kebab-case web names, like in CSS, but keep object notation camelCase.
This is super super hacked up, and we should burn away all these viewconfig processors as soon as we can.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D59793095
fbshipit-source-id: 888cad31142d7aeed42687ab23c2023ac7e4882d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45452
With this we enable <View> to use BoxShadow.
BoxShadow property can be a string as defined on MDN: https://developer.mozilla.org/en-US/docs/Web/CSS/box-shadow
Or it can also be a list of BoxShadow primitives:
```
[
{
offsetX: 10,
offsetY: 5,
color: 'red',
inset: true,
},
{
...
},
]
```
The diff includes:
* Style sheet changes so typing is valid
* Process function to turn boxShadow format into parsed boxShadow primitive
* Test for process function
* View config changes on Android, iOS and ReactNativeStyleAttributes
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D57872933
fbshipit-source-id: 2c5732709959bd996cce2f979549fc95cf2410e2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45481
We are going with this name as it is more commonly used in the spec and makes more sense since there are no circles involved with spread
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D59819180
fbshipit-source-id: cf20c22b11e9ff9935b9f54e28db37d3ea399d8f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45334
Adds support for the `xml` file extension as a loadable asset, and lets Flow treat the type signature as an image
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D58261501
fbshipit-source-id: b29cffee81d0438827529711e86267edd5d2a0f7
Summary:
I'm picking 1630b5c743 in main as it's currently missing (available only on `0.75-stable`).
## Changelog:
[INTERNAL] - Update testing scripts to work with any version of React native
Pull Request resolved: https://github.com/facebook/react-native/pull/45498
Test Plan: Nothing to test as this is a backport
Reviewed By: cipolleschi
Differential Revision: D59861440
Pulled By: cortinico
fbshipit-source-id: 57f642c66c7a6976f5a5cd53debaeb2e461a1f30
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45457
With this change, we are implementing in Android a similar logic that we implemented in iOS.
1. When the user stops dragging a scroll view, it tells native animated modle that a scroll has finished
2. NativeAnimated module asks to the NativeAnimatedNodesModule if there are native node listening to the scroll
3. In case they are, it emits an event to JS
4. JS listen to the events and resync the Shadow Tree and the Native Tree (this implemented in a previous change)
## Changelog
[Android][Fixed] - Sync the Shadow Tree and the Native Tree with Native animation when scroll is driving the animation
Reviewed By: sammy-SC
Differential Revision: D59756577
fbshipit-source-id: e558557b477f4da9da1f89fb31ba86d0ea1390a3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45383
This is the second step required to fix the onTouchMove event in the new architecture.
In this change, we are retrieving the list of nodes that are connected by the animation, and we are sending an event to the nodes so that we can trigger the commit.
## Changelog
[iOS][Added] - retrieve the tags of the nodes connected by the animation and send them to JS
Reviewed By: sammy-SC
Differential Revision: D59524617
fbshipit-source-id: 584317afa8e4cf0ad9f98f38e4e5d436c5fe3ac5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45382
This change is the first step to tr and solve the pressability's `onTouchMove` issue with animation driven natively in the New Architecture.
The idea is to trigger a special event from native to let JS know that a scroll event has ended (`scrollViewDidEndDragging` or `scrollViewdidEndDecelerating`).
When this happens, we need to send an event to JS to let him know that it has to sync the Native Tree with the Shadow Tree.
Step 2 is to connect Native with JS
## Changelog:
[iOS][Added] - Send onScrollEnded event to NativeTurboAnimatedModule
Reviewed By: sammy-SC
Differential Revision: D59459989
fbshipit-source-id: cb425cddcdaa9d700ec40accaf4ab3ce1f3c5038
