Summary:
Noticed that we weren't receiving pointer events for nested Text spans when the new pointer events implementation was enabled.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D41496672
fbshipit-source-id: 9d0ed83d1bb5f42211ec655328035651f25fa471
Summary:
These experiments have been removed already, but we still have references to them in C++.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D41549465
fbshipit-source-id: 1158fb391b4279ef4eb6ad7123cb8113d7ecccef
Summary:
`Promise<T>` is used very often in turbo module as function return types. So `T` is a critical thing for type safety. To enable future generator to produce more specific type for `Promise`, `T` is added to the schema.
## Changelog
[General] [Changed] - Fix codegen to add `T` of `Promise<T>` in CodegenSchema.js
Pull Request resolved: https://github.com/facebook/react-native/pull/35345
Test Plan: `yarn jest react-native-codegen` passed
Reviewed By: lunaleaps
Differential Revision: D41304647
Pulled By: cipolleschi
fbshipit-source-id: 6cdd2357b83d4d8007c881a7090cbb8969f3ae9d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35496
This commit includes a series of fixes needed for better integration with libraries for 0.71:
- I've added an `android/README.md` file as some libraries were failing the build if the folder was missing
- RNGP now applies dep substitution on app and all the libraries project
- RNGP now adds repositories on app and all the libraries project
- I've removed the maven local repo to the `/android` folder as now is empty
- I've fixed the path for the JSC repo for Windows users
- I've added a bit of backward compat by re-adding an empty `project.react.ext` block that libraries might read from.
- I've removed `codegenDir` from the `GenerateCodegenArtifactsTask` which was unused.
Changelog:
[Internal] [Changed] - RNGP - Various improvements needed for 3rd party libs
Reviewed By: cipolleschi
Differential Revision: D41549489
fbshipit-source-id: 2252da0180ac24fd3fe5a55300527da6781f0f8c
Summary: Changelog: [Internal] - Internal usage broke existing behavior, reverting to check if a flag is set.
Reviewed By: javache
Differential Revision: D41502122
fbshipit-source-id: 296bb1578cd63f935e4111bfec8d58f965149640
Summary:
this is a trivial change that allocates the NSMutableArray with the correct capacity before it is filled
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - RCTConvertVecToArray - allocate array with capacity
Pull Request resolved: https://github.com/facebook/react-native/pull/35490
Test Plan: tested locally: the code builds and runs as expected
Reviewed By: cipolleschi
Differential Revision: D41548050
Pulled By: GijsWeterings
fbshipit-source-id: a5b947331d6c5fffcfecc7c20c827f42442b1ab8
Summary:
Changelog: [Internal]
`NativeComponentRegistryUnstable.js` has Flow syntax but no `flow` directive. It seems to typecheck fine so I'm adding the directive here. (Plus `format` for good measure.)
Reviewed By: huntie
Differential Revision: D41547266
fbshipit-source-id: 1b6a03c705add91843633166a245d0447a21af6d
Summary:
This pull request migrates the appearance example to using React Hooks.
## Changelog
[General] [Changed] - RNTester: Migrate Appearence to hooks
Pull Request resolved: https://github.com/facebook/react-native/pull/35114
Test Plan: The animation works exactly as it did as when it was a class component
Reviewed By: cortinico
Differential Revision: D41531005
Pulled By: cipolleschi
fbshipit-source-id: a864766a3bb58a7f0c2b9c4ed8f731ee84713b26
Summary:
when I'm defining a turbomodule spec, I tried to extract a common parameter into an interface.
The error I get is this:
```
[Codegen] >>>>> Processing RNSimpleToastSpec
[Codegen] Done.
/Users/vojta/_dev/_own/simple-toast/example/node_modules/react-native-codegen/lib/parsers/typescript/utils.js:111
throw error;
^
TypeError: Cannot read properties of undefined (reading 'length')
at isModuleInterface (/Users/vojta/_dev/_own/simple-toast/example/node_modules/react-native-codegen/lib/parsers/typescript/modules/index.js:695:18)
at Array.filter (<anonymous>)
at buildModuleSchema (/Users/vojta/_dev/_own/simple-toast/example/node_modules/react-native-codegen/lib/parsers/typescript/modules/index.js:709:44)
at /Users/vojta/_dev/_own/simple-toast/example/node_modules/react-native-codegen/lib/parsers/typescript/index.js:158:9
at guard (/Users/vojta/_dev/_own/simple-toast/example/node_modules/react-native-codegen/lib/parsers/typescript/utils.js:108:14)
at buildSchema (/Users/vojta/_dev/_own/simple-toast/example/node_modules/react-native-codegen/lib/parsers/typescript/index.js:157:22)
at Object.parseFile (/Users/vojta/_dev/_own/simple-toast/example/node_modules/react-native-codegen/lib/parsers/typescript/index.js:185:10)
```
After the fix I get this:
```
[Codegen] >>>>> Processing RNSimpleToastSpec
[Codegen] Done.
/Users/vojta/_dev/_own/simple-toast/example/node_modules/react-native-codegen/lib/parsers/typescript/utils.js:111
throw error;
^
Invariant Violation: GenericTypeAnnotation 'Styles' must resolve to a TSTypeAliasDeclaration. Instead, it resolved to a 'TSInterfaceDeclaration'
```
Then I know that I should not be using an `interface` but a `type`
## Changelog
[Internal] [Fixed] - TS codegen crash when parsing interfaces
Pull Request resolved: https://github.com/facebook/react-native/pull/35492
Test Plan:
tested locally
let me know if you want an automated test
Reviewed By: cortinico
Differential Revision: D41548015
Pulled By: cipolleschi
fbshipit-source-id: 9acf02dffbb084831690f665357fb80225cbce0d
Summary:
This is the last library that we should expose via Prefab.
Thanks to cipolleschi 's work here moving the file to `/ReactCommon/jsc` folder
we can easily expose it to be consumed by third parties.
Changelog:
[Internal] [Changed] - Expose `jscruntime` to be consumed via Prefab
Reviewed By: cipolleschi
Differential Revision: D41534564
fbshipit-source-id: fb4b2d801def8caf71638dcb74eb87f8230984d4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35482
This change moves the JSCRuntime.h/cpp into a `jsc` folder.
This change is required for several reasons:
1. on iOS, the new `jsi`, `jsidynamic` and `jsc` setup is breaking the `use_frameworks!` with `:linkage => :static` option with the old architecture. So it is a regression.
2. JSCRuntime is required by some libraries and needs to be exposed as a prefab and the current setup makes it hard to achieve.
allow-large-files
## Changelog:
[General][Changed] - Move JSCRuntime into a separate pod/prefab
Reviewed By: cortinico
Differential Revision: D41533778
fbshipit-source-id: 642240c93a6c124280430d4f196049cb67cb130b
Summary:
Normally, when we work with RNTester, we have to install the pods with the `pod install` command. The `pod install` commands has some side effects on the Xcode.project: for example, it installs some build script phases.
In Sandcastle, we do not run that command to avoid network requests and to improve test reliability and reproducibility. This implies that, when we run the sandcastle jobs and/or we update the offline mirrors, we also have to upload the Xcode project associated with the specific JS engine.
This Diff operates in two steps:
1. when updating the offline mirrors, it creates a tarball with the Xcodeproj and stores it in the proper offline mirror folder.
2. when testing, it replaces the current project with the one stored in the offline mirrors before extracting the pods.
allow-large-files
## Changelog
[Internal] - Keep a copy of the Xcodeproj in the offline mirrors
Reviewed By: cortinico
Differential Revision: D41541712
fbshipit-source-id: e6d9633f9245631ab56c8b9689707b537c30075c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35436
Using std::optional as react-native has been using C++17 for quite some time
changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D41415031
fbshipit-source-id: d786647f64b4f90cf75409109830ae0885460c17
Summary:
The nightly version is bumped after the check is performed, therefore it fails.
With this diff, we become slightly more accepting with nightlies, allowing both `0.0.0` and `0.0.0-xxxx` as valid version for nightlies.
## Changelog
[JS][Fixed] - Accept 0.0.0 with and without prelrelease for nightlies' versions
Reviewed By: cortinico
Differential Revision: D41534995
fbshipit-source-id: 2d0417441ca7d3d3f7660c9317133ac3c6de2eb9
Summary:
When dry-run in stable branch, the tag already exists. We are bypassing the tag-existence check when in a dry-run to have the CI pass
## Changelog
[General] [Fixed] - Bypass tag version check when dry-run
Pull Request resolved: https://github.com/facebook/react-native/pull/35470
Test Plan:
CircleCI
It worked for RC1 and RC2
Reviewed By: cortinico
Differential Revision: D41529648
Pulled By: cipolleschi
fbshipit-source-id: d4d7f5534f86c2cf10b05e0d4cab950e4902d8df
Summary:
See the issue at https://github.com/facebook/react-native/issues/32432#issuecomment-1242234121
This fixes a bizarre issue when using the GNU coreutils tools. There are very minor differences in the standard command-line tools on macOS and the GNU coreutils. The `cp` command has slightly different semantics across these operating systems, so this commit normalizes those differences and allows GNU coreutils to be used or the system native version of `cp`.
Fixes#32432
## Changelog
[General] [Fixed] - Allow GNU coreutils to be used to build projects
Pull Request resolved: https://github.com/facebook/react-native/pull/35382
Test Plan: This change allows the use of the system or GNU coreutils verson of `cp`.
Reviewed By: cipolleschi
Differential Revision: D41532472
Pulled By: cortinico
fbshipit-source-id: f0fe5274d3828bf6099deceee797a82a6adfdcab
Summary:
This is a nit. Just moving this expo sample to a service account
which is co-owned by Meta and Expo.
Changelog:
[Internal] [Changed] - Move expo samples to a service account.
Reviewed By: cipolleschi
Differential Revision: D41533073
fbshipit-source-id: 4745bb35160c401ebb9ce03325bda64726f122dc
Summary:
We have two warnings on MapBuffer which I'd like to resolve as they show up on console every time.
1. We're using a deprecated method receiveCommand, which is actually legit but was missing a propagation of the warning. I'm adding it.
2. We had a null check that that was always not null. That is enforced by the Kotlin type system. I've checked the code and
we're actually always returning non-nulls there or raising exceptions instead.
Changelog:
[Internal] [Changed] - Fix compilation warnings for MapBuffer
Reviewed By: javache
Differential Revision: D41522129
fbshipit-source-id: c2dbb660f95a2ff7dac6e4fcdf476e4058cf730e
Summary:
The [monorepo RFC](https://github.com/react-native-community/discussions-and-proposals/pull/480) calls for renaming:
* `react-native-community/eslint-config` -> `react-native/eslint-config`
* `react-native-community/eslint-plugin` -> `react-native/eslint-plugin`
It also calls for the versions to be aligned with the rest of main -- currently `0.72.0`.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[General][Changed] - Renamed `react-native-community/eslint-config` to `react-native/eslint-config` v0.72.0 to align with other packages
[General][Changed] - Renamed `react-native-community/eslint-plugin` to `react-native/eslint-plugin` v0.72.0 to align with other packages
Pull Request resolved: https://github.com/facebook/react-native/pull/34581
Test Plan:
First test is to run `yarn lint`, and verify that output matches before and after this change.
Second test is to change the ESLint config to use the "old" packages (under `react-native-commnuity`) and run `yarn lint` to make sure that they work as expected. This is what customers will experience, until they manually move to the new ESLint packages.
Reviewed By: cortinico
Differential Revision: D41520500
Pulled By: hoxyq
fbshipit-source-id: a61e5ae15d5aaf11f0143a3b0257a60a03b1550b
Summary:
This PR updates the Cache strategy for the tarballs to include the React Native version we are building. In this way, when we publish a new Release/RC we are sure that we are going to rebuild a nmew
tarball. This should fix caching problems like:
- we have misconfigured the build script for the Hermes tarball, we then fix it, but we distribute the wrong cached artifacts
- the cached artifact has the wrong version
## Changelog
[Internal] - Fixed Hermes Tarball Cache Logic
Pull Request resolved: https://github.com/facebook/react-native/pull/35471
Test Plan:
1. CircleCI
The real way to check this is in the next RC cycle or in the next nightly.
Reviewed By: cortinico
Differential Revision: D41530651
Pulled By: cipolleschi
fbshipit-source-id: 45e8fd3b62c8e108d393d9463ff6762dfc6d3ec8
Summary:
This PR backports the changes in 0.71 to apply the same logic to decide when we have to build Hermes from source in both the `hermes-engine.podspec`
and in the `react_native_pods.rb` script.
## Changelog
[iOS] [Fixed] - Use the right logic to decide when we have to build from source
Pull Request resolved: https://github.com/facebook/react-native/pull/35469
Test Plan: Working on RC2
Reviewed By: cortinico
Differential Revision: D41529539
Pulled By: cipolleschi
fbshipit-source-id: 879522c2187df28f40f6bc699057e9ecfb7e25fb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35474
This cleans up our `on-issue-labeled` workflow and makes sure we use only github-scripts. So we don't need to checkout the code & run an external action.
Changelog:
[Internal] [Changed] - Move on-issue-labeled to use actions/github-script@v6
Reviewed By: cipolleschi
Differential Revision: D41522650
fbshipit-source-id: c93d10eddf5be2ca9f779389e8059633291c0138
Summary:
I'm getting `node_modules/react-native/Libraries/Events/EventPolyfill.js: Unexpected token, expected "{"` when building an app. Looking at the source code, it seems odd there'd be a return type defined for a constructor. Unless I'm missing something (I don't use flow), I think it should be removed?
## Changelog
[Internal] [Fixed] - Remove return type from constructor
Pull Request resolved: https://github.com/facebook/react-native/pull/35466
Test Plan: N/A
Reviewed By: jacdebug
Differential Revision: D41527010
Pulled By: yungsters
fbshipit-source-id: 9f4faf1305ebe1915f5bcf07fc86b7437aed0c97
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35459
Changelog:
[Internal] [Changed] - now bootstrapping Verdaccio before template app initialization, this is required because react-native migh depend on some package which version is not yet published to npm
Reviewed By: cipolleschi
Differential Revision: D41521496
fbshipit-source-id: 6183ab02c697d9d08e9dca5b323bd7a11a749c3a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35464
This extends the buildAll task to build both RNTester Debug and Release
We can finally do this now as debug and release are fully isolated
and don't clash on each other.
Changelog:
[Internal] [Changed] - Build RNTester Release inside buildAll
Reviewed By: cipolleschi
Differential Revision: D41521995
fbshipit-source-id: 37ec5e3b55080372f01f2736c1bb020b3776b193
Summary:
Build hermesc in Xcode run script phase, so it ends up inside `Pods/hermes-engine/buld_host_hermesc`. All the the housekeeping is now done by CocoaPods and Xcode, and we can get rid of all the setup/cleanup code.
Changelog:
[iOS][Changed] - Build hermesc in Xcode run script phase.
Reviewed By: cipolleschi
Differential Revision: D41521987
fbshipit-source-id: 336854fa23582255cba6d161acf2cc791cac9d00
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35463
This will allow us to easily retrieve debug/release APK for
both RN-Tester and the Template jobs for every run of the CI.
Changelog:
[Internal] [Changed] - Store RN Tester and Template APKs for Android on CI
Reviewed By: cipolleschi
Differential Revision: D41521977
fbshipit-source-id: e2ed60921fd005425d3915323b18dde2851e7fc2
Summary:
We don't really run AVD (Emulators on CI) so those steps
are entirely unnecessary and skipped every time. I'm removing them.
Changelog:
[Internal] [Changed] - Remove AVD code from Android CI
Reviewed By: cipolleschi
Differential Revision: D41521976
fbshipit-source-id: 2737ef0dfc84198ab9b837819c16ae46280ba43f
Summary:
Fixes https://github.com/facebook/react-native/issues/35429
This fix is fairly straightforward. Instead of hardcoding two separate paths for this repo or a simple user's project, we ask Node to resolve `react-native-codegen`.
Because `react-native-codegen` is moved [into the `/packages/*` folder](https://github.com/facebook/react-native/blob/main/package.json#L104), it's part of a workspace in this repository. That means that this fix works not only for monorepos in general but also resolves the right path within the react native repository.
You can test this out yourself when running this command in either the root, or any other workspace in this repository:
```bash
node --print "require('path').dirname(require.resolve('react-native-codegen/package.json'))"
```
I've tested this on Node 16 and 18, and seems to work nicely. Note that you _**have to specify `react-native-codegen/package.json`**_. That's because the `react-native-codegen` package itself is technically invalid; it's missing an entry point within the package (no `main`). When running `node --print "require.resolve('react-native-codegen')"` Node can't resolve the main entry point, and will fail during this process.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[iOS] [Fixed] - Fix incorrect codegen CLI paths in monorepo projects
Pull Request resolved: https://github.com/facebook/react-native/pull/35430
Test Plan: See PR https://github.com/facebook/react-native/issues/35429
Reviewed By: cortinico
Differential Revision: D41475878
Pulled By: cipolleschi
fbshipit-source-id: f0c362b64cf9c3543a3a031d7eaf302c1314e3f0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35456Fixes#35439
There is a bug in AGP 7.3.x which is causing assets to don't be copied properly inside the
final artifact: issuetracker.google.com/issues/237421684
As AGP 7.4.x is really close to release (is in Beta5, should be released stable in the next weeks)
we should be fine by bumping to beta5.
This also requires a bump of RNGP
Changelog:
[Android] [Changed] - Bump AGP to 7.4.x
allow-large-files
Reviewed By: cipolleschi
Differential Revision: D41519549
fbshipit-source-id: 60d568a3e49798a23f1d7bf4839ab58bd5549aba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35461
This is another library which is adding prefab support as it's needed by
Expo libraries and Reanimated.
Changelog:
[Internal] [Changed] - Allow `reactnativejni` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D41520801
fbshipit-source-id: 91142a5b5051cfba478d93a2475a178eed6fbb29
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35460
Reanimated reported that `react_nativemodule_core` was missing some headers.
Specifically the one from ReactAndroid::react_debug, ReactAndroid::react_render_core, ReactAndroid::glog,
and ReactAndroid::react_render_debug.
I'm adding them here so they get included in the shipped headers for `react_nativemodule_core`
Changelog:
[Internal] [Changed] - Add missing headers to `react_nativemodule_core` prefab module
Reviewed By: cipolleschi
Differential Revision: D41520751
fbshipit-source-id: 4627a2d0f880d4bb3ff2f0e43cd735cf9a3f2f9a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35458
We're adding prefab support for those modules as they're needed by Reanimated
and we're exposing headers for them as well.
Changelog:
[Internal] [Changed] - Add prefab for _uimanager _scheduler and _mounting
Reviewed By: cipolleschi
Differential Revision: D41520606
fbshipit-source-id: 76f3c81705e99057b92cd9b86d0601a2b1410f95
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35457
This exposes `hermes-executor` to be consumed via prefab so that
libraries can depend on it and use its symbols if needed (Expo and Reanimated need it).
Changelog:
[Internal] [Changed] - Expose `hermes-executor` to be consumed via prefab
Reviewed By: cipolleschi
Differential Revision: D41520019
fbshipit-source-id: d590a043ea89fdd8ff41b0ed20900c9cf381a1e4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35454
Historically, we used to have hermes-executor debug and release as separate dynamic libraries.
This makes it impossible to prefab this library, so I have to reconcile it into a single library.
This will also help keep the setup consistent with the internal (BUCK) where we have a single target.
Changelog:
[Internal] [Changed] - Consolidate hermes-executor-debug and -release inside a single target
Reviewed By: cipolleschi
Differential Revision: D41519119
fbshipit-source-id: d9ddc30b72164daa29c735836ea433fd4d917fc8
Summary:
This script phase is added to the main target of the user project.
Adding it to the hermes-engine target is redundant and does nothing useful.
Changelog:
[iOS][Changed] - Do not add "Copy Hermes Framework" script phase to hermes-engine target.
Reviewed By: cipolleschi
Differential Revision: D41521276
fbshipit-source-id: a024fa33f7ec1605d1d6021f436d3d397871a50c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35445
As Flipper version is a bit old, let's bump it to the latest stable: 0.174.0.
This is a follow-up from D33583090 (https://github.com/facebook/react-native/commit/50057158ca32842d70160541e3cb5d4bd512f8f5).
At the time, it wasn't possible to update to the latest stable Flipper as crashes were observed due to NDK mismatch.
Changelog:
[Android] [Changed] - Bump Flipper to 0.174.0
Reviewed By: cortinico
Differential Revision: D41492705
fbshipit-source-id: 9ec205bb0b8e4ddcb56355a194cae0a64f3345d6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35455
This little change allows to support Gradle Configuration cache in user projects:
https://docs.gradle.org/current/userguide/configuration_cache.html
It allows to save several seconds on the build time.
We'll keep it disabled for now, but Gradle plans to enable it by default for everyone
in the future, so this changes makes us ready for it.
Changelog:
[Internal] [Changed] - RNGP - Correctly Support Gradle Configuration Cache
Reviewed By: cipolleschi
Differential Revision: D41519506
fbshipit-source-id: 6252546e811deb0777c0aab5332291368be7fa8f
Pieter De Baets
Zihan Chen (MSFT)
Nicola Corti
Luna Wei
Ali Akbar Azizi
shivenmian
Vojtech Novak
Moti Zilberman
Marco Fiorito
Riccardo Cipolleschi
Christoph Purrer
Moti Zilberman
Thibault Malbranche
Riccardo
Ruslan Lesiutin
Steve Shreeve
Lorenzo Sciandra
LeoTM
Adam Foxman
Petr Bela
Dmitry Rykun
Cedric van Putten
Lorenzo Blasa