chore: merge React Native 0.87 fork point#3037
Draft
Saadnajmi wants to merge 549 commits into
Draft
Conversation
…renderer/animated/drivers/DecayAnimationDriver.cpp (react#57104) Summary: Pull Request resolved: react#57104 Reviewed By: javache Differential Revision: D107634657 fbshipit-source-id: 4f5afc57f461a9ab53c1e0c0d6565304bd6b71af
Summary: This PR is part of Android Gradle Plugin v9 adoption. With this PR, we adopt the AGP9 repository wide and address the deprecated APIs with the newer ones. This is in combination with react#57038 <details> <summary> <b>Changes to `configureBuildConfigFieldsForLibraries` and `configureNamespaceForLibraries`</b> </summary> <br/> These helpers are called from `ReactPlugin.apply`, but they currently iterate over `rootProject.allprojects`. Since `com.facebook.react` is applied by multiple Android library projects, each application of the plugin repeats the same traversal and attempts to register `finalizeDsl` callbacks for every Android library project. The first traversal can register the callbacks successfully. However, a later traversal can reach a project whose Android DSL finalization phase has already completed. Starting with AGP 9, AGP explicitly errors when `finalizeDsl` is called after that phase has passed, which causes the build failure. [see](https://issuetracker.google.com/issues/436595826) To understand this, consider following modules: ``` :react-native-safe-area-context :react-native-mmkv :react-native-skia ``` The current code on main, would result in executing the following block 3 times: ```kt fun configureBuildConfigFieldsForLibraries(appProject: Project) { appProject.rootProject.allprojects { subproject -> println("=== subproject ${subproject.name}") subproject.pluginManager.withPlugin("com.android.library") { subproject.extensions .getByType(LibraryAndroidComponentsExtension::class.java) .finalizeDsl { ext -> ext.buildFeatures.buildConfig = true } } } } ``` The output would be: ``` > Configure project: react-native-safe-area-context === subproject RNProject === subproject app === subproject react-native-safe-area-context === subproject react-native-mmkv === subproject react-native-skia > Configure project: react-native-mmkv === subproject RNProject === subproject app === subproject react-native-safe-area-context === subproject react-native-mmkv === subproject react-native-skia > Configure project: react-native-skia === subproject RNProject === subproject app === subproject react-native-safe-area-context === subproject react-native-mmkv === subproject react-native-skia ``` Now with AGP9, the same code will throw this error: ``` > Configure project: react-native-safe-area-context === subproject RNProject === subproject app === subproject react-native-safe-area-context === subproject react-native-mmkv === subproject react-native-skia > Configure project: react-native-mmkv === subproject RNProject === subproject app === subproject react-native-safe-area-context === subproject react-native-mmkv * What went wrong: A problem occurred evaluating project': react-native-mmkv'. > Failed to apply plugin 'com. facebook. react' > It is too late to call finalizeDst as the DSL finalization blocks have already been executed. \n In particular, you cannot call 'finalizeDsl' within the "beforeVariants' or "onVariants' blocks. Instead, you must call finalizeDsl' directly within the "androidComponents' block ``` **Solution:** Since these helpers are only intended to configure Android library projects that apply the React plugin, we can configure the current project inside `pluginManager.withPlugin("com.android.library")` instead of repeatedly configuring all projects from every plugin application. ```kt fun configureBuildConfigFieldsForLibraries(project: Project) { project.extensions .getByType(LibraryAndroidComponentsExtension::class.java) .finalizeDsl { ext -> ext.buildFeatures.buildConfig = true } } ``` ```kt fun configureNamespaceForLibraries(project: Project) { project.extensions .getByType(LibraryAndroidComponentsExtension::class.java) .finalizeDsl { ext -> if (ext.namespace == null) { val manifestFile = project.layout.projectDirectory.file("src/main/AndroidManifest.xml").asFile manifestFile .takeIf { it.exists() } ?.let { file -> getPackageNameFromManifest(file)?.let { packageName -> ext.namespace = packageName } } } } } ``` One important note for `configureNamespaceForLibraries` is that the old `com.android.build.gradle.LibraryExtension` is deprecated in favor of `com.android.build.api.dsl.LibraryExtension` - which does not expose `manifestFile` from the `sourceSets`. So we have to define a path for it. For most libraries, this should be OK but for the ones which define custom path, this will fail. Hence, I believe, if it's important to have this fallback, we take this tradeoff. Otherwise, since there has been 2 years passed for AGP8 adoption and the time when this fallback was added, we may safely remove this function as almost all libraries now define a `namespace` in `android { }` DSL. With the above in place, we make one final change and that is to move these two functions inside the `withPlugin("com.android.library")` as these are only intended for libraries and that way, we also ensure that these will only be applied once the `com.android.library` plugin has been applied. ```kt project.pluginManager.withPlugin("com.android.library") { configureBuildConfigFieldsForLibraries(project) configureNamespaceForLibraries(project) configureCodegen(project, extension, rootExtension, isLibrary = true) } ``` </details> ## 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] [BREAKING] - Adopt AGP v9 Pull Request resolved: react#57038 Test Plan: - CI passes - Verified on RN Tester - Verified on Local RN App https://github.com/user-attachments/assets/b424c211-6876-42b0-a5d1-f9ecade39a3a Reviewed By: cipolleschi Differential Revision: D107656378 Pulled By: cortinico fbshipit-source-id: 38fd7191e089ce29ccb84fa25bff6d9e920cf322
Summary: Pull Request resolved: react#57093 This is only pulled in by a few targets. Changelog: [Internal] Reviewed By: christophpurrer Differential Revision: D107651646 fbshipit-source-id: fa9a441dabf50e36ca7549cfc09591ebae67b75c
…57107) Summary: This fixes the failing CI jobs on main for `template` testing. The job fails as they echo `react.internal.mavenLocalRepo=...` to the `gradle.properties` of template test project. As a result of which the `gradle.properties` look like below: ```properties android.builtInKotlin=false android.newDsl=falsereact.internal.mavenLocalRepo=... ``` To fix it we add a line break in the `echo` command. ## 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] [FIXED] - add line break to gradle.properties for template testing Pull Request resolved: react#57107 Test Plan: - CI Passing - Verified Locally Reviewed By: cortinico Differential Revision: D107880136 Pulled By: cipolleschi fbshipit-source-id: 81cf2fe53c1c2285f79db538aa5aa3cb745f796d
…eact#57103) Summary: Pull Request resolved: react#57103 Changelog: [General][Fixed] Fixed `display: contents` nodes having `hasNewLayout` set incorrectly `cleanupContentsNodesRecursively` unconditionally sets `hasNewLayout=true` on `display: contents` children, including on code paths where their parent's layout was not actually performed in this pass. The stale flag can survive across layout passes and, in clone-on-write renderers (e.g. React Native Fabric), be observed by a subsequent pass whose parent was cloned but whose layout was served from cache, leaving the contents child's owner pointing at the previous parent revision. There are two paths through which the cleanup could stamp a contents child whose parent's `hasNewLayout` would end up false: 1. Measure-phase visit. Inside `calculateLayoutImpl`, the cleanup ran with no knowledge of `performLayout`. When the parent's `calculateLayoutImpl` was invoked only with `performLayout=false` (cache miss on measure, cache hit on layout), the cleanup stamped contents children even though the parent itself never had its `hasNewLayout` set. 2. Absolute-layout walk. `layoutAbsoluteDescendants` walks every static layout descendant of the containing block - including ones whose own `calculateLayoutImpl` was skipped via the layout-phase cache. The cleanup invoked along that walk unconditionally stamped contents children, but the parent's `hasNewLayout` was only updated when the recursion actually found new layout downstream. In both cases, the result is the same invariant violation: a contents node with `hasNewLayout=true` whose parent has `hasNewLayout=false`. A consumer iterating the tree via `hasNewLayout` skips the parent and never clears the stale flag. X-link: react/yoga#1970 Test Plan: Added `YGContentsNodeHasNewLayoutTest.cpp` with regression tests: - `contents_child_hasNewLayout_not_stamped_on_measure_only_visit` - pins the measure-phase fix - `absolute_descendant_through_contents_is_reachable_via_hasNewLayout` - pins the positive case for absolute-layout path - `absolute_phase_cleanup_does_not_stamp_when_parent_layout_skipped` - pins the negative case for absolute-layout path Reviewed By: javache Differential Revision: D107854528 Pulled By: j-piasecki fbshipit-source-id: cae5e889622296e8b6380a6428509b5ffea3e9ae
Summary: Add missing \n on helloworld gradle.properties ## Changelog: [INTERNAL] - Pull Request resolved: react#57113 Test Plan: CI Reviewed By: fkgozali, Abbondanzo Differential Revision: D107894162 Pulled By: cortinico fbshipit-source-id: 71d5ca5a4bde9ae550a6f17bb65a7cfad56d4f4c
Summary: Pull Request resolved: react#57111 D104680895 replaced the native Android `UnderlineSpan`/`StrikethroughSpan` with custom `CanvasEffectSpan` canvas drawing to support `textDecorationStyle`. The custom drawing enforces a minimum stroke thickness of `1.5f * density` (1.5dp), which is noticeably thicker than what the native framework spans produce. This diff removes the 1.5dp minimum for SOLID style so the decoration thickness matches the native `Paint.getUnderlineThickness()` value, restoring the pre-D104680895 visual behavior. The minimum is kept for all other styles (DOUBLE, DOTTED, DASHED, WAVY) since they need the thickness for their visual patterns to render correctly (dash intervals, dot sizes, bezier wavelength). **Remaining work:** the underline position (`baseline + thickness + 1f` in `ReactUnderlineSpan.kt`) also depends on thickness, so with a thinner SOLID stroke the underline sits closer to the text than before D104680895. The pre-D104680895 behavior used the native framework `UnderlineSpan` which positions the underline via `Paint.getUnderlinePosition()`. Attempted using `baseline + paint.underlinePosition + thickness / 2f` and `+ thickness` on API 29+ but neither matched the native positioning exactly. This needs further investigation to match the original vertical gap between text and underline. Changelog: [Android] [Fixed] - Fix text decoration line thickness regression on Android Reviewed By: javache Differential Revision: D107866867 fbshipit-source-id: 72635418181a2f4332cd4c06136a3104ca4609ba
…ct#57112) Summary: Pull Request resolved: react#57112 `UIManagerModule` was recently converted from Java to Kotlin. The nested `CustomEventNamesResolver` interface has a single abstract method, but was declared as a regular `interface` rather than `fun interface`. In Java, single-method interfaces support SAM (Single Abstract Method) conversion in Kotlin callers. After the Kotlin conversion, SAM conversion no longer works unless the interface is declared as `fun interface`. This breaks downstream libraries like `react-native-reanimated` that use lambda syntax to instantiate `CustomEventNamesResolver`: ``` UIManagerModule.CustomEventNamesResolver { eventName -> ... } ``` Adding `fun` restores SAM conversion support. This is backward compatible — existing `object : CustomEventNamesResolver { ... }` code continues to work. Reviewed By: cipolleschi Differential Revision: D107891295 fbshipit-source-id: da3f76aad4716a9646fd3841df3e13f610642453
Summary: Pull Request resolved: react#57109 changelog: [internal] The RAM bundle format stores offsets and lengths in little-endian, which previously required pulling in folly's byte-swapping library. This removes the folly dependency by implementing a simple little-endian decoder inline, cutting the build graph and making the code more self-contained. Reviewed By: javache Differential Revision: D107870286 fbshipit-source-id: c6f8399785189fad743123ecc51434c0feff9706
react#57099) Summary: Pull Request resolved: react#57099 Replaces the long-lived `GHA_NPM_TOKEN` automation token with npm Trusted Publishing (OIDC) for every `npm publish` invoked from this repo's GitHub Actions. Why a reusable workflow: npmjs.com Trusted Publishing accepts only ONE (org, repo, workflow_filename, environment) tuple per package. Today, packages are published from multiple workflow files: - `react-native` from publish-release.yml + nightly.yml - every `react-native/*` from nightly.yml + publish-bumped-packages.yml A naive per-workflow OIDC migration would require two Trusted Publisher entries per package, which npm doesn't support. Instead, this diff funnels every `npm publish` through one new file — `.github/workflows/publish-npm.yml` — invoked via `workflow_call` from the existing top-level workflows. The OIDC `job_workflow_ref` claim therefore always resolves to `publish-npm.yml`, so each package needs exactly one Trusted Publisher entry pointing here. What changes: * New `.github/workflows/publish-npm.yml`: reusable workflow with a `mode` input. `mode: react-native` runs the full Android + iOS prebuilt + JS build path (used by release & nightly, publishes `react-native` and — in nightly mode — every `react-native/*` package via `scripts/releases-ci/publish-npm.js`). `mode: monorepo-packages` runs only the JS build and publishes the delta-bumped packages via `scripts/releases-ci/publish-updated-packages.js` (used by publish-bumped-packages.yml). Both jobs grant `id-token: write` so the npm CLI can mint the OIDC token for Trusted Publishing. * `.github/workflows/publish-release.yml`: replace the `build_npm_package` job's inline build/publish steps with a `uses: ./.github/workflows/publish-npm.yml` call. The template-publish, rn-diff-purge, npm-verify, and Maven-verify steps move into a new `post_publish` follow-up job that `needs: [build_npm_package]`. Drops `GHA_NPM_TOKEN` from the env. * `.github/workflows/nightly.yml`: same — `build_npm_package` now delegates to the reusable workflow. Drops `GHA_NPM_TOKEN` and the obsolete `Verify NPM token` precheck (Trusted Publishing has no pre-mintable token to validate; failures surface at `npm publish` time). * `.github/workflows/publish-bumped-packages.yml`: shrinks to a thin trigger wrapper that calls the reusable workflow with `mode: monorepo-packages`. * `.github/workflows/create-release.yml`: drop the obsolete `Verify NPM token` step. * `.github/actions/build-npm-package`: drop the `gha-npm-token` input and the `Set npm credentials` step that wrote `_authToken`. Pass `registry-url: https://registry.npmjs.org` to setup-node so `actions/setup-node@v6` writes a `.npmrc` configured to consume the OIDC token at publish time. * `.github/actions/setup-node`: thread a new `registry-url` input through to `actions/setup-node@v6`. The publish scripts themselves (`scripts/releases-ci/publish-npm.js`, `scripts/releases-ci/publish-updated-packages.js`, `scripts/releases/utils/npm-utils.js`) are unchanged: they shell out to plain `npm publish`, which performs the OIDC exchange transparently when it sees a GitHub Actions OIDC environment and a Trusted Publisher configured for the package on npmjs.com. Note: this diff only changes the workflow definitions. Each package on npmjs.com must additionally be configured with a Trusted Publisher pointing at: - org: facebook - repo: react-native - workflow filename: publish-npm.yml - environment: npm-publish The npm CLI's OIDC exchange returns 404 until that registry-side config is in place. Trusted Publisher entries are additive on npmjs.com (don't enable "Require Trusted Publishing" yet) so the existing token-based flow keeps working through the cutover. See the stack landing notes for the full package list and UI steps. Backport: this also needs picking back to `*-stable` branches before "Require Trusted Publishing" is enabled on any package, since GitHub Actions runs the workflow file from the ref that triggers it. Changelog: [Internal] Reviewed By: cortinico, cipolleschi Differential Revision: D107805971 fbshipit-source-id: 7a360dff9666c4b0952504331d26c0af74148789
Summary: This makes the shell to use escape interpretation by setting `echo -e "..."`. For zsh shell, this often works out of the box. For other shells like bash, we may need to set it explicitly. ## 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] [FIXED] - allow escape interpretation for shells Pull Request resolved: react#57114 Test Plan: - CI Passes - Verified Locally on template app https://github.com/user-attachments/assets/4c8c6bf7-1cf2-4bd8-b094-651c44578ae0 Reviewed By: cipolleschi Differential Revision: D107904889 Pulled By: cortinico fbshipit-source-id: 2222f589ecc149a82d5067e0a2198b9c1a17ffcb
…eact#57130) Summary: Pull Request resolved: react#57130 The 0.86 release notes were split across four release-candidate sections (rc.0 through rc.3). Merge them into one v0.86.0 section without changing any entry text: - Combine all four RC sections under a single v0.86.0 heading - Organize entries under the standard Added / Changed / Deprecated / Fixed / Security categories, each with general / Android specific / iOS specific subsections - Sort entries within every subsection by their bold prefix - No entries were added, removed, or reworded (124 entries preserved) Changelog: [Internal] Reviewed By: cipolleschi Differential Revision: D107887110 fbshipit-source-id: c63f6fc7310eac0a58cc04ec25347093717b2175
Summary: fixes react/yoga#1659. **problem:** `YGNodeFree` called `owner->removeChild(node)` to detach the node from its parent, but never called `owner->markDirtyAndPropagate()`. the parent's layout stayed stale after the free, so a subsequent `YGNodeCalculateLayout` wouldn't recompute it. `YGNodeRemoveChild` has always called `markDirtyAndPropagate` — `YGNodeFree` was just missing the same call. `YGNodeFreeRecursive` was already correct for its recursive child removals (it calls `YGNodeRemoveChild` internally), but the terminal `YGNodeFree(root)` inherited the bug. **fix:** added `owner->markDirtyAndPropagate()` after `node->setOwner(nullptr)` in `YGNodeFree`. regression tests: `dirty_parent_when_child_freed` and `dirty_parent_when_subtree_freed_recursive` in `YGDirtyMarkingTest.cpp`. bypass-github-export-checks ## Changelog [General][Changed] - mark parent dirty when child is freed X-link: react/yoga#1969 Reviewed By: javache Differential Revision: D107895988 Pulled By: cipolleschi fbshipit-source-id: 5dce726e13147e8b7735bf72c441e80bb0c9b5a3
…ct#57116) Summary: Pull Request resolved: react#57116 ## Changelog: [General][Breaking] Compile out RuntimeScheduler_Legacy under RCT_REMOVE_LEGACY_ARCH Guard the legacy RuntimeScheduler implementation behind the `RCT_REMOVE_LEGACY_ARCH` macro instead of deleting it. `RuntimeScheduler_Legacy.h`/`.cpp` remain in the tree, but their contents — along with the feature-flag-based selection between the legacy and modern schedulers in `RuntimeScheduler.cpp`, `NativeMutationObserver.cpp`, and `Task.h` — are wrapped in `#ifndef RCT_REMOVE_LEGACY_ARCH`. When the macro is defined, the legacy code is compiled out and `RuntimeScheduler` unconditionally instantiates `RuntimeScheduler_Modern`; when it is not defined, behavior is unchanged. The C++ API snapshots are updated to drop the `RuntimeScheduler_Legacy` symbols from the new-arch surface, and the parameterized scheduler test (`RuntimeSchedulerTest`) only runs the modern configuration when the legacy arch is compiled out. Reviewed By: rubennorte Differential Revision: D107777881 fbshipit-source-id: 2b50711ab3af182edc45a87fd232d96a0f879837
Summary: `textDecorationStyle` is declared on `TextStyleIOS` in the public types but `wavy` is silently dropped: Fabric's C++ enum doesn't include `Wavy`, and UIKit's `NSUnderlineStyle` has no native wavy pattern bit. Separately, `dotted` and `dashed` map to `NSUnderlineStylePatternDot` / `NSUnderlineStylePatternDash` which don't match browser geometry on iOS. This PR adds `TextDecorationStyle::Wavy` to the shared Fabric primitives / conversions (also unblocks the same value on Android, see companion PR react#56768) and renders wavy / dotted / dashed decorations with custom Core Graphics paths. **Implementation:** - Wavy ranges are tagged with a custom `RCTCustomDecorationAttributeName` (storing the line kinds, stroke color, and style key) in `RCTAttributedTextUtils.mm` and painted by `RCTTextLayoutManager.mm` after `drawGlyphsForGlyphRange:`. Wavy uses an adaptation of WebKit's formula from `Source/WebCore/style/InlineTextBoxStyle.cpp` (`controlPointDistance = thickness * 1.5 + 0.5`, one cubic Bezier per wavelength, control points at the midpoint above and below the y-axis). At iOS point sizes the literal Blink amplitude renders as a very pronounced wave because Core Graphics paints in points (not device pixels), so the constants are dialed back to read as a clear-but-subtle browser-style wave at typical text sizes. - Dotted uses a custom CG path with a zero-length dash + round line caps, producing actual circular dots at `2 * thickness` spacing. - Dashed uses a custom CG path with `[2 * thickness, thickness]` intervals — short rectangular dashes with a tight gap, closer to Safari's geometry than UIKit's default. - Solid and double continue to use UIKit's native `NSUnderlineStyle` pattern bits, so this PR does not touch the long-standing iOS Arial+bold solid-underline rendering bug tracked in react#53935. - The wavy drawing loop iterates `while x < x2` so the final cycle continues through the last character (including trailing punctuation that would otherwise be visually uncovered when the run width is not an integer multiple of the wavelength). Companion PRs (independent, also targeting `main`): - react#56767 — fix(android): textDecorationColor on underlines + strikethroughs. Resolves react#4579 (2015). - react#56768 — feat(android): textDecorationStyle solid/double/dotted/dashed/wavy. Shares the `TextDecorationStyle::Wavy` enum addition; whichever lands first leaves the other with a trivial conflict to resolve. ## Changelog: [IOS] [ADDED] - `textDecorationStyle: 'wavy'` for `<Text>` (custom CoreGraphics path) [IOS] [CHANGED] - `textDecorationStyle: 'dotted'` and `'dashed'` for `<Text>` render with custom CoreGraphics paths instead of UIKit pattern bits, matching browser geometry more closely Pull Request resolved: react#56769 Test Plan: See the screenshot comparisons here: https://www.internalfb.com/compare-screenshots-from-diff/D104680636 {F1990979243} ---- Side-by-side comparison on iPhone 17 sim (iOS 26.4) of a `<Text>` with `textDecorationLine="underline"` and `textDecorationStyle` cycling through `solid` / `double` / `dotted` / `dashed` / `wavy`, verified against Safari rendering of the same CSS. Trailing periods now fall under the wavy stroke. Verified with `textDecorationColor` set distinct from the foreground color. ```tsx <Text style={{ color: 'black', textDecorationLine: 'underline', textDecorationStyle: 'wavy', textDecorationColor: '#ff00aa', }}> Hello </Text> ``` Reviewed By: cipolleschi Differential Revision: D104680636 Pulled By: cortinico fbshipit-source-id: ac96e5b36530f7d243a4b85a67c576b62fe99866
Summary: Adds a temporary debug step to both jobs of the reusable npm publish workflow that requests the GitHub Actions OIDC token (npm audience) and prints its decoded claims. This makes it possible to compare the token claims against the npm Trusted Publisher configuration when the OIDC exchange fails. Only the decoded claims are printed, never the raw token. Changelog: [Internal] bypass-github-export-checks Reviewed By: cortinico, cipolleschi Differential Revision: D108108630 fbshipit-source-id: 6ae8be8c9e9e2e611b6941b336230a21f876e134
Summary: iOS I18nManager.isRTL is not wrong but often misinterpreted. This PR adds a comment to clarify what the native call does, since Apple doesn't. Undocumented behavior made me waste several hours hunting for an i18n issue that incorrectly made me think RN had a bug. It's impossible to know this code is working as intended as original commit does not state why the code exist, only that it was changed, no mentions in changelogs, and no official docs from neither RN nor from Apple explains the combined or individual behavior. ## 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] [Added] - Added comment to clarify why i18nManager.isRTL may not return the expected value Pull Request resolved: react#51661 Test Plan: This project demonstrates that compiling and running will give you the "wrong"/unexpected isRTL value when using Hebrew https://github.com/scarlac/rtl-test When Hebrew is added to the Xcode project under "Internationalization" then you will observe that `.isRTL` starts returning `true`. Note that Xcode has a nasty caching bug that means that removing Hebrew: 1. Will Not remove Hebrew (you need to remove it twice) 2. Will Not cause `.isRTL` to revert behavior The solution is to remove Hebrew 2x, and then to clear DerivedData (or Product -> Clean Build Folder..., or CMD+Shift+K) In addition to these issues, it's important to note that calling .forceRTL or .allowRTL are persisted across restarts. This is clearly intentional but also not clearly documented, so you cannot "clear" these states. A reinstall is necessary, or a counter-value call is necessary. The demo project does not use these calls, so it's not an issue there. Reviewed By: javache Differential Revision: D108129627 Pulled By: cortinico fbshipit-source-id: 34f5b5509f48c0f102d4234f0315c5f58e30e773
…erface (react#57159) Summary: The hand-written TypeScript types declare only **12 of the 20** pointer event handlers that `ViewProps` actually exposes (per the Flow source and the generated `react-native-strict-api` types). The `PointerEvents` interface in `Libraries/Types/CoreEventTypes.d.ts` is missing: - `onPointerOver` / `onPointerOverCapture` - `onPointerOut` / `onPointerOutCapture` - `onGotPointerCapture` / `onGotPointerCaptureCapture` - `onLostPointerCapture` / `onLostPointerCaptureCapture` These are part of the W3C Pointer Events API. They are declared in the Flow source — `Libraries/Components/View/ViewPropTypes.js` (all typed `(e: PointerEvent) => void`) — and in the generated `react-native-strict-api` types, but were missing from the hand-written TypeScript types, so TypeScript users get a type error using them on any built-in component: ``` Property 'onPointerOver' does not exist on type '... ViewProps'. Did you mean 'onPointerMove'? ``` This adds the 8 missing handlers to the `PointerEvents` interface (matching the existing 12) and a type test covering them. ## Changelog: [GENERAL] [FIXED] - Add missing pointer event handler types (`onPointerOver`, `onPointerOut`, `onGotPointerCapture`, `onLostPointerCapture`, and their `*Capture` variants) to the TypeScript types Pull Request resolved: react#57159 Test Plan: `yarn test-typescript` passes. Verified before/after with `tsc -p packages/react-native/types/tsconfig.json`: - **Before** (props absent): the added type test fails with `Property 'onPointerOver' does not exist on type '... ViewProps'`. - **After**: passes — `<View onPointerOver={e => e.nativeEvent.pointerId} … />` type-checks for all 8 handlers, with the event correctly inferred as `PointerEvent`. Reviewed By: huntie Differential Revision: D108114655 Pulled By: fabriziocucci fbshipit-source-id: 08d364d2e156953027c0d951ab3d895a1eeab159
Summary: X-link: react#57133 `JSIndexedRAMBundle` was a deprecated legacy-architecture class (annotated `[[deprecated("This API will be removed along with the legacy architecture.")]]` and guarded by `#ifndef RCT_REMOVE_LEGACY_ARCH`) for parsing indexed RAM bundles. It was only ever instantiated by `Instance::loadRAMBundleFromString` and `Instance::loadRAMBundleFromFile`, and those two `Instance` methods have no callers anywhere in fbsource: the old Android entry point `CatalystInstanceImpl` that used to call them has been deleted, and the new architecture (`ReactInstance` / bridgeless) routes `loadScriptFromFile` through `loadJSBundleFromFile` in the new runtime, never touching the legacy `Instance`. The only remaining user was its own unit test. This removes `JSIndexedRAMBundle` and the two dead `Instance` RAM-bundle loaders that referenced it: - Delete `JSIndexedRAMBundle.cpp`, `JSIndexedRAMBundle.h`, and `JSIndexedRAMBundleTest.cpp`. - Remove `loadRAMBundleFromString` / `loadRAMBundleFromFile` from `Instance.cpp` / `Instance.h` and drop the now-unused include. - Drop `JSIndexedRAMBundle.h` from `CXXREACT_PUBLIC_HEADERS` in `cxxreact/BUCK`. - Update the committed C++ API snapshots accordingly. The broader legacy RAM-bundle machinery (`RAMBundleRegistry`, `JSModulesUnbundle`, `Instance::loadRAMBundle`, `JSIExecutor::setBundleRegistry`) is left in place; it belongs to the same `RCT_REMOVE_LEGACY_ARCH` legacy bridge and can be removed as a follow-up. Changelog: [Internal] Reviewed By: javache, mdvacca Differential Revision: D108001933 fbshipit-source-id: 4b0f12258e8caff1991847a4bb211e94fbecefa8
Summary: X-link: react#57125 Fixes a crash (`java.lang.RuntimeException` via `NoSuchElementException`) in `SkewMatrixHelper.isAffine2DTransformWithSkew` and `buildAffine2DMatrix` when a transform array contains an empty map entry (no keys). Changelog: [Android][Fixed] Fix crash in SkewMatrixHelper Reviewed By: Abbondanzo Differential Revision: D107763077 fbshipit-source-id: d61819e875e2334c6d6b121aba1876ec3153c002
Summary: X-link: react#57134 `telemetryTimePointToSecondsSinceEpoch()` in `ReactCommon/react/utils/Telemetry.h` was a `static inline` helper that converted a `TelemetryTimePoint` to seconds since the UNIX epoch, but it had no callers anywhere. This is a pure dead-code removal. The sibling `clockCast` helper it used is left in place (it remains part of the public API surface). Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D108012910 fbshipit-source-id: 5361ef87aaae3c676b542059c0a9d6475b33de45
Summary: X-link: react#57135 `ClearableSynchronizedPool` (an `internal` Kotlin class in `ReactAndroid/.../common/`) was a variant of androidx `Pools.SynchronizedPool` adding a `clear()` method, but it was never instantiated or referenced anywhere. The live event pools (`OnLayoutEvent`, `PointerEvent`, `TouchEvent`, `ScrollEvent`) use androidx `SynchronizedPool` directly. This removes the orphaned class. Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D108012905 fbshipit-source-id: d5972b4c47d054310c8b7803482fa4e6b7a9928e
Summary: X-link: react#57136 `ReactRootView.simulateAttachForTesting()` was a package-private `VisibleForTesting` helper that set up the attach flags and dispatchers, but no test or production code ever called it. `RootViewTest` exercises `startReactApplication`/`unmountReactApplication` and the sibling `simulateCheckForKeyboardForTesting`, never this method. This removes the orphaned helper. Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D108012908 fbshipit-source-id: ee550f66fae07bfeb75fd59b85d5d812fea7e2c1
Summary: X-link: react#57145 `HostTargetController::installPerfIssuesBinding()` was declared in `jsinspector-modern/HostTarget.h` but had no definition anywhere and no callers. (`HostTargetController` is `final`, so the method is not an override.) A declared-but-never-defined non-virtual member cannot be invoked — any call would be a link error — so this is unreachable dead code. The unrelated, live `HostTarget::installPerfIssuesBinding` (a different class) is left intact. Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D108012907 fbshipit-source-id: 5c7f14a7956f67e3e884a32f95aa2e50fd0f3ea6
Summary: X-link: react#57143 `RAMBundleRegistry::singleBundleRegistry` was a static factory that wrapped the public `RAMBundleRegistry` constructor, but it had no callers anywhere. Objects are constructed via the public constructor directly. This removes the orphaned factory; the sibling `multipleBundlesRegistry`, the constructor, `MAIN_BUNDLE_ID`, `registerBundle`, `getModule`, and `getBundle` are all left intact. Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D108012903 fbshipit-source-id: 5d8f18ebce2bb19abd124dbb7c9eda60baa0f272
Summary: X-link: react#57137 `RAMBundleRegistry::multipleBundlesRegistry` was a static factory wrapping the public `RAMBundleRegistry` constructor (the one taking a main bundle plus a factory callback), but it had no callers anywhere. Registries are constructed via the public constructor directly. With the sibling `singleBundleRegistry` already removed, this deletes the last orphaned static factory; the constructor and the rest of the class remain intact. Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D108012906 fbshipit-source-id: 7bb403ff7660317f0f5b422dca140ac69e048dac
Summary: X-link: react#57142 `StartupLogger::getRunJSBundleEndTime()` was a public getter that returned the `runJSBundleEndTime` member, but it had no callers. `NativePerformance` is the only consumer of `StartupLogger` and reads the start-time getters plus `getAppStartupEndTime`, never this end-time getter. This removes the dead getter. The backing member `runJSBundleEndTime` is kept because `logStartupEvent`/`reset` still write it. Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D108012912 fbshipit-source-id: ac6348b8223fba8695843340e99d7e277bf4f60a
Summary: X-link: react#57140 `StartupLogger::getInitReactRuntimeEndTime()` was a public getter returning the `initReactRuntimeEndTime` member, but it had no callers. `NativePerformance` (the only consumer of `StartupLogger`) never reads it. This removes the dead getter; the backing member `initReactRuntimeEndTime` is kept because `logStartupEvent`/`reset` still write it. Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D108012904 fbshipit-source-id: 56a6710c485a926caf82ecb1cc08e845571b2dd8
Summary: X-link: react#57138 `getWarningHighlightColor` in `LogBox/UI/LogBoxStyle.js` was an exported color helper with no importers. It is a duplicate of the live `getHighlightColor` (identical `rgba(252, 176, 29, ...)` value), which is the one actually used by LogBox UI. This removes the dead duplicate. Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D108012913 fbshipit-source-id: dd22adcf191284eb3c81778f92a8c72be15f9d30
Summary: X-link: react#57139 `RCTJSCSetOptionType` was a file-local `using` alias (`BOOL (*)(const char *)`) in `RCTPerfMonitor.mm` that was never referenced. The concrete `RCTJSCSetOption` function is called directly at its two call sites; no code ever used the function-pointer typedef. This removes the dead alias. Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D108012902 fbshipit-source-id: 2d8b207c6d216356a5b4eef9b71effda47db5744
Summary: Add test for `onabort` prop ## Changelog: [INTERNAL] [ADDED] - Add `AbortSignal::onabort` test Pull Request resolved: react#57431 Test Plan: ```bash yarn fantom abort-api/__tests__/AbortController-itest.js --watch ``` Reviewed By: javache Differential Revision: D110787344 Pulled By: Abbondanzo fbshipit-source-id: 1d9b02faa62d7ddb22fb3fccdf5efb6570b924f4
Summary: Pull Request resolved: react#57453 Metro release notes: https://github.com/react/metro/releases/tag/v0.86.0 Changelog: [General][Changed] Metro to 0.86.0 Reviewed By: huntie Differential Revision: D110789092 fbshipit-source-id: 4b999bf533c3c61b7915a73366ff3ca13257c3dc
…podspec (react#57449) Summary: Pull Request resolved: react#57449 Removes duplicate `React-jserrorhandler` dependency declaration from the React-runtimescheduler.podspec file. The dependency was listed twice (lines 50 and 52), now consolidated to a single entry. Changelog: [Internal] Differential Revision: D110778944 fbshipit-source-id: 9e2e091a24cb0c9289a61d7c758917264c6fdacf
…renderer/attributedstring/ParagraphAttributes.cpp (react#57456) Summary: Pull Request resolved: react#57456 Reviewed By: cortinico Differential Revision: D110867849 fbshipit-source-id: 8dc4e0408480f9b09b5b5c604545c369dc2fc473
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>
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>
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>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The canonical Doxygen 1.16.1 Linux output is byte-stable without the fork-local path-based enum deduplication, and matches the output produced with it. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Regenerate all nine snapshots with the upstream Linux toolchain: Doxygen 1.16.1 and Python 3.12. The outputs are byte-identical across independent runs. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The mechanical merge took the fork Gemfile but retained the upstream lockfile. Regenerate the lock mechanically to restore the microsoft#2928 / 34ca616 ActiveSupport CVE posture and the nkf dependency. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Embed the helper script in the podspec so CocoaPods executes it from the downloaded Hermes source root without serializing the checkout path. This preserves the quoted-script behavior from upstream react#45316 while making local podspec checksums portable. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The prior 4a3daf regeneration used unbundled CocoaPods 1.15.2. Regenerate with the repository-pinned Bundler 2.4.12 and CocoaPods 1.14.2 so local pod checksums, including Hermes, match the canonical toolchain. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Pass the existing BUILD_TYPE value into the host hermesc CMake configure step. Hosted prebuild CI otherwise stops at Hermes CMake configuration because CMAKE_BUILD_TYPE is unset. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Saadnajmi
changed the title
…work Newer Hermes tags remove the legacy inspector header directories while retaining the other packaged API surfaces. Guard the top-level and chrome globs independently in both Apple packaging paths. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
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
20 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.
Summary
Merges the independently certified React Native 0.87 fork point into the React Native macOS 0.86 mainline. This intentionally does not merge
facebook/0.87-stableor its release/version commits.The exact recovery head is
d8c588e4a67cbe9d3cdebb27a8909a93448807cd. Local JavaScript, static, dependency, and canonical C++ gates are green on98e4b51f38; the two subsequent Hermes build-script fixes pass focused shell/static/fixture proofs. Local native compilation is not claimed: Xcode stalled during compiler discovery under extreme host contention, before source compilation, so the draft PR's hosted CI is the authoritative native/RNTester signal.Topology
5cad69e891fd6f5038ea4005338054da4a6eb5badb92dc832747c4ad003d8fe12da35f7dc56880b4(certified 0.86 mainline)ce057d6554b5ed44070336fa2353d7d6624eab92(recomputed fork point)d8c588e4a67cbe9d3cdebb27a8909a93448807cd754e6051819af4b6076a17e663e8d45dabcc5a80fc0be7349d1aeda36f26b26d57d97f6674fd2e08is not reachable.db92dc83 ce057d65.Conflict evidence and definitions
The mechanical merge resolves every authoritative Git conflict; no conflict was deferred.
Ledger byte forms are explicit and corrected:
1a99ed3b4d37860f08a9ed01fed13a0f47bda5038c397b92e8e98a2348c5ed17.RCTUIManager.mmcompile-probe decision changed exactly one row: raw SHA2564b52f101b01917bfdf0edb730f15f2b69c9cb80ba77bc402ae485108572a6c9f.a64f1253d5a292edb2ee5574f978321bb168c6abebc97f1f3dbdce78979f6853.The earlier use of
1a99ed3b...as the final authoritative hash was stale; it identifies only the initial pre-probe form.c58c12aba7b2a85de3a00a706245128dc09264f7mt087SHA256:ceb4a5d05b81468895442a1096d732f051c0b469509dc6caaaad0dfb304a9f05paths087SHA256:2e21aecad99f6615f6d10ecd2b42f0e248540ab5fa33fef4b9f4e357a579700bTerminology:
UUis modified on both sides;UDis modified in parent 1 and deleted in parent 2.<<<<<<<through>>>>>>>; a path may contain multiple blocks.<<<<<<<,|||||||,=======, or>>>>>>>boundary.Git is authoritative. Git/Jujutsu reconciliation was 142 intersection + 1 Git-only + 3 Jujutsu-only = union 146. Membership table SHA256:
ca994e2035869dab987112b9bff4e3938fa8fe313e493512a0d0a3503ac69673.Supplemental semantic obligations outside the authoritative 143:
ErrorUtils.hfalse rename remained parent-2 byte-identical.Major conflict decisions
86350ab988/ Remove legacy architecture code guarded by RCT_REMOVE_LEGACY_ARCH from RN iOS (#56831) react/react-native#56831 removes the deprecated, legacy-architecture-only surface; there were no build references or consumers. The separate core wrapper view controller remains untouched.RCTAppSetupUtils.h/.mmandRCTRootView.mfollow parent 2 exactly.RCTRootView.mSHA256 is89221f710245fc711f8ee6a15b09e657483d46b888c7c81310e094810868fdf9.RCTUIManager.mmkeeps the Fabric-era parent-2 stub plus approved platform type/import substitutions, drops the removed Paper rows/imports, and uses the unguarded scrollable-protocol import after an actual macOS compile probe passed.Reversible layers
5cad69e891mechanical two-parent merge and all conflict decisions1b619e2271CocoaPods regeneration3f10d8ab2eworkspace constraints5d523c0147Flow modernization577fecfbd9merged configuration formattingdb6c417397import ordering52468a13c6TypeScript API regenerationd6673f2df6Jest snapshot regeneration7ad2c6b001C++ API enum deduplication34831bbc15C++ API snapshots2836f70fb2native/Fabric reconciliationcb0c8ee0f1diff-tag correctionsbab0787897SwiftPM linker-setting disambiguationd5c234bc11nested diff-tag pairing42e3682cc5minimal diff-tag formatting4a3daf7687final CocoaPods checksumsbe403fe694recovery: remove noncanonical C++ enum-deduplication generator changea9dca301c5recovery: regenerate canonical C++ API snapshots82a2c7b10frecovery: reconcileGemfile.lockwith the forkGemfile9b0258fa86recovery: embed a checkout-path-independent Hermes prepare command98e4b51f38recovery: regenerate the RNTester lock with bundled CocoaPods 1.14.2211fa7f8dcrecovery: pass the existing build type when configuring host HermesCd8c588e4a6recovery: skip legacy inspector header globs removed from newer Hermes tagsAll 23 first-parent commits are non-empty and contain the Copilot co-author trailer.
Recovery changes and deterministic proofs
Canonical C++ API
be403fe694.a9dca301c5.669aeeef...) through Rosetta.Ruby lock reconciliation
Gemfilebut retained the upstream lock, leaving theactivesupport >= 7.2.3.1/nkfrequirements unresolved.c92be41e2ed6aa6c3367c9de35169b549350cab8; SHA256682886bcb1266bb084c2215ba37b29f56afdcead61623f9950e436dd75a48e7c.Hermes prepare command and CocoaPods
9b0258fa86embeds the helper script contents withFile.read, so CocoaPods executes the command in the downloaded Hermes source root without serializing the checkout path.98e4b51f38regenerates onlypackages/rn-tester/Podfile.lockunder Ruby 3.4.5, Bundler 2.4.12, and CocoaPods 1.14.2.b31af4df03103d006996baed689687ae884dc97d, CocoaPods footer 1.14.2, and an unchanged RNTester project.859b236e74977c23a4fe3ad184cc09e20578cf49; SHA2568cd7b1bcf1b46f6b4b5f39ccbe7c0b896fc44564d2d3a73d6b3c63c8f14782cd.Host HermesC build type
98e4b51f38resolved Hermes successfully but failed host HermesC configuration atCMakeLists.txt:45:Please set CMAKE_BUILD_TYPE.211fa7f8dcpasses the script's existingBUILD_TYPEvalue to the host CMake configure command:-DCMAKE_BUILD_TYPE="$BUILD_TYPE".bash -n,git diff --check, default-value, and exact-command checks. A local Hermes compile was not started because proven host load remained in the hundreds; the current-head hosted rerun is required.Newer Hermes inspector header removal
211fa7f8dcproves the build-type fix: Hermes resolution andBuild hermescpass.cp: API/hermes/inspector/*.h: No such file or directory.d8c588e4a6independently guards only the two removed inspector globs in both packaging paths. The chrome guard is not nested under the top-level guard.set -efixture matrix passes all five states: absent directory, empty directory, top-level only, chrome only, and both. Shell syntax and diff checks pass; unrelated proven-present header globs remain unguarded.Exact-head validation
Full local validation green on parent
98e4b51f38:Focused local validation after
98e4b51f38:211fa7f8dc: one source file and one CMake command;bash -n,git diff --check, existing build-type default, and exact-command checks pass.d8c588e4a6: one source file;bash -n,git diff --check, exact independent guards at both copy sites, five-state fixture matrix, and candidate-tag header-presence checks pass.Cheap current-head integrity checks on exact
d8c588e4a6:754e6051819af4b6076a17e663e8d45dabcc5a80Local native status:
CreateBuildDescriptioncompiler discovery with idle clang probes; direct clang completed successfully, no competing Xcode writer existed, and source compilation never began.Not completed locally on
d8c588e4a6because native validation stopped before compile:React.xcframework/dSYM compositionFirst hosted CI run (
98e4b51f38)The first hosted draft-PR run completed with 13 successful checks, 9 skipped checks, and 3 failures.
Hosted native/RNTester passed:
Other passing checks included workspace constraints, JavaScript tests, npm publish dry run, Hermes resolution, CLA, and GitOps validation.
Failures:
Merge React Native 0.87 fork pointis not conventional-commit formatted. The title remains unchanged per coordinator direction.CMakeLists.txt:45withPlease set CMAKE_BUILD_TYPE. Commit211fa7f8dcdirectly addresses this failure.The Hermes slice jobs, platform prebuild matrix, and Debug XCFramework composition were skipped after the host HermesC failure. The hosted rerun for exact head
211fa7f8dcis authoritative for that fix.Second hosted CI run (
211fa7f8dc)The second hosted run proves the CMake fix:
Build hermescpass.cp: API/hermes/inspector/*.h: No such file or directory.Commit
d8c588e4a6directly addresses the shared slice failure by independently guarding only the removed inspector header globs.Final hosted CI run (
d8c588e4a6)Hosted run
29679047851completed successfully on exact headd8c588e4a67cbe9d3cdebb27a8909a93448807cd:iphoneos,iphonesimulator,macosx,xros, andxrsimulatorslices: passmacos,ios,ios-simulator,visionos, andvisionos-simulator: passThe run produced 19 hosted artifacts, including five Hermes slices, assembled Hermes artifacts, five platform slices/headers,
ReactCoreDebug.xcframework.tar.gz, andReactCoreDebug.framework.dSYM.tar.gz.Skipped in this hosted run:
Test react-native-test-app integrationTest react-native-macos initCheck for ChangesetsBuild the websiteThe separate
Validate C++ API Snapshotsworkflow was skipped and is not claimed as hosted validation. Canonical C++ evidence is the exact-head local Linux proof described above: Doxygen 1.16.1, Python 3.12.13, 9/9 validation, two-run identity, and committed-byte identity.Diff-tag, API, and advisory evidence
The prior external
[macOS]audit reported zero new pairing issues, file-marker issues, or untagged preprocessor-condition keys versus the 0.86 baseline. Its raw scanner output contained 30,879 new suspect keys and 676 deletion-coordinate deltas; after normalization and exhaustive classification, zero entries were unexplained. The raw counts are disclosed as scanner findings, not represented as normalized failures.That external raw/normalized diff-tag audit was not rerun on exact head
d8c588e4a6. The seven recovery commits change C++ snapshots,Gemfile.lock, one tagged Hermes podspec line,Podfile.lock, and tagged Hermes build-script changes; static marker and Paper-scope checks are green on98e4b51f38, but the prior external audit remains prior evidence rather than a new certification.The following are also prior evidence and were not rerun on
d8c588e4a6after the native stop:POTENTIALLY_BREAKING: 137 changed API symbols versus the 0.86 parent and 104 versus upstream 0.87. Machine reports contain the complete symbol and native/C++ file deltas.undici@7.25.0.Rough command record
Authoritative 143-path conflict ledger
Each authoritative Git conflict path appears exactly once below with bilateral source provenance, status class, decision, and rationale.