vercel.ts and api/server.js are read by Vercel for every deploy in this
repo regardless of which framework preset is selected, which means the
TanStack-flavoured rewrites, `framework: null`, and `dist/server` import
would clobber the Next.js prod build. Default both to a no-op shape and
opt in to the TanStack behaviour with STUDIO_FRAMEWORK=tanstack — set in
the branch's dev/build/start/preview scripts and on the TanStack Vercel
project's dashboard env vars.
TanStack's server bundle already exposes `.fetch(request)`. Vercel's
Web API handler pattern (per the docs) invokes that method on the
default export, passing a real Web Request — so we can skip the
hand-rolled IncomingMessage→Request adapter entirely.
Vercel's Node runtime hands the function an IncomingMessage-shaped object:
path-only `.url`, plain-object `.headers`, Node Readable `.body`. TanStack's
H3 server wants a Web-standard Request. Convert headers to a Headers
instance, rebuild an absolute URL from the host header, and bridge the
Node stream body to a web ReadableStream via Readable.toWeb.
Vercel's Node runtime passes a Request-like object where `.url` is
path-only (IncomingMessage semantics). TanStack's H3Event constructor
calls new URL(req.url) and crashes with ERR_INVALID_URL. Reconstruct
the URL from the host header before forwarding.
Keep the base-path-prefixed rewrites for assets and routes that Vite
already baked the prefix into, but also emit root-level rewrites so
bare-domain hits (including /) resolve to the shell instead of Vercel's
default 404.
Alaister Young