Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/56801
In preparation for enabling `enableSyncVoidMethods` (D104331837), which makes TurboModule void methods execute synchronously on the JS thread instead of being dispatched asynchronously.
Currently, this module overrides `methodQueue` to return `dispatch_get_main_queue()` so its void methods execute on the main thread. When `enableSyncVoidMethods` is enabled, the `methodQueue` override is ignored for void methods — they execute directly on the JS thread. This causes crashes for any UI operations that must run on the main thread.
**Fix:** Remove the `methodQueue` override. The `alertWithArgs` method already dispatches UI work onto the main thread via `RCTExecuteOnMainQueue`, so it is already safe.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D104771644
fbshipit-source-id: 4f1eae55c64e56990efc20c4b32af1d722520037
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/56825
Disable `babel/plugin-transform-block-scoping` when `customTransformOptions.unstable_preserveBlockScoping` is truthy. This allows us to experiment with native let/const block scoping support in Static Hermes.
Changelog: [Internal]
Reviewed By: vzaidman
Differential Revision: D93013927
fbshipit-source-id: 6e2c1274426943fcf1ce5a8c09d677e1d0afb35f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/56824
Update the `simplifyTypes` transform (Flow → TS generation) to prune non-overlapping keys from `Omit<>` helpers in TypeScript `interface` unions.
This greatly reduces API snapshot churn/inflation in the next two diffs, which convert a number of `type` declarations (trivial unions) to `interface` (`Omit<>` required for correct union).
#### In detail
`flow-api-translator` emits `Omit<ParentType, keys>` to faithfully translate Flow's object spread override semantics to TypeScript.
```
// Flow
type Base = {x: string, y: number};
type Child = {...Base, x: boolean}; // Later properties in an object spread override earlier ones
// TypeScript
type Base = {x: string; y: number};
type Child = Omit<Base, "x" | "y"> & {x: boolean}; // Later properties in an object spread *merge*, rather than override. So we must use Omit<> for matched keys.
```
For `interface` type unions with overlapping keys, this can result in a number of unnecessary lines in the API snapshot, with little/no human readable value.
This diff extends existing `Omit<>` handling by `simplifyTypes` to recursively resolve all property keys reachable from a type, and prune keys that don't exist on the parent type.
```
// TypeScript
type Child = Omit<Base, "x"> & {x: boolean}; // Only "x" matched - strip `| "y"`
type ChildTwo = Base & {z: string}; // No property collision - strip entire `Omit<>`
```
- See changes to `ReactNativeApi.d.ts`, [P2325468482](https://www.internalfb.com/phabricator/paste/view/P2325468482?view=diff) for examples.
- **Decision point**: This diff opts to preserve correctness in TS — even though the snapshot isn't/isn't intended to be read directly/programatically, vs the conciseness tradeoff if we dropped all `Omit<>`s (human readable but ambiguous to the typechecker).
Changelog: [Internal] - JS API snapshot changes are a simplification refactor only
Reviewed By: robhogan
Differential Revision: D105150070
fbshipit-source-id: 43b0ef517164332a5cfaee7a5de5747749ac5e7c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/56746
Add an RNTester PlatformTest case that calls Image.getSize against a small PNG, a large JPEG, and an EXIF-rotated JPEG, then verifies the dimensions reported by native image metadata. Extend the existing Image Maestro flow to open the new test and wait for the pass result, so the same flow can run against Android and iOS RNTester builds.
Changelog:
[Internal][Added] - Add RNTester device coverage for Image.getSize dimensions
Reviewed By: christophpurrer
Differential Revision: D104535939
fbshipit-source-id: 4f181ce7320af679dd4c409a5c813555914e580c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/56819
The native iOS touch system can occasionally dispatch touch events to JavaScript where `nativeEvent.changedTouches` is undefined due to inconsistencies between local and UIKit touch registries. This causes a TypeError crash in `ResponderTouchHistoryStore.recordTouchTrack` when it unconditionally calls `.forEach()` on `changedTouches`.
The fix adds a defensive null check: if `changedTouches` is null/undefined, we log a DEV warning and bail out early from `recordTouchTrack`. Additionally, `nativeEvent.touches` accesses use optional chaining to prevent secondary crashes.
Changelog: [iOS][Fixed] - Fix TypeError crash in ResponderTouchHistoryStore when changedTouches is undefined
Reviewed By: fkgozali
Differential Revision: D105023000
fbshipit-source-id: d3ade24e93f45614b094932e436f7190c8c0a985
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/56814
Any time we have a non-nullable accessibilityState prop, it appears to always set `expanded` false, which causes most Android screen readers to append or prepend "collapsed". This fixes the issue.
## Changelog
[Android][Fixed] Screen reader behavior for accessibilityState expanded
Reviewed By: javache
Differential Revision: D105035390
fbshipit-source-id: 4b3b1b2a9b6e661cfde0f39d7de6a7cd7af91bb0
Summary:
Two developers (or one developer on two paths, or CI vs. local) running pod install on the same React Native project at the same commit get different SPEC CHECKSUMS entries for React-Core-prebuilt and ReactNativeDependencies in Podfile.lock. That breaks pod install-deployment style verification and any workflow that expects Podfile.lock to be reproducible.
CocoaPods derives each SPEC CHECKSUMS entry by hashing the in-memory podspec JSON. So anything embedded in source.http, prepare_command, user_target_xcconfig, etc. becomes part of the hash. Two podspec-resolution sites in this repo build their source.http from an absolute on-disk path.
Because project_pods_root is an absolute path, the resulting file://<abs>/... URL differs across machines or working-tree paths, so the hashed JSON differs, so the checksum differs.
### How
The Maven URL for each tarball is already computed inside both functions (stable_tarball_url(...) / nightly_tarball_url(...) / release_tarball_url(...)). Returning that URL — a stable string identical across machines — instead of the local file:// URL makes source.http path-free. CocoaPods downloads from Maven and caches the tarball itself, so functionality is preserved.
The pre-existing local-tarball download is kept untouched (its only remaining consumer is the opt-in `RCT_SYMBOLICATE_PREBUILT_FRAMEWORKS=1` dSYM-injection path in rncore.rb, which still needs file:// to feed CocoaPods a mutated tarball — gated by unless @download_dsyms so the leak is preserved only for that flag).
**Out of scope: **
hermes-engine.podspec has the same shape of leak in user_target_xcconfig.HERMES_CLI_PATH. Fixing it requires a paired change to ensure hermesc lands at the new ${PODS_ROOT}-relative path; that's a separate PR.
## Changelog:
[IOS] [FIXED] - Fix Pod install checksum drifting
Pull Request resolved: https://github.com/facebook/react-native/pull/56803
Test Plan:
Run `pod install` and verify that none of the following files contains absolute paths:
- Pods/Local Podspecs/React-Core-prebuilt.podspec.json
- Pods/Local Podspecs/ReactNativeDependencies.podspec.json
Reviewed By: christophpurrer
Differential Revision: D104889112
Pulled By: CalixTang
fbshipit-source-id: 97505a8bf78f7df57bda2d87705da5a20c934d2b
Summary:
X-link: https://github.com/facebook/yoga/pull/1949
Pull Request resolved: https://github.com/facebook/react-native/pull/56793
Migrate YogaWrap.java to YogaWrap.kt by adding Wrap to KOTLIN_ENUM_NAMES in enums.py and regenerating. All enums are now migrated to Kotlin — KOTLIN_ENUM_NAMES now contains all enum names.
Reviewed By: fabriziocucci
Differential Revision: D104666339
fbshipit-source-id: c30cac3d1f8cd5d8ac863c961ad7c90f4371cc58
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/56802
When MobileConfig flags (`cxxNativeAnimatedEnabled` and `useSharedAnimatedBackend`) are enabled server-side, `connectAnimatedNodeToShadowNodeFamily` is added to the method names list in `createNativeOperations()`. However, MobileConfig values and what is available in the AnimatedModule on the client can mismatch due to OTA updates — the JS bundle may have the flag enabled while the native module on the device does not yet implement the method. In this case, `nullthrows(NativeAnimatedModule)[methodName]` returns `undefined`, which gets queued as `() => undefined(...args)` and throws TypeError when the queue is flushed.
This fix adds a runtime check that `NativeAnimatedModule?.connectAnimatedNodeToShadowNodeFamily != null` before including the method in the list, preventing the mismatch from surfacing. The specific guard at the registration site is sufficient — if the method is not available on the native module, it will never be registered, so the general null guard in the method wrapper is unnecessary.
Fixes T270861607.
Changelog: [Internal]
Reviewed By: zeyap
Differential Revision: D104775294
fbshipit-source-id: ece86a3ab37792bf9624985eebfc53059af61677
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/56772
Upgrades to TypeScript 6.0.3 and updates `typescript-eslint/*` for TS 6.0 compatibility across `react-native` and `metro`.
#### Motivation
TypeScript 6.0 (Mar 2026) will resolve https://github.com/facebook/react-native/issues/53565. Before updating in the React Native CLI template, align in RN and Metro source for consistency.
This is an internal change since:
- This upgrade only applies to TS analysis of these repos' source code.
- Edits to `react-native/typescript-config/tsconfig.json` (which *is* distributed) maintain backwards compatibility.
#### Changes
**react-native**
- Bump `typescript` from `^5.8.3` to `^6.0.3`
- Bump `typescript-eslint/*` from `^8.24.0` to `^8.59.2`
- Replace deprecated `moduleResolution: "node"` with `"node16"` and `target: "es5"` with `"es2015"` in codegen-typescript-test
- Add explicit `types: ["jest", "node"]` where needed (TS 6.0 defaults `types` to `[]`)
- Set `strict: false` in configs that only enable specific strict flags (TS 6.0 defaults `strict` to `true`)
- Update `ModuleResolutionKind.NodeJs` to `Node16` in build config
**metro**
- Bump `typescript` from `5.8.3` to `^6.0.3`
- Bump `typescript-eslint/*` from `^8.36.0` to `^8.59.2`
- No tsconfig changes needed (`tsconfig/node20` preset is already TS 6.0 compatible)
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D104658690
fbshipit-source-id: 9a2feeb257d5783431941a911b17065fcd0389a5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/56800
Reproduces, in a standalone gtest, the use-after-free race between Scheduler
teardown and pending rendering-update lambdas previously enqueued via
runtimeScheduler->scheduleRenderingUpdate inside
Scheduler::uiManagerDidFinishTransaction.
The lambda captures the SchedulerDelegate by raw pointer; when the delegate
is destroyed (as part of an instance teardown triggered by an uncaught fatal
error) before the lambda runs, the dereference is a use-after-free unless
the invalidation-token guard in Scheduler::setDelegate
(enableSchedulerDelegateInvalidation) is enabled at queue time.
The test:
- Drives the *real* Scheduler::uiManagerDidFinishTransaction so the lambda
is enqueued via the regular code path into a real RuntimeScheduler's
pending-rendering-updates queue.
- Initiates teardown via an uncaught JSI host-function throw routed through
RuntimeScheduler's onTaskError callback (the test's analog of a host-side
fatal handler), which drops the delegate.
- Triggers the next event loop tick to drain the queue.
Three test cases:
1. Sanity_LambdaRunsOnNextTickWhenDelegateAlive -- baseline: lambda runs and
reaches the delegate when no teardown happens.
2. GuardEnabled_JSThrowInitiatedTeardownIsSafe -- with the guard ON, the
pending lambda observes the invalidation token after teardown and returns
without touching the freed delegate. Safe.
3. GuardDisabled_JSThrowInitiatedTeardownIsUAF -- with the guard OFF, the
lambda dereferences the destroyed delegate. Caught by EXPECT_DEATH via a
magic-sentinel ASSERT_EQ in the recording delegate, or by AddressSanitizer
on the vptr load.
Fantom is intentionally not used here: it shares the global runtime VM across
tests, which would interfere with this test's contract that no further JS
executes after a fatal-driven instance teardown.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D104777850
fbshipit-source-id: 7ecacaf21a4a9b121575fcc66c2fcbb6bfd4adc7
Summary:
`Image.getSize` and `getSizeWithHeaders` call Fresco's `fetchDecodedImage`, which returns a `CloseableImage` whose width / height reflect the bitmap after Fresco's automatic downsampling (typically capped at the screen size).
For sources larger than the screen this returned the wrong dimensions. ex: a 4000x3000 image on a 1920x1080 device came back as 1920x1440.
Switch to `fetchEncodedImage` and read the dimensions from the parsed image metadata (JPEG / PNG / WebP / HEIF headers), so the values are the true source dimensions. Swap width / height for 90°/270° EXIF rotation to match the iOS behavior in `RCTImageLoader`.
Fixes https://github.com/facebook/react-native/issues/33498Closesfacebook/fresco#2236
## 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
-->
[ANDROID] [FIXED] - `Image.getSize` and `Image.getSizeWithHeaders` now return the true source dimensions instead of Fresco's downsampled values
Pull Request resolved: https://github.com/facebook/react-native/pull/56736
Test Plan:
In the RNTester app, add:
```ts
useEffect(() => {
Image.getSize(
'https://images.pexels.com/photos/842711/pexels-photo-842711.jpeg?auto=compress&cs=tinysrgb&w=1260&h=750&dpr=2',
(width, height) => {
console.log({width, height});
},
);
}, []);
```
### Before
<img width="811" height="467" alt="before" src="https://github.com/user-attachments/assets/6fb401ed-cf5a-4496-bcc1-4cfd243bc0b7" />
### After
<img width="811" height="467" alt="after" src="https://github.com/user-attachments/assets/dc809d5f-c554-45d6-a3a3-7712bf39ac44" />
Reviewed By: javache
Differential Revision: D104533593
Pulled By: Abbondanzo
fbshipit-source-id: f087d528474c40cffbf24eb1e3958b4b18fb118e
Summary:
X-link: https://github.com/facebook/yoga/pull/1943
Pull Request resolved: https://github.com/facebook/react-native/pull/56794
Migrate YogaLogLevel.java to YogaLogLevel.kt by adding LogLevel to KOTLIN_ENUM_NAMES in enums.py and regenerating. Also adds DO_NOT_STRIP support to the Kotlin codegen path to preserve the DoNotStrip annotation.
Reviewed By: fabriziocucci
Differential Revision: D104666343
fbshipit-source-id: 6307e0f72559d505a8db115d63669271cbd8754a
Summary:
Fixes https://github.com/facebook/react-native/issues/54123
In RN 0.80, `betterHitTest:withEvent:` in `RCTScrollViewComponentView` was added, which returns `self` (the `RCTScrollViewComponentView` wrapper view) when a touch point falls inside the scroll view's bounds. This causes touches in the contentInset area — where no content is rendered — to be absorbed by the wrapper rather than forwarded to the underlying UIScrollView, making scroll gestures in that region completely non-functional.
The fix returns `_scrollView` instead of `self`, so hit-tested touches are correctly attributed to the `UIScrollView` and scrolling works throughout the full bounds, including the inset area.
## Changelog:
[IOS] [FIXED] - Fix ScrollView touch events ignored in contentInset area on Fabric
Pull Request resolved: https://github.com/facebook/react-native/pull/56747
Test Plan:
Couldn't use the snack-repro from https://github.com/facebook/react-native/issues/54123 since this requires a native change. But using the `ScrollViewSimpleExample` from the RNTester, and removing a lot of the items demonstrates the behaviour change.
The two videos show attempted dragging from the region below the ScrollView content.
### Before: Dragging in the inset area does nothing — scroll view does not respond
https://github.com/user-attachments/assets/55468ca8-78a7-4034-9e34-0191d55f7da1
### After: Dragging in the inset area scrolls the content correctly
https://github.com/user-attachments/assets/d1f10729-9b41-4a55-8738-16faf27031d7
Reviewed By: christophpurrer
Differential Revision: D104644045
Pulled By: javache
fbshipit-source-id: c8b856ff133705f2197ce9938d5ebafae46d0c17
Summary:
Syncs the in-package AppState API documentation with the Android AppState clarification added in facebook/react-native-website#5079.
Android AppState `background` was already documented as including another `Activity`. This clarifies that temporary system activities, such as autofill credential pickers, are included too.
## Changelog:
[GENERAL] [CHANGED] - Clarify Android AppState background API documentation.
Pull Request resolved: https://github.com/facebook/react-native/pull/56779
Test Plan:
Documentation-only change.
Verified with:
- `git diff --check`
- `prettier --check packages/react-native/Libraries/AppState/AppState.js packages/react-native/Libraries/AppState/AppState.d.ts`
Reviewed By: cortinico
Differential Revision: D104810583
Pulled By: huntie
fbshipit-source-id: 17d2ec312c65c91b8086bd382f733f3cceb4da8a
Summary:
The `onMouseLeave` handler in `Pressability` stores the delayed `onHoverOut` timeout in `_hoverInDelayTimeout` instead of `_hoverOutDelayTimeout`. This is a copy-paste error from the `onMouseEnter` handler above it.
The Pointer Events path (`onPointerLeave`, line 593) correctly uses `_hoverOutDelayTimeout`. The Mouse Events path (`onMouseLeave`, line 645) incorrectly uses `_hoverInDelayTimeout`.
This causes:
- `_cancelHoverOutDelayTimeout()` to not cancel the pending `onHoverOut` callback
- `_cancelHoverInDelayTimeout()` to incorrectly cancel `onHoverOut` instead of `onHoverIn`
- A pending `onHoverIn` timeout to be silently overwritten if it exists
Affects non-mobile platforms (web, desktop) when `delayHoverOut > 0`.
## Changelog:
[General] [Fixed] - Fix hover out timeout stored in wrong variable in Pressability
Pull Request resolved: https://github.com/facebook/react-native/pull/56328
Test Plan:
- All 37 existing Pressability tests pass: `yarn jest packages/react-native/Libraries/Pressability/__tests__/Pressability-test.js`
- Prettier and ESLint checks pass.
- Verified by code inspection: the Pointer Events path (line 593) correctly uses `_hoverOutDelayTimeout`, the Mouse Events path (line 645) now matches.
Reviewed By: christophpurrer
Differential Revision: D104657310
Pulled By: javache
fbshipit-source-id: 66b0b353168102a5e8664e0c9b558cb6a1d7503c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/56720
Introduces a generic TextEffect system that lets apps register custom text
span effects without modifying React Native core. This can serve for use cases like `react-native-live-markdown`, or product specific effects.
The implementation is pretty dumb right now. It's just a marker, where we can add some JSON serializable data, to be serialized during Spannable creation on JS side MapBuffer.
**JS API:**
```js
import requireNativeTextEffect from 'react-native/Libraries/Text/requireNativeTextEffect';
const Spoiler = requireNativeTextEffect<{}>('RCTSpoiler');
<Text>Normal <Spoiler>hidden text</Spoiler></Text>
```
**Android registration** (via FabricUIManager):
```kotlin
val fabricUIManager = UIManagerHelper.getUIManager(
context, UIManagerType.FABRIC) as? FabricUIManager
fabricUIManager?.textEffectRegistry?.register("RCTSpoiler") { props ->
MyCustomSpan()
}
```
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D98812222
fbshipit-source-id: 7000a0452b7592cdc2b26e7eaa37ec95736efce4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/56775
babel/plugin-transform-modules-systemjs versions >= 7.12.0 and <= 7.29.3 are affected by CVE-2026-44728 (GHSA-fv7c-fp4j-7gwp), a HIGH severity vulnerability. The react-native repo resolves this package at 7.25.9 via babel/preset-env. This adds a Yarn resolution to force the package to ^7.29.4, the first patched version.
#Changelog: [Internal]
[General] - Bump `babel/plugin-transform-modules-systemjs` to 7.29.4
Reviewed By: robhogan
Differential Revision: D104687110
fbshipit-source-id: ce95afcae024d6ea2a83eae9067d3ab3fd3baa0c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/56752
Delete the old script files that were renamed in prior commits:
- scripts/releases/use-hermes-nightly.js (renamed to use-hermes-prebuilt.js)
- scripts/try-set-nightly-hermes-compiler.js (renamed to try-set-hermes-compiler-prebuilt.js)
These deletions were accidentally omitted from their respective rename commits.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D104650744
fbshipit-source-id: a0f1e3279622f792a0e79d011d942539e5168eaf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/56751
The hermes-utils test used an old-style Hermes git tag
('hermes-2022-04-28-RNv0.69.0-...') as its fixture. Hermes now uses semver
version strings (e.g. '250829098.0.13'). Update the fixture to match the
current format so the test better represents real usage.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D104649627
fbshipit-source-id: 00562fd7d0325acde6f4ccf906e4c34e3c705375
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/56757
Update comments that still say 'Hermes V1' as if it is an opt-in feature.
Since Hermes (formerly called Hermes V1) is now the only supported engine:
- hermes-engine.podspec: drop 'when using Hermes V1' from hermesc note
- PathUtils.kt: rewrite the hermesc path comment to drop the 'opted in to Hermes V1' phrasing
- hermes-engine/build.gradle.kts: 'Hermes V1 by default...' -> 'Hermes by default...'
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D104649634
fbshipit-source-id: 9b0a05ed013c7ba908c7abe467d5e3c1c3c2f26c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/56756
The use-hermes-nightly boolean input of prebuild-ios-core.yml was misleadingly named.
It controls whether to use the latest prebuilt Hermes from npm's latest-v1 dist-tag
(not a 'nightly' build). Rename:
- prebuild-ios-core.yml input: use-hermes-nightly -> use-hermes-prebuilt
- Update description of the input
- Update comment to move the TODO note inline
- Update callers in nightly.yml and test-all.yml
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D104649628
fbshipit-source-id: 71c75b07caebfe5e7d03e80d47cefba883843c9a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/56758
Rename scripts/try-set-nightly-hermes-compiler.js to
scripts/try-set-hermes-compiler-prebuilt.js. The script sets the hermes-compiler
version to the latest prebuilt (latest-v1 on npm), not a nightly build.
Update the preinstall script reference in the root package.json.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D104649635
fbshipit-source-id: 8375d0518ea8c9ca99a59fd65366210eeea91e50
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/56753
The functions getLatestHermesNightlyVersion() and updateHermesVersionsToNightly() were
misleadingly named: they actually fetch from the 'latest-v1' npm dist-tag, not a 'nightly'
tag. Rename them to better reflect what they do:
- getLatestHermesNightlyVersion -> getLatestHermesVersion
- updateHermesVersionsToNightly -> updateHermesVersionsToPrebuilt
Update all call sites in publish-npm.js and publish-npm-test.js.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D104649629
fbshipit-source-id: b1d60b9bb48ef51946e99877a73d5760db585a4c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/56759
The legacy Hermes V0 nightly dist-tag ('nightly') has been removed. This commit
cleans up the ios-prebuild Hermes download logic:
- Remove the 'nightly' sentinel string and getNightlyVersionFromNPM()
- Remove DOWNLOAD_PREBUILT_NIGHTLY_TARBALL source type and downloadPrebuiltNightlyTarball()
- Remove getNightlyTarballUrl() (was fetching from Maven Snapshots for V0 nightlies)
- Rename getLatestV1VersionFromNPM -> getLatestHermesVersionFromNPM
- Update prepare-app-utils.js to use 'latest-v1' instead of 'nightly' for HERMES_VERSION
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D104649632
fbshipit-source-id: 91f7c67ee59a3ef835d78146e5ad5ecab25a17bf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/56754
Hermes V1 (Static Hermes) is now always enabled. Remove the isHermesV1 variable and inline its effects:
- enableRegenerator is always based on dev mode (was isHermesV1 && dev)
- preserveClasses is always true (was isHermesV1)
Also update the comments to drop the 'V1' framing.
## Changelog:
[Internal] -
Reviewed By: cortinico
Differential Revision: D104649639
fbshipit-source-id: 70d4cbc0ad365df551b744e3cc16e880ce41c90c
Ivor Zhou
