Fix Pages prod middleware named proxy export resolution

[pomarie]

summary

we found a production-only mismatch in how vinext runs proxy.ts for Pages Router apps.

if an app exported proxy.ts as export function proxy(...) (named export), the generated production middleware runner ignored it and acted like no middleware existed. this means requests could continue straight to routes that were expected to be gated by proxy logic.

why this is a problem

teams commonly put auth/authz checks in proxy.ts (redirect unauthenticated users, block private paths, tenant checks, etc).

before this fix, those checks could silently not run in Pages production output when using named proxy. that is teh dangerous part: no crash, just skipped protection.

why lowercase proxy

we resolve the export by exact name, and JavaScript export names are case-sensitive. Next.js 16 also documents/uses proxy in lowercase. so proxy must be matched exactly; Proxy or PROXY are different identifiers.

what changed

• fixed generated Pages production resolver to use: default || proxy || middleware
• updated middleware warning/docs text to mention named proxy support
• added regression tests for:
  • named proxy execution in generated Pages prod entry
  • export precedence (default > proxy > middleware)
  • codegen assertion coverage in app-router test suite

[southpolesteve]

/bigbonk review please

[southpolesteve]

Thanks for the PR, yeah this looks like a legit issue. Will work on merging

[ask-bonk]

Review: Fix Pages prod middleware named proxy export resolution

This is a clean, well-targeted fix for a real production-only bug. The core issue is confirmed: on main, the Pages Router production entry codegen (index.ts:665) generated middlewareModule.default || middlewareModule.middleware, missing the middlewareModule.proxy fallback that was already present in both middleware.ts:196 (dev runtime) and app-dev-server.ts:1295 (App Router codegen). This means a proxy.ts using export function proxy(...) (named export, no default) would silently be ignored in Pages Router production builds — a dangerous parity gap.

After this fix, all four middleware resolution sites are consistent:

• middleware.ts:196 — dev runtime: mod.default ?? mod.proxy ?? mod.middleware (already correct on main)
• app-dev-server.ts:1295 — App Router RSC codegen: middlewareModule.default || middlewareModule.proxy || middlewareModule.middleware (already correct on main)
• index.ts:665 — Pages Router prod codegen: now includes middlewareModule.proxy (this PR)
• prod-server.ts — calls runMiddleware from the generated entry, so inherits the fix

The test coverage is good:

1. Integration test that builds a real Pages Router app with named proxy export and verifies the redirect fires
2. Precedence test confirming default > proxy > middleware ordering
3. Unit test for the dev-server runMiddleware path with a named proxy mock
4. Codegen assertion for the App Router generated entry

Two minor notes below, but nothing blocking.

[ask-bonk]

Nit: It might be worth adding a third test case that verifies a proxy.js with only a named middleware export (no default, no proxy) also works through the generated prod entry. That would fully exercise the third fallback position in the chain. Not a blocker though — the current tests already cover the important cases.

[ask-bonk]

This test asserts on the generated code string, which is sufficient for catching regressions. Note that the App Router codegen already had proxy support on main — this test is purely additive insurance, which is a good thing.

[ask-bonk]

Review submitted. Here's a summary of what I found:

Verdict: Approved

The PR fixes a confirmed production-only bug where the Pages Router production codegen (index.ts:665) was missing middlewareModule.proxy in the middleware resolution chain. The three other resolution sites (middleware.ts, app-dev-server.ts, and prod-server.ts via delegation) already had it. This meant export function proxy(...) in proxy.ts would silently be skipped in Pages production builds — particularly dangerous since proxy.ts is commonly used for auth checks.

The fix is a single-line change plus doc/warning text updates, with solid test coverage: two integration tests (named proxy execution + export precedence), one unit test, and one codegen assertion.

github run

[pkg-pr-new]

Open in StackBlitz

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

commit: b6be6d6

[pomarie]

Thanks for the PR, yeah this looks like a legit issue. Will work on merging

Thanks! Glad it helped. We actually caught this with a @cubic-dev-ai codebase scans - running 1000s of agents to flag critical issues.

It caught a bunch of other stuff too - not sure if you'd want to look into them or if this repo isn't really made for production-use

[pomarie]

@southpolesteve ^

[pomarie]

@southpolesteve could we also get a CVE + bug bounty for this?