test(pages-router): regression coverage for edge runtime & OG image API routes (#1338)

[james-elicx]

Summary

Adds Pages Router-only fixtures and dev + production integration tests for the two scenarios reported as failing in the Next.js Deploy Suite (#1338):

• export const config = { runtime: 'edge' } API route returns a Web Response (case 1 — /api/hello was observed as 500).
• next/og ImageResponse with runtime: 'edge' inside a Pages Router API route returns image/png (case 2 — /api/og was observed as 404).

The existing implementation already routes both code paths through handlePagesApiRoute and applies the vinext:og-inline-fetch-assets Vite transform; this PR locks in regression coverage so a Pages Router-only build cannot silently regress either path. Both new tests pass locally against the current main-equivalent code.

Route handlers are ported from Next.js' own e2e fixtures:

• next.js/test/e2e/edge-pages-support/app/pages/api/hello.js
• next.js/test/e2e/og-api/app/pages/api/og.js

Scoped intentionally — the App Router OG + custom-font (/font/opengraph-image 500) and other edge-runtime test-suite gaps remain out of scope for this PR and continue to be tracked under #1338.

Refs #1338

Test plan

• pnpm test tests/pages-router.test.ts — dev + prod regression cases pass (271 tests)
• pnpm test tests/pages-api-route.test.ts — direct handler unit tests still pass
• pnpm run check — fmt, lint, types clean

[james-elicx]

/bigbonk review

[pkg-pr-new]

Open in StackBlitz

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

commit: 450cfcf

[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
web	preview	production

[ask-bonk]

Review: LGTM

Clean, well-scoped regression coverage PR. Fixtures are faithful to the upstream Next.js test sources and the test assertions cover the right things.

What's good

• Fixture provenance comments link back to the exact Next.js source files — easy to cross-reference.
• Both dev (standalone it() blocks in "Pages Router integration") and prod (inside the monolithic "serves pages from production build end-to-end") paths are covered.
• The edge-hello.ts handler exercises req.nextUrl.searchParams with a query param, not just a bare request — this catches a broader class of edge-route dispatch bugs.
• The OG route test checks both content-type: image/png and non-zero blob size, which is sufficient to prove the ImageResponse rendered end-to-end.
• The NextRequestLike type in edge-hello.ts is pragmatic — it avoids pulling in the full NextRequest type from next/server while still exercising the nextUrl.searchParams API surface that handlePagesApiRoute wires up for edge routes.

Nits (non-blocking)

1. Prod coverage lives in the monolithic test: The edge API and OG assertions are appended inside it("serves pages from production build end-to-end") which already has ~25 sub-assertions. If that test fails on an unrelated assertion (e.g., the ssr-cache-control check above), the edge/OG assertions never run. Consider splitting these into the describe("Production server middleware (Pages Router)") block as standalone it() blocks in a follow-up — that describe already has startProdServer lifecycle hooks, so the edge/OG tests would get independent pass/fail reporting for free.

2. No startProdServer-based standalone tests: The describe("Production server middleware (Pages Router)") block (which uses startProdServer and has independent it() blocks) doesn't get edge/OG coverage from this PR. The middleware matcher /((?!api|_next|favicon\.ico|mw-object-gated).*) excludes /api/* from middleware, so the prod-server routing path for API routes is actually different — worth covering independently when time permits.

Both nits are follow-up material. The coverage as-is is a net improvement and locks in the regression.

[ask-bonk]

Approved PR #1648. The PR adds solid regression coverage for the two Pages Router edge-runtime scenarios reported in #1338 (edge API routes returning 500 and OG image routes returning 404). The fixtures are faithfully ported from the upstream Next.js test suite, and both dev-mode and production-mode code paths are covered.

I left two non-blocking nits about the prod-mode tests being embedded in the monolithic "serves pages from production build end-to-end" test rather than as standalone it() blocks in the startProdServer-based describe block — but that's follow-up material and doesn't block this PR.

github run