* web: configure vercelPreset() for Vercel deployments
Enables per-route bundle splitting, function-level configuration, and an
accurate Deployment Summary for the packages/web Vercel deployment.
Gated on WORKFLOW_WEB_VERCEL_BUILD (rather than the ambient VERCEL var)
so that the standard build layout consumed by server.js (self-hosted
deployments and the CLI's in-process server via @workflow/web/server) is
still produced when the package is packed as a tarball by the docs
Vercel deployment. Existing VERCEL-based checks in vite.config.ts have
been migrated to this same variable for consistency.
* web: allow WORKFLOW_WEB_VERCEL_BUILD through Turborepo
Turborepo strips environment variables not declared in turbo.json, which
prevented WORKFLOW_WEB_VERCEL_BUILD (set on the Vercel project) from
reaching the build. Declare it in the env list and also include the
.vercel/ directory (where the preset writes react-router-build-result.json)
in the build outputs.
* web: narrow Turbo output to react-router-build-result.json
* web: address PR review feedback
- Check WORKFLOW_WEB_VERCEL_BUILD === '1' explicitly (rejects '0', 'false',
etc.) in both react-router.config.ts and vite.config.ts
- Use double-quoted package name in changeset frontmatter to match the
repo's dominant convention
## Summary
- Replace Next.js App Router with React Router v7.13.0 framework mode (Vite-based), eliminating the large `next` dependency from the web, CLI, and workflow metapackages
- Serve the web UI in-process from the CLI via Express instead of spawning `next start` as a child process
- Switch RPC transport from JSON to CBOR to preserve binary data types across the wire
- Replace `nuqs` URL state management with React Router's `useSearchParams`
- Replace Next.js server actions with an RPC resource route (`/api/rpc`) and a thin CBOR-based client
## Motivation
The `next` package is ~300MB installed and was the single largest dependency in the monorepo. It also required spawning a separate child process from the CLI to run the o11y web server, adding complexity around process lifecycle management, port readiness polling, and environment variable forwarding.
With React Router framework mode, the web package builds to a standard Express-compatible server bundle that the CLI can import and serve directly in its own process.
## What changed
**Framework swap (`@workflow/web`):**
- `next.config.ts` / `postcss.config.mjs` → `react-router.config.ts` / `vite.config.ts`
- `src/` directory → `app/` directory (React Router convention)
- `src/app/layout.tsx` + `layout-client.tsx` → `app/root.tsx`
- `src/app/page.tsx` → `app/routes/home.tsx`
- `src/app/run/[runId]/page.tsx` → `app/routes/run-detail.tsx`
- Path alias `@/` → `~/`
- Removed all `'use client'` / `'use server'` directives
**Data transport:**
- Server actions → RPC resource route at `/api/rpc` with CBOR encoding
- CBOR preserves `Uint8Array` and other binary types natively (no base64 overhead)
- Stream reading → dedicated `/api/stream/:streamId` resource route
**URL state:**
- `nuqs` (`useQueryState`) → `useSearchParams` from `react-router`
**Fonts:**
- `next/font/google` → Geist `.woff2` files referenced directly from `node_modules/geist` via `@font-face` in CSS
**CLI integration (`@workflow/cli`):**
- `import('@workflow/web/server').then(m => m.startServer(port))`
- No child process, no readiness polling, no cleanup handlers
**Radix UI compatibility:**
- `onSubmit` preventDefault on `AlertDialogContent` and `SheetContent` to prevent Radix's internal `<form method="dialog">` from triggering React Router route actions
- Catch-all action on root route for any stray POSTs
## Dependencies removed
- `next`, `swr`, `nuqs`, `@tailwindcss/postcss`
## Dependencies added
- `react-router` / `@react-router/dev` / `@react-router/node` / `@react-router/express` (all `7.13.0`)
- `express`, `vite`, `@tailwindcss/vite`, `cbor-x`, `isbot`, `cross-env`
- `geist` (devDep)
Nathan Rajlich