refactor: Extract early config header and public file pipeline

[NathanDrake2406]

Summary

• Move next.config.js header application into request-pipeline helpers for both Web Headers and early header records.
• Move App Router public-file static response resolution into request-pipeline, leaving generated RSC entry code to describe app shape and route manifests.
• Reuse the same config-header helper from the Pages production server and generated Pages Worker entry; export vinext/server/request-pipeline for generated worker code.
• Add focused tests for original-request matcher context, middleware/config header precedence, multi-value header appends, and public-file routing policy.

Next.js references

Vinext should keep the route policy aligned with Next.js while keeping behavior out of generated templates:

• Next.js documents the request order as headers, redirects, proxy/middleware, beforeFiles, then filesystem routes including public/: https://github.com/vercel/next.js/blob/canary/docs/01-app/03-api-reference/03-file-conventions/proxy.mdx
• Next.js resolve-routes.ts models that same order with fsChecker.headers, fsChecker.redirects, middleware, rewrites.beforeFiles, and filesystem checks: https://github.com/vercel/next.js/blob/canary/packages/next/src/server/lib/router-utils/resolve-routes.ts
• The redirects docs explicitly call out that redirects are checked before filesystem routes, including /public files: https://github.com/vercel/next.js/blob/canary/docs/01-app/03-api-reference/05-config/01-next-config-js/redirects.mdx
• Next.js filesystem routing handles public/static asset matching in filesystem.ts: https://github.com/vercel/next.js/blob/canary/packages/next/src/server/lib/router-utils/filesystem.ts
• Next.js integration coverage includes public files after rewrites and public-file precedence over dynamic routes: https://github.com/vercel/next.js/blob/canary/test/integration/custom-routes/test/index.test.ts and https://github.com/vercel/next.js/blob/canary/test/integration/dynamic-routing/test/index.test.ts

Tests

• vp test run tests/request-pipeline.test.ts
• vp test run tests/app-router.test.ts -t "custom header handling|empty config arrays|rewrite handling code|config pattern"
• vp test run tests/deploy.test.ts -t "next.config.js custom headers|next.config.js redirects|next.config.js rewrites|basePath stripping"
• vp test run tests/request-pipeline.test.ts tests/deploy.test.ts
• vp test run tests/app-router.test.ts -t "custom headers from next.config.js|serves public files from the build output|serves public files under basePath|App Router next.config.js features"
• vp test run tests/entry-templates.test.ts
• vp fmt --check packages/vinext/src/server/request-pipeline.ts packages/vinext/src/entries/app-rsc-entry.ts packages/vinext/src/server/prod-server.ts packages/vinext/src/deploy.ts tests/request-pipeline.test.ts tests/app-router.test.ts tests/deploy.test.ts packages/vinext/package.json
• vp check
• vp run vinext#build

[pkg-pr-new]

Open in StackBlitz

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

commit: 1bbf648

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[james-elicx]

/bigbonk review

[ask-bonk]

Clean refactor that successfully extracts duplicated config-header and public-file logic from generated entries and server hot paths into testable helpers in request-pipeline.ts. All CI green.

What I verified:

• applyConfigHeadersToResponse faithfully reproduces the old inline App Router entry behavior: append for vary/set-cookie, set only when !has().
• applyConfigHeadersToHeaderRecord faithfully reproduces the old inline Pages Router prod-server and Worker entry behavior, with one inconsequential difference: for set-cookie with no pre-existing value, the old code stored [value] (always array) while the new appendHeaderRecord stores a plain value (string). This is safe because all downstream consumers (toWebHeaders, mergeHeaders, sendCompressed) handle both string and string[] correctly.
• findHeaderRecordKey adds case-insensitive key lookup, which is a minor improvement over the old lk in middlewareHeaders (which happened to work because both sides were lowercased).
• resolvePublicFileRoute exactly reproduces the old inline checks: method guard (GET/HEAD), .rsc exclusion on pathname, public-file lookup on cleanPathname, and createStaticFileSignal matches the old __createStaticFileSignal.
• The new ./server/request-pipeline package.json export is correctly placed for the generated worker entry to consume.
• Tests cover the important contracts: original-request matcher context, middleware precedence, multi-value header appends, and public-file routing policy.
• Snapshot updates are mechanical and consistent across all fixture variants.

One small observation below, but nothing blocking.

[ask-bonk]

Minor observation: the old inline set-cookie code in prod-server.ts and deploy.ts always stored a fresh set-cookie as an array (middlewareHeaders[lk] = [h.value]), whereas appendHeaderRecord stores it as a plain string when there's no existing value. This is safe today because all downstream consumers (toWebHeaders, mergeHeaders) handle both string and string[], but worth noting in case a future consumer assumes set-cookie values are always arrays.

[ask-bonk]

Review submitted. Approved with one minor observation.

Summary: This is a well-executed refactor that extracts duplicated config-header application and public-file routing logic from 3 places (generated App Router RSC entry, Pages Router prod-server, and generated Worker entry) into shared, tested helpers in request-pipeline.ts. The behavioral equivalence is verified across all code paths, all CI checks pass, and the new tests cover the key contracts. The one minor difference (set-cookie stored as string vs array for single values with no prior entry) is inconsequential since all downstream consumers handle both forms.

github run