Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39828
Active Suppert released a new Gem which is incompatible with Cocoapods 1.13.0, the latest release, as they removed a method used by cocoapods.
This fix ensures that we install compatible versions of the Gem.
## Changelog:
[iOS][Fixed] - Set the max version of Active support to 7.0.8
Reviewed By: hoxyq
Differential Revision: D49949782
fbshipit-source-id: 278097502d3a416567cc8c0b90090fee4fb21503
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39795
X-link: https://github.com/facebook/yoga/pull/1412
Android NDK 25 uses a version of libc++ that is more than three years old, missing a lot of basic features of C++ 20. This is rectified in NDK 26 (latest LTS NDK), which brings us up to date with latest Clang (17, released this year), and adds a new policy where future NDK versions will bump libc++ as part of bumping LLVM/Clang.
This requires an a beta AGP version (and corresponding Android Studio Preview). Based on how far we are historically, it wouldn't be a surprise if we see the stable release this month (well before the RN 0.74/Yoga 3.0 cut, even in the worse case).
Changelog:
[Android][Changed] - Use NDK 26
Reviewed By: yungsters
Differential Revision: D49895949
fbshipit-source-id: 37bb4d1fdf81137be7f14f6675b4e079c6f861e4
Summary:
This bumps folly, to absorb https://github.com/facebook/folly/commit/45fffa629d6bf7321391222d40613d75e8e067d7 which fixes warnings in XCode 15, and NDK 26 (treated as error bc we have better hygiene there). We then bump a little bit further to get past a new warning added, then fixed later.
Need to manually set `FOLLY_HAVE_GETTIME` on Apple because of the silliness described in https://github.com/facebook/folly/issues/1470#issuecomment-1746035194
There is not a combination of Folly, and Android libc++, that has fixes for warnings, but doesn't require the new libc++ in NDK 26. It is expected then that this commit will fail the build, but the next should succeed, and the two must be landed at the same time.
Changelog: [Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/39798
Reviewed By: fkgozali
Differential Revision: D49897681
Pulled By: NickGerleman
fbshipit-source-id: 52b97ed5b302abf9e27f38dc655207827852dcc3
Summary:
This is what Folly is built against internally. Bump the version we use, and the standard we compile with, to take some different paths, and see if we fix some warnings caused by FMT with the ndk bump.
Changelog:
[General][Breaking] - Bump fmt to 9.1.0
Pull Request resolved: https://github.com/facebook/react-native/pull/39799
Test Plan: Passes in CircleCI
Reviewed By: cortinico, yungsters
Differential Revision: D49900112
Pulled By: NickGerleman
fbshipit-source-id: 3f11080555ef20aeb9291d1096ffa6077b3b3bbd
Summary:
Changelog: [Internal]
sync void execution is now hooked up to mc
Reviewed By: mdvacca
Differential Revision: D49854130
fbshipit-source-id: fb4241b11a80d44318b382e2757fe7fcbfba4fb1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39759
Changelog: [Internal]
as part of the sync void tm methods test, there are some modules that do not behave correctly when trying to execute their methods on the js thread.
this module accesses UIKit, so we explicitly dispatch async to the main thread
Reviewed By: mdvacca
Differential Revision: D49835587
fbshipit-source-id: 30b5b58b6df4686bd81dbf8dbeaae275c98fa2e1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39761
Changelog: [Internal]
as part of the sync void tm methods test, there are some modules that do not behave correctly when trying to execute their methods on the js thread.
to maintain the old behavior, we dispatch them explicitly in the implementation.
Reviewed By: mdvacca
Differential Revision: D49693966
fbshipit-source-id: 870118d0aeb5cfb4155eebf6afa7dfc724d4cecc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39760
Changelog: [Internal]
void functions are kinda special right now for the following reasons:
- they can be executed async or sync right now
- they don't return any value
thus, it makes sense for us to separate the invocation logic out and clean up the logic for retrieving return values specifically.
Reviewed By: javache
Differential Revision: D49652998
fbshipit-source-id: 7dba03adb8154e73ed75f8c2864294215c748107
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39805
## Changelog:
[Internal] -
This makes corresponsing text measure methods inside `TextLayoutManager` overridable, so that it can be substituted with a custom implementation without introducing a new "platform".
Rationale: CXX platform is rather general and less specific than Android or iOS, so we may potentially have multiple alternative implementations of text layout there.
An alternative could be making `TextLayoutManager` an interface across all the platforms, and actual implementations called e.g. `TextLayoutManagerImpl` in each of them, however this would be quite a bit bigger blast radius without much added benefit for Android/iOS.
Reviewed By: christophpurrer
Differential Revision: D49907594
fbshipit-source-id: dc8213ddb2313adaa86c2852d23bb038d80ac244
Summary:
We don't need this if-than-else because the initializeFlipper already checks if we're on bridgeless or not
Changelog:
[Internal] [Changed] - Do not guard initializeFlipper for bridgeless for RN Tester
Reviewed By: NickGerleman
Differential Revision: D49881903
fbshipit-source-id: e6bfc941b43382580bd418a5f27ad9426d300c69
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39809
It's currently possible for RN to crash the dev server by sending down an exceptionally large CDP response/event. Instead of making assumptions on the protocol spoken over the proxy, let's assume clients on either side of the proxy can be trusted to be well behaved (and to degrade gracefully when a large message is encountered).
Changelog: [General][Fixed] JS debugging: prevent dev server crash when a large CDP payload is returned from the device
Reviewed By: huntie
Differential Revision: D49642047
fbshipit-source-id: 07b134c9fa6aba7ce2208f71981d6d862281395f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39791
Bump `hermes-parser` packages to the latest released version.
Changelog: https://github.com/facebook/hermes/blob/main/tools/hermes-parser/js/CHANGELOG.md
Notable changes:
- Upgraded to the lastest version of emscripten for the parser.
- The babel interop logic now more closely matches babel's AST.
- The biggest change is we now add the `extra.raw` properties to literal nodes, which results in Babel more closely outputting literal sources. e.g. previously the following would happen `1.0` -> `1`, `'foo'` -> `"foo"` and `1n` -> `1` but now the raw source value is preserved.
- Upgraded `prettier-plugin-hermes-parser` to use the latest prettier formatting logic, which causes some minor formatting changes.
- `hermes-parser` no longer fails when the `component` name is used within a function type, e.g. `type Foo = (component: string) => void`.
Changelog: [Internal]
Reviewed By: SamChou19815
Differential Revision: D49838842
fbshipit-source-id: ebfd2f89852d1bd3b1671ce77f58240d7e17cfbb
Summary:
Add support for `Platform.isMacCatalyst`
By default, Mac catalyst reports the idiom as an iPad, but you can check if it is Mac catalyst with a macro
There is technically the possibility to have the idiom return as a Mac, but that's not the default and almost definitely doesn't work in RN
ignore-github-export-checks
## Changelog:
[IOS] [ADDED] Add support for `Platform.isMacCatalyst`
Pull Request resolved: https://github.com/facebook/react-native/pull/38187
Test Plan: It compiles
Reviewed By: cortinico
Differential Revision: D47664425
Pulled By: cipolleschi
fbshipit-source-id: 09f43694aa9b5f980204474f0e07779acd5ed2c7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39787
I've realized that some of the DevMenu strings were missing the `project="catalyst" translatable="false"`
tags so they ended up being fed to the translation pipeline.
We don't need those strings to be translated so I'm cleaning this up.
Changelog:
[Internal] [Changed] - Do not attempt to translate devsupport strings
Reviewed By: arushikesarwani94
Differential Revision: D49870688
fbshipit-source-id: 14188f4d391c7f8e2e6e92a394d85c58c8fbcf95
Summary:
https://github.com/facebook/react-native/commit/5f40f0800e64b4380d7897b2e8b9ff561d84b97c added a new prop and corresponding RCTConvert method for transformOrigin. Strangely, it added the RCTConvertMethod to a `RCTConvert+UIAccessibilityTraits` category.. which feels like the wrong spot for it. Let's just add it to the existing `RCTConvert+Transform` category. This also means we can get rid of the header if we move the `RCTTransformOrigin` struct into UIView+React (where it is used).
## Changelog:
[IOS][CHANGED] - Move `[RCTConvert RCTTransformOrigin:]` out of UIAccessibilityTraits category
Pull Request resolved: https://github.com/facebook/react-native/pull/39758
Test Plan:
Transform Origin example still works.
<img width="559" alt="Screenshot 2023-10-02 at 11 26 17 AM" src="https://github.com/facebook/react-native/assets/6722175/c7b863cc-3595-430d-8579-f8ce8e73c4f4">
Reviewed By: javache
Differential Revision: D49867993
Pulled By: NickGerleman
fbshipit-source-id: 1b2d5a9d08f0231040e7449f2eb75860f08bafa5
Summary:
This PR is in response to https://github.com/facebook/react-native/pull/39758#discussion_r1344839022 .
`RCTConvert.h` currently takes an import of `<Webkit/Webkit.h>` for... one enum: `WKDataDetectorTypes`. This has a few problems:
1) RCTConvert is JS engine agnostic, it shouldn't be depending on Webkit
2) As far as I can tell, this code is dead, we also define (and use) the UIKit equivalent `UIDataDetectorTypes`.
Let's just combine the two, update some JS typing, and get rid of the Webkit header import.
## Changelog:
[IOS] [CHANGED] - Remove `<Webkit/Webkit.h>` import in `RCTConvert.h`
Pull Request resolved: https://github.com/facebook/react-native/pull/39794
Test Plan: CI should pass
Reviewed By: rshest
Differential Revision: D49898701
Pulled By: NickGerleman
fbshipit-source-id: 5420cb62317e1186426aae019bcc43d27c49ea26
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39806
Same issue of the previous fix: jobs do not run by default on tagged build. I forgot to add the filter parameter in the jobs that build the slices for Hermes and packages it and therefore the build failed.
I added those filters, so now we should be able to release RC.1.
What puzzles me is how it is possible that the publish-npm jobs even started, given that it was set up to depends on a job called build_hermes_macos which was not executed in the pipeline. 🤔https://pxl.cl/3w2rr
## Changelog:
[Internal] - Make sure that the Hermes jobs starts when releasing
Reviewed By: dmytrorykun
Differential Revision: D49906898
fbshipit-source-id: ebbceb6cbc4dcd2ac22445610da1c52000c8ae2a
Summary:
Rewrite `RNTesterApplication` to Kotlin as per [Help us Kotlin-ify React Native tests - Round 2](https://github.com/facebook/react-native/issues/38825)
## Changelog:
[ANDROID] [CHANGED] - Rewrite RNTesterApplication to Kotlin, add AnnotationTarget property.
Pull Request resolved: https://github.com/facebook/react-native/pull/39557
Test Plan:
`yarn && yarn android` ✅
The only thing I'm kinda unsure of is whether `AnnotationTarget.PROPERTY` should be added, but it didn't let me annotate `reactHostInterface` without that and didn't compile.
<img width="637" alt="image" src="https://github.com/facebook/react-native/assets/33528752/8bc84870-f3f2-4a46-b076-6ee7e38bd735">
cortinico mdvacca
Reviewed By: cortinico
Differential Revision: D49598401
Pulled By: mdvacca
fbshipit-source-id: 105ae0c13c93dae0eeb2b6fa9040f03f42d2736a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39788
Hotfix for exiting `npx react-native start` when a session is connected. Partially reverts D49422206.
This lines back up with the original RN CLI and Expo implementations — explicitly calling `process.exit()`. We still aim to follow this up with graceful server shutdown.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D49880226
fbshipit-source-id: d2c76b2de21b9172dfd892141d1f679b808e043d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39595
X-link: https://github.com/facebook/yoga/pull/1404
These functions all ensure their returns are defined, but return FloatOptional anyway, making their callers have to deal with that possibility. Return `float` instead of `FloatOptional`, and do some additional cleanup.
Reviewed By: rshest
Differential Revision: D49531421
fbshipit-source-id: 95b21cade74e501dd54c7b6ca667c8c3859c5dae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39644
This makes Android Paper/Classic renderer fire `onLayout` events top down, like in Fabric/new Architecture. This gives a much more sane model for using layout events to calculate bottom/right-edge insets.
I was under the impression that Paper in general was bottom-up, but it turns out that is only true for Android and Windows (iOS seems totally deterministic).
This is a behavior change, but to my knowledge was never hit during the Fabric migration, and any JS code already written for both Android and iOS cannot make assumptions here anyways.
Changelog:
[General][Changed] - Make layout events top-down on Android classic renderer
Reviewed By: mdvacca
Differential Revision: D49627996
fbshipit-source-id: 29964b421dd420681d45348c7db16f211a6c087f
Summary:
The Loading.../Refreshing... indicator is currently broken on Android.
The reason is related to D42599220
We used to have a Toast shown to users on Android as a fallback, but as the
DevLoadingView is not always loaded as a module in the core package, this ends up in the banner never beign shown to the user (on RN Tester or template apps).
Changelog:
[Android] [Fixed] - Fix broken Loading/Refreshing indicator on Android
Reviewed By: cipolleschi
Differential Revision: D49876757
fbshipit-source-id: 400e002327ebca908e3e7a7f81c5066888ac4e9b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39591
Changelog: [Internal]
I'm refactoring this for a couple of reasons:
1) it isolates the void execution path, which we are changing now
2) switch case is safer than if else, in the future if we introduce new return types
Reviewed By: RSNara
Differential Revision: D49521866
fbshipit-source-id: 451c846ca15cc470cfeb5b2326d6eb2ffec74b25
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39589
Changelog: [Internal]
currently, turbomodule void methods run async by default, unless the consumer returns `RCTJSThread` in the `methodQueue` API.
we're looking to update this, so i'm introducing a flag at the module level that allows us to configure this behavior.
Reviewed By: RSNara
Differential Revision: D49521864
fbshipit-source-id: a6c61eb420b72199426e3dfdaec5fd090847efa5
Summary:
While inspecting the pipelines for the template, I realized that the caching was failing because the keys were malformed.
This PR fixes the malformed keys adding the missing "
## Changelog:
[Internal] - Fix cache keys for the Template
Pull Request resolved: https://github.com/facebook/react-native/pull/39786
Test Plan: The template jobs should not fail with `error computing cache key: template: cacheKey:1: unterminated quoted string`
Reviewed By: cortinico
Differential Revision: D49874270
Pulled By: cipolleschi
fbshipit-source-id: 5a23237ba826e87f2cd15566e63a1316291af595
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39597
X-link: https://github.com/facebook/yoga/pull/1406
Similar in vain to D49362819, we want to stop exposing pre-resolved CompactValue, and allow enum class usage without becoming annoying.
This also simplifies gap resolution a bit. I moved this to Style, to make it clear we aren't relying on any node state. I plan to do some similar cleanup for other resolution later.
Reviewed By: rshest
Differential Revision: D49530923
fbshipit-source-id: 47b06a7301fb283acc493dba159f496159d59580
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39775
ChoreographerCompat existed to support JellyBean, but given we target Android SDK 23+ now, this is safe to remove.
Changelog: [Android][Removed] Deprecated ChoreographerCompat.FrameCallback, use Choreographer.FrameCallback
Reviewed By: mdvacca
Differential Revision: D49826889
fbshipit-source-id: 5158c470553327b70a199168f5b7ed7071cc8c48
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39717
AsyncCallback is a better abstraction than the current usage of WeakCallbackWrapper and RAIICallbackWrapperDestroyer, and has way fewer gotchas. Making a few changes here to make it easier to use in various scenarios and match the behaviour we're already seeing in CallbackWrapper.
1) Remove the explicit copy constructor, since this prevents an automatic move constructor from being generated
2) Add a call variant which takes a lambda, for callers which need to manually create JSI arguments
3) Ignore AsyncCallback invocations when the underlying runtime has gone away.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D49684248
fbshipit-source-id: 8b49ec22cc409572ead80a85b10a190994bf0dd5
Riccardo Cipolleschi
Christoph Purrer
Nick Gerleman
Nick Gerleman
Hakeem King
Phillip Pan
Intl Scheduler
Ruslan Shestopalyuk
Nicola Corti
Moti Zilberman
Pieter Vanderwerff
Luna Wei
Jacob Parker
adriancuadrado
Rubén Norte
Pieter De Baets
Saad Najmi
David Vacca
Ian Levesque
Oleksii
Alex Hunt
huzhanbo.luc
Riccardo Cipolleschi