fix(deps): pin react-native to 0.85.3 via pnpm.overrides #232

Merged

james merged 12 commits from fix-rn-dedupe into main 2026-06-23 11:47:35 +00:00

Conversation 2 Commits 12 Files changed 26 +257 -374

james commented 2026-06-21 19:22:27 +00:00

Owner

Copy link

Summary

Follow-up to PR #231. The react + react-dom overrides shipped there pinned the bundle to 19.2.3, but Expo Go still reported the React-version mismatch. Investigation found a second react-native version in the workspace.

Root cause

@carol/api-client declares @react-native-community/netinfo and react-native as optional peer deps with the wildcard * version range. When pnpm resolves api-client into the workspace, its peer resolver picks the latest matching for each peer — react-native@0.86.0 for netinfo's peer, not the workspace-pinned 0.85.3.

Result: two react-native sub-graphs in node_modules/.pnpm/:

react-native@0.85.3_…    (pinned, used by apps/client direct)
react-native@0.86.0_…    (transitive via netinfo, brings its own React)

Expo Go's renderer is built against react-native@0.85.3 exactly, so anything else in the bundle triggers the React-version-mismatch error at runtime. The earlier React-version overrides didn't help because the mismatch was downstream, in the RN sub-graph.

Fix

Add react-native: 0.85.3 to root pnpm.overrides. Forces every consumer — including api-client's optional peer-dep resolution — to the workspace's pinned version. The optional-peer declaration in api-client stays intact (it's still the correct intent).

Verified

$ pnpm install --frozen-lockfile
$ find node_modules/.pnpm -name 'react-native' -type d | grep -v 0.86
# only 0.85.3 directories remain
$ pnpm -F @carol/client export:web
# bundle sniff: react 19.2.3, no 19.2.7 anywhere

Test plan

• pnpm install --frozen-lockfile clean.
• No react-native@0.86 references in pnpm-lock.yaml.
• pnpm -F @carol/client export:web succeeds; rebuilt bundle has only React 19.2.3.
• Manual: Expo Go on a real device boots the bundle without the React/renderer mismatch error.

Forward compatibility

When Expo SDK 57 lands and bumps react-native to the next major, bump the override here in the same PR (and the workspace pins in apps/client).

## Summary Follow-up to PR #231. The `react` + `react-dom` overrides shipped there pinned the bundle to 19.2.3, but Expo Go still reported the React-version mismatch. Investigation found a **second react-native version** in the workspace. ## Root cause `@carol/api-client` declares `@react-native-community/netinfo` and `react-native` as optional peer deps with the wildcard `*` version range. When pnpm resolves api-client into the workspace, its peer resolver picks the **latest matching** for each peer — `react-native@0.86.0` for netinfo's peer, not the workspace-pinned `0.85.3`. Result: two `react-native` sub-graphs in `node_modules/.pnpm/`: ``` react-native@0.85.3_… (pinned, used by apps/client direct) react-native@0.86.0_… (transitive via netinfo, brings its own React) ``` Expo Go's renderer is built against `react-native@0.85.3` exactly, so anything else in the bundle triggers the React-version-mismatch error at runtime. The earlier React-version overrides didn't help because the mismatch was downstream, in the RN sub-graph. ## Fix Add `react-native: 0.85.3` to root `pnpm.overrides`. Forces every consumer — including api-client's optional peer-dep resolution — to the workspace's pinned version. The optional-peer declaration in `api-client` stays intact (it's still the correct intent). ## Verified ``` $ pnpm install --frozen-lockfile $ find node_modules/.pnpm -name 'react-native' -type d | grep -v 0.86 # only 0.85.3 directories remain $ pnpm -F @carol/client export:web # bundle sniff: react 19.2.3, no 19.2.7 anywhere ``` ## Test plan - [x] `pnpm install --frozen-lockfile` clean. - [x] No `react-native@0.86` references in `pnpm-lock.yaml`. - [x] `pnpm -F @carol/client export:web` succeeds; rebuilt bundle has only React 19.2.3. - [ ] Manual: Expo Go on a real device boots the bundle without the React/renderer mismatch error. ## Forward compatibility When Expo SDK 57 lands and bumps `react-native` to the next major, bump the override here in the same PR (and the workspace pins in `apps/client`).

james added 1 commit 2026-06-21 19:22:27 +00:00

fix(deps): pin react-native to 0.85.3 via pnpm.overrides ... f85521ed1b

The react@19.2.3 + react-dom@19.2.3 overrides shipped in #231 didn't
fully solve the Expo Go version-mismatch error. Investigation showed
the workspace was resolving two react-native versions:

- 0.85.3 (Expo SDK 56's required, pinned in apps/client).
- 0.86.0 (latest), pulled in by @react-native-community/netinfo's
  peer dep — which it inherits because @carol/api-client declares it
  as an optional peer dep with the wildcard "*" range.

pnpm's peer resolver picked the latest matching version (0.86.0) to
satisfy api-client's optional peer, dragging in a second RN sub-graph
alongside the explicit 0.85.3. Expo Go's renderer is built against
0.85.3 exactly, so anything else triggers the React-version-mismatch
error.

Pinning react-native via pnpm.overrides forces every consumer to
0.85.3. The optional-peer declaration in api-client stays — it's
correct intent — but the workspace now produces a single resolution
regardless.

Bump react-native here in the same PR when Expo SDK 57 lands.

forgejo-actions commented 2026-06-21 19:26:57 +00:00

Copy link

📊 Test coverage

Patch coverage: no testable lines changed.

Overall (app/, lib/, db/, excluding UI per ADR-0019):

Metric	Value	Soft target
Lines	83.0% ✅	≥ 50%
Branches	75.9% ✅	≥ 75%
Functions	91.3%	informational

Soft thresholds per ADR-0019. Coverage is informational and does not block merge.

<!-- coverage-comment --> ## 📊 Test coverage **Patch coverage:** no testable lines changed. **Overall** (`app/`, `lib/`, `db/`, excluding UI per ADR-0019): | Metric | Value | Soft target | |---|---|---| | Lines | 83.0% ✅ | ≥ 50% | | Branches | 75.9% ✅ | ≥ 75% | | Functions | 91.3% | informational | Soft thresholds per [ADR-0019](docs/adr/0019-coverage-soft-targets.md). Coverage is informational and does not block merge.

forgejo-actions commented 2026-06-21 19:27:45 +00:00

Copy link

Trivy (container image)

Threshold: high  ·  Total findings: 121  ·  At/above threshold: 1

critical	high	medium	low
0	1	50	70

severity	id	package	installed / range	fix
high	CVE-2026-12151	undici	6.25.0	6.27.0, 7.28.0, 8.5.0

<!-- scanner-comment: trivy --> ### Trivy (container image) **Threshold:** `high` &nbsp;·&nbsp; **Total findings:** 121 &nbsp;·&nbsp; **At/above threshold:** 1 | critical | high | medium | low | |---:|---:|---:|---:| | 0 | 1 | 50 | 70 | | severity | id | package | installed / range | fix | |---|---|---|---|---| | high | [CVE-2026-12151](https://avd.aquasec.com/nvd/cve-2026-12151) | undici | 6.25.0 | `6.27.0, 7.28.0, 8.5.0` |

james added 1 commit 2026-06-21 19:32:19 +00:00

fix(client): rewrite relative URLs in the off-origin rewriter ... 745e3b1e70

The runtime URL middleware assumed `request.url` was always absolute —
true in browsers (fetch resolves Request URLs against the document
origin), false in React Native (the polyfill keeps relative inputs as
literal "/api/foo" strings).

Result: on Android, the rewriter's `new URL(originalUrl)` threw on
the relative path, the catch returned the unchanged value, and the
relative URL leaked to RN's fetch — which resolved it against
something other than the configured server. Manifested as 404s on
login from Expo Go even though the same API worked from the device's
browser.

Branch on whether the input parses as an absolute URL; if it doesn't
and starts with `/`, splice the configured base directly. Anything
else (foreign URL) passes through.

james added 1 commit 2026-06-21 19:36:01 +00:00

fix(client): explicitly copy request body in the off-origin rewriter ... 74c70c9e71

`new Request(newUrl, originalRequest)` is documented to copy fields
from a Request as init, but RN's whatwg-fetch polyfill doesn't
reliably transfer the body stream through that shortcut. The server
then sees an empty body — login surfaced as "Invalid JSON body" on
Android via Expo Go.

Read the original body out explicitly via `request.text()` and pass
it as a string in the init. Same pattern for method / headers /
credentials / signal etc. — pass each field rather than letting RN
guess.

GET / HEAD never carry a body; skip the text() read so we don't
trigger the body-already-consumed error on those.

james added 1 commit 2026-06-21 19:41:04 +00:00

fix(client): middlewares return undefined when not modifying ... 827ef5b8a7

openapi-fetch 0.17's middleware contract is: return undefined for "no
change", or a new Request / Response when modifying. Carol's middlewares
were returning the unchanged input instance instead of undefined, which
RN's polyfill environment treats as a different class identity — the
runtime `instanceof Request` / `instanceof Response` check fails and
openapi-fetch throws "onResponse: must return new Response() when
modifying the response".

Three middlewares affected:

- `authMiddleware` (api-client) mutates headers in place; was returning
  the input Request. Mutations carry through without re-returning.
- `errorMiddleware` (api-client) returned `response` on the ok path.
- `apiClient.ts` rewriter returned `request` when the URL was unchanged.

All three now return undefined for the no-change branch. The actual
replacement paths (new Request when URL changes, throw CarolApiError
on non-ok responses) are unchanged.

james added 1 commit 2026-06-21 19:44:01 +00:00

fix(client): iterate Headers explicitly when rewriting Request ... 69bb01e270

Passing `headers: request.headers` to RN's Request constructor doesn't
reliably iterate an existing Headers instance — the resulting Request
ships with no headers (or partial), so the Authorization header
authMiddleware just set disappears. The first authenticated GET after
login (useMe()) answers 401, and the protected layout bounces straight
back to /login.

Walk the Headers via forEach into an array of [key, value] tuples;
RN's polyfill copies tuples reliably.

james added 1 commit 2026-06-21 19:48:05 +00:00

fix(client): invalidate useMe cache after login ... f7b33be1d2

`useMe()` runs under the (app)/_layout auth gate. The QueryClient
defaults staleTime to 30s, so a pre-login 401 stays cached when the
post-login navigation lands. The layout reads the stale error,
redirects to /login, and the app bounces straight back to where it
started — even though the bearer tokens are now in SecureStore.

Invalidate `keys.auth.me` right before `router.replace("/notes")`.
The layout's first read re-queries with the fresh Authorization
header and sees the actual user.

james added 1 commit 2026-06-21 19:51:50 +00:00

fix(api): /api/auth/me accepts bearer tokens, not session-only ... a813f2a17b

The route called getSession() directly, which means native clients —
who hold a bearer access token in SecureStore but no session cookie —
can never satisfy it. The universal client's (app)/_layout auth gate
fires useMe() on every protected route mount; on Android the bearer
header is present but the route ignores it, returns 401, and the
layout redirects back to /login. Result: post-login navigation
appears to "flash" the app then bounce straight back, even though
the token mint succeeded and the bearer is well-formed.

Swap getSession() for getAuthIdentity() so either auth method works.
The theme-cookie refresh remains session-only — bearer callers have
no cookie to refresh, and the universal client's ThemeProvider reads
useSettings() directly.

james added 1 commit 2026-06-21 21:07:47 +00:00

fix(client): respect the status-bar inset in the mobile header ... 7c4c969ba4

The narrow-shell MobileHeader rendered at y=0, so on Android the
brand + hamburger sat under the status bar. SafeAreaProvider wasn't
mounted, so useSafeAreaInsets() would have returned zeros anyway.

Two changes:
- Mount SafeAreaProvider at the root, inside GestureHandlerRootView,
  outside the rest of the providers. Single instance for the whole
  tree.
- MobileHeader reads useSafeAreaInsets() and inflates its height +
  padding-top by `insets.top`. The 48px content height stays; the
  padding pushes the row down below the status bar without shrinking
  the touch target.

james added 1 commit 2026-06-21 21:09:09 +00:00

fix(client): give the sidebar shell flex: 1 so the nav list renders ... ceb678006c

The outer sidebar View had `flexDirection: column` but no `flex: 1`.
Inside it, the nav-list ScrollView is `flex: 1` — meant to fill the
space between the brand row and the footer. Without a flex parent
the View's height is whatever its content adds up to, which means
ScrollView's `flex: 1` distributes against zero, collapsing the nav
list to 0px. Users saw just the brand row + theme/locale footer +
logout — no Notes / Profile / Skills / etc. rows.

Permanent web sidebar didn't trip on this because the layout wraps
it in a fixed-width parent that already imposes a height. The
react-navigation drawer's `drawerContent` callback hands the Sidebar
a container without that imposition.

james added 1 commit 2026-06-21 21:13:38 +00:00

fix(api): domain routes accept bearer tokens, not just session ... 4246d17199

Same issue as /api/auth/me but across the rest of the protected
surface. Every domain route (skills, jobs, positions, contributions,
educations, settings, skill-sections) called getSession(req)
directly, ignoring the Authorization header the universal client
sends on native. The OpenAPI spec already declares them as
authenticated by either cookieAuth OR bearerAuth (the `authed`
stanza in openapi-routes.ts); the handlers just didn't follow
through.

Swap getSession → getAuthIdentity across 15 route files. The
explicit session-only routes — /api/account/tokens/* (ADR-0021),
OAuth start + callback — keep getSession unchanged.

Notes and profile already used getAuthIdentity; this brings the rest
of the protected surface in line.

james added 1 commit 2026-06-21 21:18:23 +00:00

fix(client): configure i18next for single-brace {var} interpolation ... 4ca13567f1

Carol's translation catalog at packages/i18n/messages/*.json uses ICU
single-brace interpolation ({email}, {url}) — the same shape next-intl
already consumes on the API side. i18next defaults to double-brace
{{var}}, so every interpolated string rendered literal: "Signed in as
{email}." instead of the email, "Connected to {url}." instead of the
server URL.

Override interpolation.prefix and .suffix to "{"/"}" so the same
catalog works in both runtimes.

james added 1 commit 2026-06-21 21:25:59 +00:00

perf(client): cache the access token in memory ... a5930f8597

SecureStore.getItemAsync hops to the native bridge on every call —
~5-15ms on Android. The bearer-header middleware fires per HTTP
request, so a screen with four queries pays that four times on mount
and again on each re-fetch. Caching the value in JS memory after the
first read removes the per-request bridge hop without weakening
storage durability — the token still lives in
EncryptedSharedPreferences / Keychain.

Cache is sentinel-undefined ("not loaded") vs null ("no token") vs
string ("token present") so we don't confuse a fresh-mount with a
known-empty state. setAccessToken updates the cache after writing
through; clearTokens nulls it.

The same hot path on web is a no-op (cookies cover auth on
same-origin) so no behaviour change there.

james merged commit 729f10ccbe into main 2026-06-23 11:47:35 +00:00

james deleted branch fix-rn-dedupe 2026-06-23 11:47:35 +00:00

james referenced this pull request from a commit 2026-06-23 11:47:36 +00:00

Merge pull request 'fix(deps): pin react-native to 0.85.3 via pnpm.overrides' (#232) from fix-rn-dedupe into main

james referenced this pull request 2026-06-23 11:52:56 +00:00

test(client): unit coverage for the off-origin URL rewriter + middleware contract #233

james referenced this pull request 2026-06-23 11:52:56 +00:00

test(client): native Android E2E smoke against a live API #234

james referenced this pull request 2026-06-23 12:11:57 +00:00

feat(client): show + change the configured server URL from the login screen (#235) #238

james referenced this pull request 2026-06-23 12:16:19 +00:00

chore(client): scrub style={[...]} array patterns on DOM-leaf primitives + ESLint guardrail #239

james referenced this pull request 2026-06-23 21:18:02 +00:00

feat(client): page-level edit toggle on Profile (per design package) #266

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

area:auth

Authentication and authorization

  

area:ci

Forgejo Actions, build, test, security, release

  

area:db

Database abstraction, migrations, persistence

  

area:infra

Containerization, deployment, foundational tooling

  

area:native

React Native app (Android + Linux Flatpak)

  

area:pwa

PWA / web frontend

  

area:service

Backend service, API routes, persistence

  

epic

High-level tracker; links several feature tickets

  

feature

A user-facing feature

  

foundation

Foundational work that other tickets build on

No labels

area:auth

area:ci

area:db

area:infra

area:native

area:pwa

area:service

epic

feature

foundation

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

james/carol!232

No description provided.