Vercel Feature Lab

A hands-on tour of Vercel and Next.js. Each page demos one feature live, explains it, and shows the code behind it. It's the companion to the Cloudflare Feature Lab (repo), built to the same pattern so the two platforms can be compared side by side.

Stack: Next.js 16 (App Router, TypeScript, Cache Components) · live at https://vercel.djmiskey.com (vercel-feature-lab.vercel.app redirects there with a 308).

Run it

npm install
cp .env.example .env.local   # local env vars and a dummy secret
npm run dev                  # http://localhost:3000

Production build locally: npm run build && npm start.

Checks

npm run lint
npm run typecheck
npm test          # Vitest: request helpers, feature registry, route handlers, revalidation webhook, Proxy rules and session cookies, flag bucketing, upload checks, note rules, rate-limit helpers, cron route and config, simulated AI chat, CSP, firewall rules and reports, the comparison table
npm run build     # also catches Cache Components mistakes
npm run e2e       # Playwright against the build (starts `npm start` on :3200)
BASE_URL=https://vercel.djmiskey.com npm run e2e   # …or against a deployment, plus the @deployed tests
npm run db:migrate  # applies db/schema.sql to DATABASE_URL (safe to re-run)

CI (.github/workflows/ci.yml) runs lint, typecheck, unit tests, the build and the end-to-end suite on every pull request.

End-to-end tests (e2e/, Playwright) are read-only (previews and production share one Neon database, so nothing signs the guestbook, uploads or spends a shared rate limit). pages.spec loads every page on desktop and a Pixel 7 and fails on exceptions, console errors, failed requests, CSP blocks (except the one /security blocks on purpose, which it requires) and sideways overflow; in CI there are no secrets, so it also proves every page degrades gracefully. headers.spec checks the security headers, the per-request nonce on /security, the sandbox CSP on uploads, Proxy's cookies and redirects, and the API routes' refusals. a11y.spec runs axe (WCAG 2.2 A/AA) in light and dark mode. behaviour.spec streams, chats with the simulated model and signs in to the members area. Tests tagged @deployed run only with BASE_URL: the Firewall's 403s, x-vercel-id, BotID refusing a scripted request, the .vercel.app 308 and every service connected. Locally the browser is the installed Edge; CI installs Chromium. Web Analytics' and Speed Insights' /_vercel/… scripts only exist on Vercel, so their 404s are allowed off Vercel and fail the suite on a deployment.

Layout

Path	What lives there
src/lib/features.ts	Registry of all features; drives the nav and the home page
src/app/<slug>/page.tsx	One folder per built feature page
src/app/api/*/route.ts	Route handlers (API endpoints, run as Vercel Functions)
src/components/	FeaturePage, Demo, JsonView, CodePeek, Nav
src/proxy.ts	Proxy (formerly middleware); its rules live in src/lib/proxy-rules.ts
src/flags.ts	Feature flags (Flags SDK), decided from Global Config
vercel.json	Cron schedule and Firewall rules
src/lib/comparison.ts	Vercel vs Cloudflare mapping (tests keep it in sync with both labs' pages)
src/instrumentation-client.ts	BotID client (which routes get the invisible challenge)
db/schema.sql	Postgres schema (the guestbook table)
next.config.ts	Cache Components + security headers (plus a sandboxing CSP for uploaded files)

Adding a feature: create src/app/<slug>/page.tsx using FeaturePage and add it to features.ts with ready: true. A test checks that every ready feature has a page. (The [slug] placeholder route for unbuilt features was removed once every feature was built; bring it back if you add ready: false entries.)

以上為 README 的開頭部分。其餘內容請閱讀原文。 檢視完整 README ↗