chore(client): bump react-native from 0.85.3 → 0.86.x and retire the foojay patch #281

New issue

Open

opened 2026-06-24 13:51:10 +00:00 by james · 1 comment

james commented

2026-06-24 13:51:10 +00:00

Owner

Context

#278 patched @react-native/gradle-plugin@0.85.3's settings.gradle.kts to bump org.gradle.toolchains.foojay-resolver-convention from 0.5.0 → 1.0.0. The patch exists because RN 0.85.x shipped a known-broken combo: Gradle 9.3.1 wrapper paired with a foojay plugin that references JvmVendorSpec.IBM_SEMERU (removed in Gradle 9.0).

Upstream React Native already fixed this in @react-native/gradle-plugin@0.86.0 — same change, identical foojay version. The patch is a backport, not a workaround.

Goal

When we bump react-native (and the matched @react-native/* packages) to 0.86.x, the patch becomes redundant. Drop the patch in the same commit as the RN bump so we don't leave a stale entry in pnpm.patchedDependencies — pnpm will fail the install if the patch's target file shape has shifted, and we'd rather discover that intentionally.

Surface to audit on the bump

apps/client/package.json — react-native dep, plus the matched @react-native/* peers (metro-config, etc.)
Root package.json — pnpm.overrides.react-native pin and pnpm.patchedDependencies entry (delete the latter)
patches/@react-native__gradle-plugin@0.85.3.patch — delete
pnpm-lock.yaml — re-resolve
The full RN 0.85 → 0.86 changelog — RN minor bumps regularly touch the New Architecture, autolinking, and Android build config. Read the Expo SDK 56 (or whatever SDK we're on at that point) compatibility note before deciding to do this — Expo pins react-native and they may not have shipped a 0.86-compatible SDK yet.

Acceptance

patches/ no longer contains the gradle-plugin patch.
Root package.json pnpm.patchedDependencies is removed (or only contains other patches).
The Android release pipeline runs cleanly with the new RN — verified on a release tag run or via the PR-time validation job (whichever lands first; see the companion follow-up ticket).

Out of scope

Bumping Expo SDK in the same change. Expo's RN pin is its own decision; if a new Expo SDK lands that ships with RN 0.86+, this becomes a non-issue and the Expo SDK bump ticket subsumes this one.

Relates to #278.

## Context #278 patched `@react-native/gradle-plugin@0.85.3`'s `settings.gradle.kts` to bump `org.gradle.toolchains.foojay-resolver-convention` from `0.5.0` → `1.0.0`. The patch exists because RN 0.85.x shipped a known-broken combo: Gradle 9.3.1 wrapper paired with a foojay plugin that references `JvmVendorSpec.IBM_SEMERU` (removed in Gradle 9.0). Upstream React Native already fixed this in `@react-native/gradle-plugin@0.86.0` — same change, identical foojay version. The patch is a backport, not a workaround. ## Goal When we bump `react-native` (and the matched `@react-native/*` packages) to `0.86.x`, the patch becomes redundant. **Drop the patch in the same commit as the RN bump** so we don't leave a stale entry in `pnpm.patchedDependencies` — pnpm will fail the install if the patch's target file shape has shifted, and we'd rather discover that intentionally. ## Surface to audit on the bump - `apps/client/package.json` — `react-native` dep, plus the matched `@react-native/*` peers (metro-config, etc.) - Root `package.json` — `pnpm.overrides.react-native` pin and `pnpm.patchedDependencies` entry (delete the latter) - `patches/@react-native__gradle-plugin@0.85.3.patch` — delete - `pnpm-lock.yaml` — re-resolve - The full RN 0.85 → 0.86 changelog — RN minor bumps regularly touch the New Architecture, autolinking, and Android build config. Read the Expo SDK 56 (or whatever SDK we're on at that point) compatibility note before deciding to do this — Expo pins react-native and they may not have shipped a 0.86-compatible SDK yet. ## Acceptance - `patches/` no longer contains the gradle-plugin patch. - Root `package.json` `pnpm.patchedDependencies` is removed (or only contains other patches). - The Android release pipeline runs cleanly with the new RN — verified on a release tag run or via the PR-time validation job (whichever lands first; see the companion follow-up ticket). ## Out of scope - Bumping Expo SDK in the same change. Expo's RN pin is its own decision; if a new Expo SDK lands that ships with RN 0.86+, this becomes a non-issue and the Expo SDK bump ticket subsumes this one. Relates to #278.

james referenced this issue

2026-06-26 23:31:03 +00:00

chore(client): bump Expo SDK 56 → 57 (brings react-native 0.86) #304

james commented

2026-06-26 23:31:16 +00:00

Author

Owner

Blocked on Expo SDK — holding this ticket. Investigated the compatibility gate the description calls out, and a standalone RN 0.86 bump isn't safe today:

We're on expo@56.0.12 (SDK 56), which pins react-native: 0.85.3 in bundledNativeModules.json — the version Expo's prebuilt native modules are built against. The full @react-native/* family is locked at 0.85.3.
RN 0.86.0 has shipped upstream (react-native@latest = 0.86.0, no patch releases yet), but Expo only ships RN 0.86 in SDK 57, which is currently preview-only (expo@next = 57.0.0-preview.0).
RN can't be bumped independently of the Expo SDK — the native ABI/JS surface is version-locked, so RN 0.86 on SDK 56 would break the native client.
Per this ticket's own "Out of scope" note, the SDK bump subsumes this work once it lands RN 0.86+.

Filed #304 (bump Expo SDK 56 → 57) as the blocker; #281 is folded into it (the foojay patch retirement happens as part of that bump, since upstream RN 0.86 already carries the foojay 1.0.0 fix). Recommend holding #281 until expo@latest ≥ 57 (also clears ADR-0009's version-age quarantine on the freshly-published 0.86.0).

**Blocked on Expo SDK — holding this ticket.** Investigated the compatibility gate the description calls out, and a standalone RN 0.86 bump isn't safe today: - We're on `expo@56.0.12` (SDK 56), which **pins `react-native: 0.85.3`** in `bundledNativeModules.json` — the version Expo's prebuilt native modules are built against. The full `@react-native/*` family is locked at 0.85.3. - RN `0.86.0` has shipped upstream (`react-native@latest` = 0.86.0, no patch releases yet), but Expo only ships RN 0.86 in **SDK 57**, which is currently **preview-only** (`expo@next` = `57.0.0-preview.0`). - RN can't be bumped independently of the Expo SDK — the native ABI/JS surface is version-locked, so RN 0.86 on SDK 56 would break the native client. - Per this ticket's own "Out of scope" note, the SDK bump subsumes this work once it lands RN 0.86+. Filed **#304** (bump Expo SDK 56 → 57) as the blocker; #281 is folded into it (the foojay patch retirement happens as part of that bump, since upstream RN 0.86 already carries the foojay 1.0.0 fix). Recommend holding #281 until `expo@latest` ≥ 57 (also clears ADR-0009's version-age quarantine on the freshly-published 0.86.0).