feat(client): PWA install + offline shell via Expo #208

New issue

Closed

opened 2026-06-21 14:53:59 +00:00 by james · 0 comments

james commented

2026-06-21 14:53:59 +00:00

Owner

Context

#185 decommissioned the Next.js UI, including the @serwist/next PWA wiring (manifest.ts, sw.ts, sw-register.tsx, offline page). The universal client at apps/client/ now serves every screen via the Expo Web bundle, but Expo Web does NOT yet ship its own PWA wiring — so PWA install + offline shell have regressed.

Scope

Configure Expo Web PWA support (manifest, service worker, install prompt) on the universal client.
Restore the offline shell. The previous version was a force-static /offline page Serwist used as a navigation fallback when the network was unreachable — the Expo SW needs an equivalent.
Port the existing icons into the Expo bundle if they aren't already used:
- apps/api/public/icon.svg
- apps/api/public/icon-192.png
- apps/api/public/icon-512.png
Ensure the SW cache strategy makes sense for the SPA: app shell + hashed _expo/static/** precache, /api/* network-first (or runtime-cached with a short TTL), HTML pages no-cache.
Update the public-route allowlist in apps/api/lib/auth/public-routes.ts to re-add whatever paths the new Expo SW lands on (/sw.js, manifest, workbox chunks if any).

Acceptance

A fresh install of the PWA from a supported browser succeeds (browser shows the install prompt and the resulting standalone app boots into the SPA shell).
After the SW registers, killing the network and reloading still renders the offline shell instead of the browser's "no internet" page.
pnpm -F @carol/api build + the container smoke tests from #185 still pass.

Notes

Part of #176 (universal-client work). Tracks the regression called out in #185's PR description.

## Context [#185](https://forge.wynning.tech/james/carol/issues/185) decommissioned the Next.js UI, including the `@serwist/next` PWA wiring (manifest.ts, sw.ts, sw-register.tsx, offline page). The universal client at `apps/client/` now serves every screen via the Expo Web bundle, but Expo Web does NOT yet ship its own PWA wiring — so PWA install + offline shell have regressed. ## Scope - Configure Expo Web PWA support (manifest, service worker, install prompt) on the universal client. - Restore the offline shell. The previous version was a `force-static` `/offline` page Serwist used as a navigation fallback when the network was unreachable — the Expo SW needs an equivalent. - Port the existing icons into the Expo bundle if they aren't already used: - `apps/api/public/icon.svg` - `apps/api/public/icon-192.png` - `apps/api/public/icon-512.png` - Ensure the SW cache strategy makes sense for the SPA: app shell + hashed `_expo/static/**` precache, `/api/*` network-first (or runtime-cached with a short TTL), HTML pages no-cache. - Update the public-route allowlist in `apps/api/lib/auth/public-routes.ts` to re-add whatever paths the new Expo SW lands on (`/sw.js`, manifest, workbox chunks if any). ## Acceptance - A fresh install of the PWA from a supported browser succeeds (browser shows the install prompt and the resulting standalone app boots into the SPA shell). - After the SW registers, killing the network and reloading still renders the offline shell instead of the browser's "no internet" page. - `pnpm -F @carol/api build` + the container smoke tests from #185 still pass. ## Notes Part of #176 (universal-client work). Tracks the regression called out in #185's PR description.

james referenced this issue

2026-06-21 14:54:41 +00:00

chore(api): decommission Next.js UI (#185) #209

james referenced this issue from a commit

2026-06-21 17:46:49 +00:00

feat(client): expo web manifest + icons (#208)

james referenced this issue from a commit

2026-06-21 17:46:49 +00:00

feat(client): service worker with precache + offline shell (#208)

james referenced this issue from a commit

2026-06-21 17:46:49 +00:00

feat(api): public-route allowlist for new SW + manifest paths (#208)