chore(0.84): merge up to 0.84.1 from upstream branch - #3067
Closed
Saadnajmi wants to merge 63 commits into
Closed
Conversation
#publish-packages-to-npm&next
#publish-packages-to-npm&next
Summary: Pull Request resolved: react#55113 Reverts react#55038 Dropping v20 (still in LTS) causes friction with Expo's LTS policy, so we're restoring support for v20.19. Changelog: [General][Added] Revert react#55038 Reviewed By: shwanton Differential Revision: D90467161 fbshipit-source-id: d876cf7869f11e04058f88239f553704e0706514
Summary: This change makes Hermes V1 the default engine for React Native for both platforms. This change needs to land before the branch cut of react native 0.84 bypass-github-export-checks ## Changelog: [iOS][Changed] - Make Hermes V1 the default engine for iOS Pull Request resolved: react#54989 Test Plan: 1. Run `bundle exec pod install` and verified that Hermes V1 is used when building from source <img height="480" alt="Simulator Screenshot - iPhone 17 Pro - 2025-12-29 at 11 28 44" src="https://github.com/user-attachments/assets/0889f16c-f2ee-4a0e-9a4d-529dd82c8283" /> 2. Run `prebuild-ios -s` and verified that the scripts downloads the Hermes V1 tarball <img width="831" height="324" alt="Screenshot 2025-12-29 at 10 37 53" src="https://github.com/user-attachments/assets/9a60565e-1e13-4967-a4a4-dd079e6b040f" /> 3. GHA and nightlies Reviewed By: vzaidman, cortinico, huntie Differential Revision: D89881943 Pulled By: cipolleschi fbshipit-source-id: 958b6d31bd4230ba4a5c7fee2bffc19e03dcbc89
…t#55072) Summary: Syncs `getAndroidResourceIdentifier` implementations between [`/community-cli-plugin/src/commands/bundle/assetPathUtils.js`](https://github.com/facebook/react-native/blob/main/packages/community-cli-plugin/src/commands/bundle/assetPathUtils.js#L72-L79) and [`/assets/path-support.js`](https://github.com/facebook/react-native/blob/main/packages/assets/path-support.js#L77-L85). Ideally, the former should use `react-native/assets-registry` directly so we don't need to sync. ## Changelog: [ANDROID] [FIXED] - Handle `unstable_path` query param in asset URLs Pull Request resolved: react#55072 Test Plan: n/a Reviewed By: javache Differential Revision: D90267467 Pulled By: Abbondanzo fbshipit-source-id: f4eb0053c6af02b67f3fb493ae76e290d6b354e5
…oading Apple SDKs (react#55141)
Summary: Use of `debug` was added in react#54978 but never declared. This causes `react-native config` to fail in pnpm setups. ## Changelog: [GENERAL] [FIXED] - Fixed missing dependency breaking `react-native config` in pnpm setups Pull Request resolved: react#55145 Test Plan: `yarn` in `xplat/js` didn't change any files Reviewed By: cortinico Differential Revision: D90589051 Pulled By: vzaidman fbshipit-source-id: b53a46a9b034d385e64a72f85d29e63da02522d7
#publish-packages-to-npm&next
Summary: So currently RN app is broken with following error if the `SWIFT_OBJC_INTEROP_MODE` is changed to `objcxx`. <img width="567" height="112" alt="image" src="https://github.com/user-attachments/assets/7a8e8cf4-a8a3-42d3-a65f-9943cbf296f2" /> ### Why do we need this interop ? So currently any pod that uses `objcxx` as interop (For example Any library created with Nitro modules) cannot be imported into App directly . <img width="548" height="59" alt="image" src="https://github.com/user-attachments/assets/b6d9fb7a-00df-4bf2-aa0c-c61fb3a6538f" /> We are using this in a nitro module where we override bundle url . And nitro-player for jellify app where we create a new scene for carplay . Currently we are using hacky stuffs like creating two pods to address this but the solution is messy. ### RCA for failing <img width="633" height="155" alt="image" src="https://github.com/user-attachments/assets/7eb811cc-d1ba-410d-902c-4217bfc47b40" /> Currently glog imports some things inside namespace which is not allowed. ### Fix This patches creates a module map that uses textual headers to prevent submodule creation. We can still keep using the old interop by default . Users who need to do this can change the interop themselves bypass-github-export-checks ## 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 --> [IOS][FIXED] - Fix glog namespace issue to allow using interop mode of objcxx Pull Request resolved: react#55117 Test Plan: To test this I forked Nightly repo and ran against all the libraries and nothing seems to fail With objcxx interop :- https://github.com/riteshshukla04/nightly-tests/actions/runs/20908210967 with Objc interop :- https://github.com/riteshshukla04/nightly-tests/actions/runs/20902452877 Reviewed By: cortinico Differential Revision: D90503097 Pulled By: cipolleschi fbshipit-source-id: c1b46e901ec1515998428e1f3ca46f9d48d17bd3
Changelog: [Internal]
Summary: Pull Request resolved: react#55157 Changelog: [Internal] At the moment, Fantom doesn't propagate the Hermes V1 opt-in to the React Native build, which causes the code that should be gated by compile-time flags to be compiled. Since Hermes V1 differs in some cases, the headers there are missing. This diff adds the opt-in propagation, so the code can be correctly compiled out. Reviewed By: cortinico Differential Revision: D90674696 fbshipit-source-id: d2adb131af4588e745c023703a893d0ecaaaee01
Summary: Pull Request resolved: react#55202 Changelog: [Internal] After changing Hermes V1 to be the default engine, Fantom tests started failing. This was due to a combination of changes, one of them being the change of default value for `HERMES_ENABLE_DEBUGGER`. In case of legacy Hermes it was enabled by default, while for Hermes V1 it's disabled by default. Fantom didn't explicitly set this flag, but the debug build of RN (which Fantom performs) requires it to be enabled. This diff explicitly sets this flag to true for Fantom builds. Reviewed By: cipolleschi, cortinico Differential Revision: D90849881 fbshipit-source-id: 17f8393872eacef26f927f50aaf364644d9b94d7
#publish-packages-to-npm&next
Summary: Fixes react#55243 Fixes an issue where iOS codegen fails when the React Native project is located inside a hidden folder (a folder starting with `.`, such as `~/.jenkins/workspace/` or `/.buildkite/builds/`). The issue was reported for React Native 0.79.4, but the bug affects all subsequent versions including the current main branch. The `findFilesWithExtension` function was checking if the entire absolute path contained `/.` to skip hidden folders. This caused false positives when the project workspace itself was under a hidden folder, resulting in all files being incorrectly filtered out and codegen producing empty results. The fix changes the check to only look at the current filename being iterated (`file.startsWith('.')`) rather than the full path, while preserving the existing `.pnpm` exception. ## Changelog: [iOS] [Fixed] - Fix codegen failing when project is inside a hidden folder Pull Request resolved: react#55259 Test Plan: Added unit tests for `findFilesWithExtension` that verify: - Hidden files/folders are still correctly skipped - The `.pnpm` folder exception still works - Projects under hidden folders (e.g., `/.jenkins/workspace/`) now work correctly Run tests with: ```bash yarn jest packages/react-native/scripts/codegen/__tests__/generate-artifacts-executor-test.js --testNamePattern="findFilesWithExtension" ``` All 3 tests pass. The critical test `works when project is under a hidden folder` fails without the fix (returns empty array) and passes with the fix. ### Example of the codegen failing on a dotted path 🔴 <img width="970" height="609" alt="Screenshot 2026-01-21 at 09 54 21" src="https://github.com/user-attachments/assets/247576c4-ce06-4656-93d7-06e880e779e3" /> - [`pod install` logs on Github Actions](https://github.com/dinisnunes1/.react-native-codegen-dotted-paths/actions/runs/21204831248/job/60998728238) - [example based on the Reproducer repo](dinisnunes1/.react-native-codegen-dotted-paths@main...test-dotted-path-codegen) ### Example of the codegen crawling working on a dotted path - with the fix ✅ <img width="938" height="700" alt="Screenshot 2026-01-21 at 10 15 56" src="https://github.com/user-attachments/assets/f36ef04d-e5ca-454e-907f-9af1fcd0a6d9" /> - [`pod install` logs on Github Actions](https://github.com/dinisnunes1/.react-native-codegen-dotted-paths/actions/runs/21205599303/job/61001213856) - [example based on the Reproducer repo - branch with RN `0.83.1` patched](dinisnunes1/.react-native-codegen-dotted-paths@main...test-codegen-fix) Reviewed By: cipolleschi Differential Revision: D91122133 Pulled By: cortinico fbshipit-source-id: 762564c874d5081521811e3a20d850a89861b99f
Summary: Pull Request resolved: react#54946 ## Summary: Adds support for `overflow`, `position`, `zIndex`, and `direction` layout props to be passed as `AnimatedProp` to the animation backend. The `PropName` enum is changed to the class enum because the `OVERFLOW` keyword is already defined in `math.h` when building with `XCode`. ## Changelog: [General][Added] - Added support for `overflow`, `position`, `zIndex`, and `direction` props to the AnimationBackend. Reviewed By: zeyap Differential Revision: D89543930 fbshipit-source-id: ff7f5f19c4b641b0c5121dfd7417ffd15b4c72cd
…om-source (react#55310) Summary: PR react#54707 removed `prefabPublishing = true` from hermes-engine when switching to prebuilt Hermes by default. This broke build-from-source because AGP no longer generates the CMake config file needed by `find_package(hermes-engine)` in ReactAndroid's native build. Adding `prefabPublishing = true` back restores the CMake config generation and proper Gradle task ordering. The same PR also disables all hermes tasks when not building from source - which will make the CI work correctly - ie. not build hermes from source when not needed. ## Changelog: [ANDROID] [FIXED] - Re-added prefabPublishing=true to make Android build from source work again Pull Request resolved: react#55310 Test Plan: - Build RN Tester and build from source, verify that Android builds correctly. - Check CI and verify that Hermes is not built from source Reviewed By: cipolleschi Differential Revision: D91581389 Pulled By: cortinico fbshipit-source-id: 01953cc071d22faa84920ebe30cc1426c8d420e4
…. (react#55251) Summary: This fixes a regression introduced by b18cd58 by including the final, redirected to URL in the response object. ## Changelog: [ANDROID][FIXED] fetch() response URL is incorrect after redirect (react#55248) Pull Request resolved: react#55251 Test Plan: Testing using the reproducer from issue react#55248. Reviewed By: cortinico Differential Revision: D91046809 Pulled By: javache fbshipit-source-id: 314419304f18325e6273ae9ed6a828d32abd68ac
…uild types (react#55312) Summary: The HERMES_V1_ENABLED compile option was incorrectly scoped inside the else() block, meaning it only applied to Release builds. This caused Debug builds to fail with missing header errors: fatal error: 'hermes/inspector/RuntimeAdapter.h' file not found This happens when Expo builds Hermes in release mode but WITH the debugger enabled. Moved the HERMES_V1_ENABLED compile definition into the centralized target_compile_reactnative_options function in react-native-flags.cmake, eliminating duplicate conditional blocks across 7 CMakeLists.txt files. This ensures the define is consistently applied to all targets that use target_compile_reactnative_options when HERMES_V1_ENABLED is set, and makes the codebase easier to maintain. Files cleaned up: - ReactCommon/cmake-utils/react-native-flags.cmake (added centralized logic) - ReactCommon/hermes/inspector-modern/CMakeLists.txt - ReactCommon/hermes/executor/CMakeLists.txt - ReactCommon/react/runtime/CMakeLists.txt - ReactCommon/react/runtime/hermes/CMakeLists.txt - ReactAndroid/.../hermes/reactexecutor/CMakeLists.txt - ReactAndroid/.../runtime/hermes/jni/CMakeLists.txt - ReactAndroid/.../runtime/jni/CMakeLists.txt ## Changelog: [ANDROID] [FIXED] - Fixed so that all build types get the HERMES_V1_ENABLED flag Pull Request resolved: react#55312 Test Plan: Build RN Tester with HERMES_V1 Reviewed By: cipolleschi Differential Revision: D91581367 Pulled By: cortinico fbshipit-source-id: fa39158009dadda32438bc04a59579459da2cf7d
#publish-packages-to-npm&next
#publish-packages-to-npm&next
#publish-packages-to-npm&latest
Summary: Changing the line in `ReactPlugin.kt` that always set `hermesV1Enabled` to `true` even if it was explicitly disabled, accidentally omitted in react#54989. In recent update of hermes V1 binary a file `RuntimeAdapter.h` was removed. ## Changelog: [ANDROID] [FIXED] - ReactPlugin.kt always setting `hermesV1Enabled` to `true` Pull Request resolved: react#55399 Test Plan: Build React Native from source on latest 0.84 RC, disable hermesV1 and see that it compiles now. Reviewed By: cipolleschi Differential Revision: D92267385 Pulled By: cortinico fbshipit-source-id: 58ecae6d3064995ef9e63ddbd67ac04db2a1126b
…t#55400) Summary: Since HermesV1 is enabled by default in React Native 0.84, the prebuilt Android artifacts are compiled with the flag `HERMES_V1_ENABLED`. This results in dropping some inspector symbols, in my case `enableDebugging` and `disableDebugging` from `inspector-modern/chrome/Registration.cpp`. This is problematic, because even if the app sets `hermesV1Enabled=false` in `gradle.properties`, it's shipped with binaries compiled with `hermesV1Enabled=true`. This makes it so I'm expecting symbols that should be available when `HERMES_V1_ENABLED` macro isn't defined - but they aren't available. I don't know what other symbols could lead to compilation failures, maybe shipping a whole other binary would be a better idea. For the time being I made a simple fix that would provide fallback implementations instead of not generating them at all. ## Changelog: [ANDROID] [FIXED] - Provide symbol fallbacks for `inspector-modern/chrome/Registration.h` when HermesV1 is disabled. Pull Request resolved: react#55400 Test Plan: I tested these changes (although in `Registration.h` file) in a project, not building from source, and they worked. Reviewed By: cipolleschi Differential Revision: D92964824 Pulled By: cortinico fbshipit-source-id: a87ceab6d25095062de200d1a08821dba379240d
…nt build in monorepos (react#55569) Summary: _Disclaimer: The code was generated using GPT-5.3 Codex. I have read it, and it looks fine, but I'm no android expert. I made sure with logging that everything worked._ React Native’s included build was reading only ../../android/gradle.properties, which breaks in monorepos where Android apps live under packages/*/android. This updates settings.gradle.kts to resolve gradle.properties from the parent Gradle start parameters (projectDir/currentDir) first, with the old relative path kept as a backward-compatible fallback. This ensures hermesV1Enabled and react.hermesV1Enabled are propagated reliably across composite builds. ## Changelog: [ANDROID] [FIXED] Fix included-build `gradle.properties` resolution for monorepos by reading from parent Gradle start parameters (`projectDir`/`currentDir`) before falling back to `../../android/gradle.properties`, so `hermesV1Enabled` can be inherited correctly. Pull Request resolved: react#55569 Test Plan: I've tested manually with expo sdk 55 in our monorepo. Ideally we'll want this in 83, so that expo 55 can use hermes V1 in monorepos Reviewed By: cipolleschi Differential Revision: D93478206 Pulled By: cortinico fbshipit-source-id: ebb8b4dd555b86b6cba57d9b197557a6aab1887f
…" failure (react#55486) Summary: Pull Request resolved: react#55486 The Modal integration test `<Modal> › ref › instance › uses the "RN:ModalHostView" tag name` was flaky on CI, intermittently failing with "MessageQueue is not empty" during the global afterEach `validateEmptyMessageQueue` hook. The root cause is that when Modal renders in __DEV__ mode, AppContainer's `useEffect` schedules passive effects as a deferred task on the RuntimeScheduler. Due to how microtask scheduling interacts with the RuntimeScheduler drain loop in Hermes, `flushMessageQueue()` inside `runTask` occasionally returns before this task is fully processed, leaving it on the queue for `validateEmptyMessageQueue` to find. The fix adds an `afterEach` hook at the top-level `describe('<Modal>')` block that calls `Fantom.runWorkLoop()`. This provides a second drain pass before the global `validateEmptyMessageQueue` check runs (inner afterEach hooks execute before outer ones). The call is a no-op when the queue is already empty, so it adds no overhead to tests where the initial drain was complete. This is consistent with patterns in Fantom-itest.js where Modal tests that call additional `runWorkLoop()` (for `enqueueModalSizeUpdate`) never exhibit this flakiness, precisely because that second drain catches any residual passive effects work. Changelog: [Internal] [Changed] - Reviewed By: rubennorte Differential Revision: D92828076 fbshipit-source-id: 529abe962044e2da6bee3b1e2ef4b129392fae06
Summary: Pull Request resolved: react#55712 changelog: [Internal] The Modal tests are flaky because message queue is sometimes not empty, leading to error: "MessageQueue is not empty". The fix adds beforeEach/afterEach hooks to create a fresh root for each test and properly destroy it afterwards. The root.destroy() call flushes the message queue, ensuring cleanup happens before the next test. I am not 100% sure why this happens, especially in multithreading environment. But this makes the situation less bad and tests less flaky. It does not address the root cause. Reviewed By: cipolleschi Differential Revision: D92171933 fbshipit-source-id: 0b931771475c9b65fe287ab06d1652d7d5d7efab
#publish-packages-to-npm&latest
…t-native (react#57167) Backport of react#57167 to 0.84-stable. Update GitHub Actions workflow fork-prevention guards (github.repository == ...) and the monitor-new-issues repo_owner parameter to reflect React Native's migration from facebook/react-native to react/react-native. This is the equivalent of upstream commit 861d8e0; applied manually because the workflow files have diverged on this branch and a direct cherry-pick conflicts.
Backport of react#57216 to 0.84-stable. Move CI jobs off the timing-out 4-core-ubuntu / 8-core-ubuntu runners to ubuntu-latest across the Android, fantom, build and publish workflows. macOS runners are unchanged. This is the equivalent of upstream commit 097dbc2; applied manually because the workflow files have diverged on this branch and a direct cherry-pick conflicts.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Saadnajmi
changed the title
Collaborator
Author
|
🤖 Copilot: Closing this replacement PR because JJ will remain the topology and evolution tool. Continue review on #3031. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
18 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Supersedes
Replaces #3031 with the locally recreated DAG node.
886c5369ab6fe11eaa5016f58cbcd6379efc55b39887755a45df65099385beb276d31cb4cdcc4d2f7e606c19b50ba00a22d37c188eb20d6d4766cbf28f85e0e93b7f3521a70f2bf7e8da55eadadce6cbsaadnajmi/dag/0.84-mergeRecreation evidence
The ordered-parent DAG, conflict provenance, consumer-liveness checks, tree-delta confinement, validation logs, and verified bundle are archived in the Phase 1 evidence package. Published as a draft replacement for review.