[james-elicx]

Summary

• add a shared Pages request cookie attachment helper using the existing Next-style Cookie parser
• use the helper for dev Pages SSR and Node Pages API request objects, aligning them with the Workers/prod Pages req/res adapter
• add Pages SSR and API fixtures/tests ported from the matching Next.js coverage

Tests

• vp test run tests/pages-router.test.ts -t "passes parsed request cookies"
• vp test run tests/pages-bodyparser-config.test.ts -t "preserves duplicate ordering and the public object API"
• vp test run tests/pages-router.test.ts -t "serves pages from production build end-to-end"
• vp check packages/vinext/src/server/dev-server.ts packages/vinext/src/server/api-handler.ts packages/vinext/src/server/pages-node-compat.ts tests/pages-router.test.ts tests/fixtures/pages-basic/pages/ssr-cookies.tsx tests/fixtures/pages-basic/pages/api/cookies.ts

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@vinext/cloudflare@2401

npm i https://pkg.pr.new/vinext@2401

commit: fffea3d

[github-actions]

Example	Preview	Production	Original
app-router-cloudflare	preview	production
pages-router-cloudflare	preview	production
app-router-playground	preview	production	original
realworld-api-rest	preview	production
nextra-docs-template	preview	production
benchmarks	preview	production
hackernews	preview	production	original
workers-cache	preview	production
web	preview	production

[github-actions]

Performance benchmarks

Compared fffea3d against base 3de7c93 using alternating same-runner rounds. Next.js was unchanged and skipped.

0 improved · 0 regressed · 6 within ±1.5%

Scenario	Framework	Baseline	Current	Change
Client bundle size (gzip)	vinext	124.0 KB	124.0 KB	⚫ -0.0%
Client entry size (gzip)	vinext	118.8 KB	118.8 KB	⚫ -0.0%
Dev server cold start	vinext	2.46 s	2.44 s	⚫ -0.6%
Production build time	vinext	2.88 s	2.86 s	⚫ -0.6%
RSC entry closure size (gzip)	vinext	95.2 KB	95.2 KB	⚫ -0.0%
Server bundle size (gzip)	vinext	161.5 KB	161.5 KB	⚫ -0.0%

View detailed results and traces

_{🟢 improvement · 🔴 regression · ⚫ change below 1.5% · paired base/head}

[james-elicx]

/bigbonk review for issues

[ask-bonk]

Review: fix(pages): expose parsed cookies on request objects

I reviewed the diff, traced dev/prod/Workers parity, checked Next.js parity for the lazy-getter pattern, and ran the targeted tests. This is a solid, well-scoped fix. No blocking issues.

What's good

• Real bug fix, not cosmetic. Dev Pages SSR (createSSRHandler) never set req.cookies at all before this — getServerSideProps saw undefined. Now both dev SSR and dev API paths get cookies, aligning with the Workers/prod adapter.
• Correct dev/prod/Workers parity (the thing AGENTS.md warns about most):
  • Prod + Workers Pages SSR/API go through createPagesReqRes, which now calls attachPagesRequestCookies internally.
  • Dev + Node API go through enhanceApiObjects (shared by dev and prod API dispatch) and the two dev-server SSR entry points (createSSRHandler, renderErrorPage).
  • All four request-construction sites are covered by a single shared helper — no divergent copies.
• Faithful Next.js parity. Next.js uses setLazyProp(req, 'cookies', getCookieParser(...)) — an enumerable, configurable, self-replacing lazy getter that bails if the prop already exists. attachPagesRequestCookies replicates this exactly: lazy getter, Object.hasOwn guard, self-replacement on first read, and a set trap that keeps the prop writable. Good attention to detail.
• Tests are well-chosen and ported with links back to the Next.js source/tests (render.tsx, api-resolver.ts). They cover the empty-cookie ({}) case and the populated case, in both dev and the production end-to-end build.

Verification I ran

• vp test run tests/pages-router.test.ts -t "passes parsed request cookies" → 2 passed (SSR + API).
• vp test run tests/pages-router.test.ts -t "serves pages from production build end-to-end" → passed, including the new prod SSR + API cookie assertions.
• vp check on all changed source + fixtures → format/lint/type clean.

Minor observations (non-blocking, no change required)

1. string[] cookie-header branch is defensively dead. parsePagesRequestCookies handles cookie?: string[] by joining with "; ", but neither carrier ever produces an array: Node IncomingMessage.headers.cookie collapses to a single string, and createPagesReqRes's headersObj is Record<string,string>. Harmless and future-proof; just noting it's currently unreachable.
2. renderErrorPage re-attach is redundant but correct. When the error page renders after a normal SSR pass, req.cookies is already an own property, so the Object.hasOwn guard makes the second attachPagesRequestCookies(req) a no-op. The explicit call is still worthwhile for error paths that bypass createSSRHandler (e.g. the 404 dispatch at line 570), so keeping it is the safer choice.

Nice work — this matches Next.js behavior and closes a genuine dev-mode gap.

[ask-bonk]

Review posted to PR #2401. Summary of findings:

Review verdict: No blocking issues — solid, well-scoped fix

What the PR does: Adds a shared attachPagesRequestCookies helper that lazily parses req.cookies from the Cookie header, then wires it into all Pages request-construction sites (dev SSR, dev/Node API, and the Workers/prod createPagesReqRes adapter).

Key correctness points I verified:

• Real bug fix: Dev Pages SSR previously never set req.cookies, so getServerSideProps saw undefined. This closes that gap.
• Dev/prod/Workers parity (the thing AGENTS.md flags hardest): all four request-building paths now funnel through one shared helper — no divergent copies.
• Next.js parity: the lazy, enumerable, configurable, self-replacing getter with a hasOwn guard exactly mirrors Next.js's setLazyProp(req, 'cookies', getCookieParser(...)).
• Tests cover empty + populated cookies in both dev and the production end-to-end build, and are ported with links to the matching Next.js source.

Verification run locally: targeted SSR/API tests pass, prod end-to-end test passes, and vp check is clean on all changed files. All CI checks on the PR are green.

Minor non-blocking notes (no changes requested): the string[] cookie-header branch is currently unreachable defensive code, and the renderErrorPage re-attach is a redundant-but-correct no-op (guarded), worth keeping for error paths that bypass the main SSR handler.

github run