Review

Clean refactoring — the extraction is well-motivated and the shared function correctly handles both the Node.js prod-server and Workers deploy paths.

Failing test

The test at tests/deploy.test.ts:550-557 fails because it asserts the old inline implementation exists in the generated worker entry string:

it("preserves x-middleware-request-* headers for prod request override handling", () => {
    const content = generatePagesRouterWorkerEntry();
    // Worker entry must unpack x-middleware-request-* into the actual request
    expect(content).toContain('const mwReqPrefix = "x-middleware-request-"');
    expect(content).toContain('key.startsWith(mwReqPrefix)');
    // Worker entry must also strip remaining x-middleware-* headers (defense-in-depth)
    expect(content).toContain('key.startsWith("x-middleware-")');
  });

The generated entry now calls applyMiddlewareRequestHeaders(middlewareHeaders, request) instead of inlining the logic, so all three assertions fail. This test needs updating — e.g., assert the import and the function call instead:

expect(content).toContain("applyMiddlewareRequestHeaders");
expect(content).toContain("applyMiddlewareRequestHeaders(middlewareHeaders, request)");

Subtle behavioral difference in prod-server (benign)

The old prod-server.ts code mutated webRequest.headers in-place:

webRequest.headers.set(realName, middlewareHeaders[key]);

The new shared function always clones via new Request(...) when there are headers to apply. This is slightly more work for the Node.js prod-server path (where headers are mutable anyway), but it's the correct approach — it makes the behavior uniform across runtimes and avoids assumptions about header mutability. The const → let change on webRequest is the necessary counterpart. No behavioral issue here.

Everything else looks good

• The JSDoc is thorough and accurately describes mutation semantics and the return value
• The requestContextFromRequest call is correctly placed after the potential request clone
• Both call sites (deploy.ts and prod-server.ts) destructure and reassign identically
• The generated worker entry correctly adds the import from vinext/config/config-matchers
• The index.ts dev server (line ~2797) isn't deduplicated, which is fine — it operates on Node.js IncomingMessage, not Web Request, so it wouldn't cleanly use this shared function

Review

Clean, well-scoped refactoring. All CI checks pass. Approving.

What it does

Extracts the duplicated x-middleware-request-* unpacking + x-middleware-* stripping logic from two inline call sites (deploy.ts and prod-server.ts) into a single applyMiddlewareRequestHeaders() in config-matchers.ts. Both call sites now destructure and reassign identically, and the test has been updated to assert the import + function call rather than the old inline implementation strings.

Notes

• The const → let change on webRequest in prod-server.ts is correct — needed because the shared function returns a (possibly new) Request rather than mutating in-place.
• The JSDoc accurately documents the mutation semantics on middlewareHeaders and the clone-on-write behavior for the Request.
• The two remaining inline copies (index.ts:2797 operating on Node IncomingMessage and app-dev-server.ts:1470 using a different applyMiddlewareRequestHeaders that operates on the RSC entry's generated code) aren't consolidatable with this shared function since they operate on different object types. The previous review correctly noted this.
• The updated test at tests/deploy.test.ts:550-557 now asserts "applyMiddlewareRequestHeaders" and "vinext/config/config-matchers" which validates the generated worker entry imports and calls the shared function. This is a better test — it verifies the integration contract rather than brittle implementation strings.

Review

Clean, correct refactoring. All 24 CI checks pass (one E2E still pending but unrelated). Approving.

Summary

Extracts the duplicated x-middleware-request-* unpacking + x-middleware-* stripping logic from two inline sites (deploy.ts and prod-server.ts) into a shared applyMiddlewareRequestHeaders() in config-matchers.ts. Both call sites now destructure identically.

Observations

Correctness: The shared function faithfully reproduces the old inline logic. The two-pass approach (collect into toApply, then clone-if-needed) is equivalent to the old deploy.ts code and strictly better than the old prod-server.ts code, which mutated headers in-place — the uniform clone-on-write via new Request(...) avoids assumptions about header mutability across runtimes.

const → let in prod-server.ts:792: Correct and necessary since webRequest is now reassigned from the shared function's return value.

Test update (deploy.test.ts:582-589): The new assertions (applyMiddlewareRequestHeaders and vinext/config/config-matchers) verify the integration contract — that the generated worker entry imports and calls the shared function — rather than asserting on brittle inline implementation strings. This is an improvement.

Non-consolidated copies are correct to leave alone: The inline copies in index.ts (operates on Node IncomingMessage) and app-dev-server.ts (generated RSC entry code as a string template) operate on different object types and can't cleanly use this shared Web Request-based function.

Note from PR comments: Author mentions waiting for PR #297 to merge then rebasing. No issues with the code as-is — the rebase should be mechanical.