Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38879
When creating a new app for iOS, you need to have Node installed properly and in the right paths in order for Xcode to pick it up.
Xcode, by default, looks into the following folders for executables:
- /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
- /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/appleinternal/bin:
- /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/local/bin:
- /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/libexec
- /Applications/Xcodefb.app/Contents/Developer/Platforms/iPhoneSimulator.platform/usr/bin
- /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/usr/appleinternal/bin
- /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/usr/local/bin
- /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin
- /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/local/bin
- /Applications/Xcode.app/Contents/Developer/usr/bin
- /Applications/Xcode.app/Contents/Developer/usr/local/bin
- /usr/local/bin
- /usr/bin
- /bin
- /usr/sbin
- /sbin
If `node` is not in one of them, our JS codegen scripts will fail to run. However, as soon as we run some scripts in Xcode, it is too late to properly look for node.
We already had a cocoapod step, running before the build phase, which was creating the `.xode.env` file, setting `NODE_BINARY` to `$(command -v node)`. Unfortunately, when executed by Xcode, that's too late too.
This change creates an `.xcode.env.local` file with the `$(command -v node)` command expanded, so I user can start working locally and quickly.
We had multiple reports and issues related to this configuration online. For example:
- https://www.reddit.com/r/reactnative/comments/15jpj0a/is_there_a_react_native_version_that_just_works/?utm_source=share&utm_medium=web2x&context=3
Note: we cannot automatically create simlinks to node in `/usr/local/bin` as it requires `sudo`.
## Changelog:
[Internal] - Generate `.xcode.env.local` to simplify the creation of an app.
Reviewed By: rshest
Differential Revision: D48111724
fbshipit-source-id: 49cc6375bd80458d69adbc343ead6c4408805eee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38880
Users who interact with your app on Android 14 devices can now grant partial access to their visual media library (Photos/Videos) when an app requests any visual media permissions (READ_MEDIA_IMAGES or READ_MEDIA_VIDEO) introduced in Android 13 (API level 33).
This diff allow enable the partial access via "READ_MEDIA_VISUAL_USER_SELECTED" in Marketplace photo picker
For Android 14 this diff request partial media access plus the normal access, there will be two return cases:
- READ_MEDIA_VISUAL_USER_SELECTED is granted, READ_MEDIA_IMAGES and READ_MEDIA_VIDEO will be denied automatically, there is no need to check the later ones
- READ_MEDIA_VISUAL_USER_SELECTED is denied, then check READ_MEDIA_IMAGES and READ_MEDIA_VIDEO
Changelog:
[Android][Changed] - Enable partial media picking in Marketplace
Reviewed By: NickGerleman
Differential Revision: D48171193
fbshipit-source-id: 644f6c691f9c2c25f981ba2c255044f62b97299d
Summary:
One of the limitations of the existing flow for the release crew is that they need to manually remember to publish all the other packages in the monorepo ahead of a new patch release - this PR modifies the logic for the bump-oss-version script (and makes it available via yarn) so that it will not run if:
* there are git changes lying around
* if some of the packages need a new release
it required a bit of refactoring to extract some portions of the logic from the bump-all-package-versions script, but I think the end result is pretty decent.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [CHANGED] - improve bump oss script to allow less human errors
Pull Request resolved: https://github.com/facebook/react-native/pull/38666
Test Plan:
* checkout this branch
* comment L54 of bump-oss-version.js (to remove the check on the branch name)
* run `yarn bump-all-updated-packages`, verify that it works and that it detects that some packages have unreleased code
* run `yarn bump-oss-version -t asd -v asd` (the "fake" parameters are needed to pass the yargs check), verify that it will throw an error because it finds a package that has unreleased code
Reviewed By: mdvacca
Differential Revision: D48156963
Pulled By: cortinico
fbshipit-source-id: 2473ad5a84578c5236c905fd9aa9a88113fe8d22
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38857
`hitSlop` must be passed into the `usePressability` hook in order for it to take effect. It's a no-op if no hit slop is present
Changelog:
[Internal][Fixed] - Propagate hit slop prop to TextInput pressability config
Reviewed By: NickGerleman
Differential Revision: D48124538
fbshipit-source-id: a910fdcec55e67d37c84facca297428556ef777e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38855
For the `test_js_prev_lts` job we don't need xlarge resources.
The current average usage for `test_js_prev_lts` is around 25%.
We can also downscale to medium in few days if this scales well.
**Insights Dashboard:**
`test_js_prev_lts`
{F1065747013}
Changelog:
[Internal] [Changed] - Downscale test_js_prev_lts job to Large
Reviewed By: cortinico, cipolleschi
Differential Revision: D48125886
fbshipit-source-id: 521fac38a1d699e576bc1ce5a3a29a47bc284e76
Summary:
[Codegen 119] This PR introduces `emitBuildEventSchema` to parser commons and abstracts the logic out of typescript and parser events as requested on https://github.com/facebook/react-native/issues/34872
## Changelog:
[Internal] [Changed] - Add `emitBuildEventSchema` to parser commons and update usages.
Pull Request resolved: https://github.com/facebook/react-native/pull/38810
Test Plan:
Run `yarn jest react-native-codegen` locally and ensure CI is green
## Screenshot of test passing locally:
<img width="1047" alt="Screenshot 2023-08-07 at 8 03 49 AM" src="https://github.com/facebook/react-native/assets/64726664/ab87f004-d9f8-4b5f-800b-0e724430301f">
Reviewed By: rshest
Differential Revision: D48155051
Pulled By: cipolleschi
fbshipit-source-id: a3db3f4783d60681b366a871b1d2ee32eb864bc0
Summary:
As we had version numbers scattered all over the places, I'm consolidating them to use a version catalog: https://docs.gradle.org/current/userguide/platforms.html
## Changelog:
[INTERNAL] - Use version catalog to consolidate versions for JVM dependencies
Pull Request resolved: https://github.com/facebook/react-native/pull/38836
Test Plan: CI
Reviewed By: cipolleschi
Differential Revision: D48150285
Pulled By: cortinico
fbshipit-source-id: 83a1867aace5395d9a10fadd6c6ab11c31fa14b5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38827
For the `test_js` and `find_and_publish_bumped_packages` jobs we don't need xlarge resources.
The current average usage for `test_js` and `find_and_publish_bumped_packages` is around 25%.
We can also downscale to medium in few days if this scales well.
**Insights Dashboard:**
`test_js`
{F1065742668}
`find_and_publish_bumped_packages`
{F1065742888}
Changelog:
[Internal] [Changed] - Downscale test_js and find_and_publish_bumped_packages` jobs to Large
Reviewed By: cortinico
Differential Revision: D48125531
fbshipit-source-id: 004c2306fd224a5798a6b084fb75a79896695b15
Summary:
Migrate `CustomLineHeightSpanTest` 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 CustomLineHeightSpanTest to kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/38847
Test Plan:
```
./gradlew :packages:react-native:ReactAndroid:test
```
Reviewed By: rshest
Differential Revision: D48155397
Pulled By: cortinico
fbshipit-source-id: bbaa7d08a84c609bc64b48a08e1b91078ce6ef23
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38816
To save resources, we should build only arm64 for PRs and commits to mains.
Our Android ABIs are really similar and we should just build the most popular. For nightlies/releases
instead we'll have to build all the archs.
Changelog:
[Internal] [Changed] - Build only arm64 when building PRs. All archs for nightlies and releases.
Reviewed By: cipolleschi
Differential Revision: D48112361
fbshipit-source-id: 69e172a4ea69f844b344a9fc6ac4ee0471b40c36
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38815
For the template jobs, we don't need xlarge resources but we can probably use medium.
I've checked on the Insights dashboard and the average usage is at 25%
Changelog:
[Internal] [Changed] - Downscale Test Android Template jobs to Large
Reviewed By: cipolleschi
Differential Revision: D48112362
fbshipit-source-id: 3745a90d12b96818430264be43ae2672bb05d436
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38746
This adds a view prop which controls the layout conformance of it and its transitive children (including non-view ShadowNodes).
The implementation here is to traverse down before layout, updating any context-specific configuration.
Normally at the time of layout, unchanged child ShadowNodes are already sealed. These must be mutated already if layout results change, and we do this today via Yoga node clone callback, where Yoga clones nodes where it will do layout work (but not all of them).
We down-propagate configuration, but can terminate if we observe an already sealed node whose values match those of our current context, since any nodes under must also follow the same contexts (or any nested contexts of the sealed node). This means that calling `layoutTree()` on a mostly clean ShadowTree will cause configuration to not traverse most nodes.
`Errata` and `PointScaleFactor` (DPI) are threaded to each Node's per-node config. The same values are retained when Yoga nodes are cloned (by cloning the ShadowNode). Since these are set before the first layout, config setting should only ever dirty layout [when layout-effecting values change](https://www.internalfb.com/code/fbsource/[1c95e981c740]/xplat/yoga/yoga/YGConfig.cpp?lines=13).
The prop is prefixed with `experimental` because we are likely to make more breaking conformance fixes in the strict mode, and I'm not sure this is the final API yet. I was previously looking at a context-like component which is more challenging to implement.
Changelog: [Internal]
bypass-github-export-checks
Reviewed By: rozele, sammy-SC
Differential Revision: D47940100
fbshipit-source-id: f72e1c73f537e0312c2bba19ae8c2e882c82aced
Summary:
The offset we record should be the one closest to the reference zero-point in the coordinate space. This makes scroller offset reference match the cell reference we keep in D47978631.
Changelog:
[General][Fixed] - Use right edge of ScrollView viewport for `scrollMetrics.offset` in RTL
bypass-github-export-checks
Reviewed By: lenaic
Differential Revision: D48132236
fbshipit-source-id: 3307081e5e859f1b4afbc15a84c5be1b33915206
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38803
The d.ts file says these constant must exist, but they only exist in the android implementation. This diff stops lying and adds some dummy constants, so that the type will match-up.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D48085126
fbshipit-source-id: 8d5332a71b9b3c1925abeec9e47630a07abf8b86
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38819
The jobs for `analyze_pr` and `analyze_code` are currently running on Android's Docker container on a XL instance. This is costly. As those jobs are relatively small, not on the critical path, and need the Android container only for `java`, I've moved the to the node-broswers CI executor:
https://circleci.com/developer/images/image/cimg/node
Changelog:
[Internal] [Changed] - Downscale and move to a prebuilt-image analyze code/pr
Reviewed By: cipolleschi
Differential Revision: D48116159
fbshipit-source-id: a12782b810fb225ab6916a35054a891e73f3a717
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38822
We should not attempt to import `java.util.Collections` in a Kotlin file
as we should use the Kotlin's equivalent class instead.
Changelog:
[Internal] [Changed] - Do not import java Collections from Kotlin
Reviewed By: cipolleschi
Differential Revision: D48117940
fbshipit-source-id: f1a972f1d3867ee4dd788c3cf34c1b931a8082d8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38821
I've just realized that the caching of 3rd party native dependencies is broken for Android, so we re-download them every time. This fixes it by specifying the correct paths where the zip files are stored.
Changelog:
[Internal] [Changed] - Fix caching paths for Gradle after the monorepo migration
Reviewed By: cipolleschi
Differential Revision: D48116655
fbshipit-source-id: 5a8ba65ef9b006be197b135f8dbf60372483f726
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38814
This change enables the Gradle Daemon on CI.
We noticed some flakyness with the Daemon disabled, so we'll give it a try with the daemon enabled which is the default for Gradle.
Changelog:
[Internal] [Changed] - Enable the Gradle Daemon for CI
Reviewed By: cipolleschi
Differential Revision: D48112363
fbshipit-source-id: 4a7f9bbaad33935a97e4e0ea28ea8f2f22c67d0f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38771
Changelog: [Internal]
Metro has been passing `inlineRequires: false` to Babel transformers for the last 5 years (D9636747), as the inline requires transform had been hoisted into the transform worker. Here we clean up the unused code paths in React Native's implementations of the Metro Babel transformer API, and the unused properties in the API itself.
Reviewed By: GijsWeterings
Differential Revision: D48034441
fbshipit-source-id: d24a793962942a3c87461ffbade847ea749dac95
Summary:
Right now we're building by default Android app in New Architecture, so to align this behaviour between platforms - I added `RCT_NEW_ARCH_ENABLED=1` when installing Pods when running E2E tests, to also build iOS app in New Arch.
## Changelog:
[IOS] [CHANGED] - Build iOS app in New Architecture when running E2E tests.
Pull Request resolved: https://github.com/facebook/react-native/pull/38813
Test Plan: App in `test_e2e_ios` job should build in New Architecture
Reviewed By: dmytrorykun
Differential Revision: D48112814
Pulled By: cipolleschi
fbshipit-source-id: f709fe23f7c3ff65f3e39acb304581c4ec0fdea8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38742
If you try to add an `onScroll` event listener on iOS, you will get a warning that you must additionally add a `scrollEventThrottle`, otherwise you will only receive a single event throughout the duration of the gesturing.
Values under 17ms are unthrottled, so it is common to see components passing magic values `16` and `0.0001` to ask for full events.
This behavior is inconsistent with Android, Web, and Windows.
This change runs an experiment on iOS to continuously fire scroll events to users of `onScroll` without `scrollEventThrottle`. Because there are warnings already, I think this case will be rare, and any code written for Android will already have to be written to be compatible with it.
I intentionally left the warning in for now, so that folks don't add new code relying on this QE while it is being tested.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D47975260
fbshipit-source-id: 8f182c5514cc557e1804586e8cbc68fc54502d83
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38735
UTs around cell measurement results through `getCellMetrics` and `getCellMetricsApprox`. For each orientation, validate basic scenarios for approximation, cached measurement, or measurement by user-provided `getItemLayout`.
Changelog: [Internal]
Reviewed By: rozele
Differential Revision: D47978630
fbshipit-source-id: 4c9ba6a60599848034f4f23cde3497dd4c2b8788
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38733
I was working under the assumption that Fabric fired layout events bottom up, but it actually fires them top-down, in constrast to Paper.
Previous invalidation logic wasn't quite correct when fired bottom-up. This corrects the logic by:
1. Deriving direction based on initial event ordering
2. Use last cached contentLength if we are on Fabric (top-down)
3. Use future contentLength if we are on Paper (bottom-up)
Changelog:
[General][Fixed] - Fixup contentLength invalidation logic
Reviewed By: rozele
Differential Revision: D47978638
fbshipit-source-id: 3446d08aa34397b4e6bd9924dad0eba36a12a115
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38737
This fixes up behavior on Android so that `scrollToIndex` aligns the right edge of the cell of the given index to the right edge of the scrollview viewport. We do not incorporate RTL on iOS which inverts x/y coordinates from scroller (but not layout).
Changelog:
[General][Fixed] - Right align scrollToIndex in RTL
Reviewed By: lenaic
Differential Revision: D47978637
fbshipit-source-id: 7786b5d97efaced318018409e2c7577a3d8f7402
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38734
Returned measurements from the measurements cache in RTL calculate offset as distance from the left edge of the cell to the right edge of the content, when it should instead be the distance from the right edge of the cell (the logical beginning).
Changelog:
[General][Fixed] - Return right edge in RTL cell metrics
Reviewed By: lenaic
Differential Revision: D47978631
fbshipit-source-id: b0db4e9aff676c5bee81d4491f901a6bbc38e4bf
Riccardo Cipolleschi
Lulu Wu
Riccardo Cipolleschi
Lorenzo Sciandra
Madhusudan Sapkota
Intl Scheduler
Ellis Tsung
Xin Chen
Arushi Kesarwani
David Vacca
Siddarth Kumar
Nicola Corti
Burak Güner
David
tarunrajput
Nick Gerleman
Sam Zhou
Samuel Susla
Moti Zilberman
szymonrybczak
Kyaw Thura
Pieter Vanderwerff
Facebook Community BotandFacebook Community Bot