feat(middleware)!: forbid response body

[feugy]

What's in there?

As part of the Edge Functions General Availability roadmap, it has been decided to only support the following uses cases in Next.js' middleware:

• rewrite the URL (x-middleware-rewrite response header)
• redirect to another URL (Location response header)
• pass on to the next piece in the request pipeline (x-middleware-next response header)

1. during development, a warning on console tells developers when they are returning a response (either with Response or NextResponse).
2. at build time, this warning becomes an error.
3. at run time, returning a response body will trigger a 500 HTTP error with a JSON payload containing the detailed error.

All returned/thrown errors contain a link to the documentation.

This is a breaking feature compared to the beta middleware implementation.
It also removes NextResponse.json().

How to try it?

The new error is covered with:

• integration tests:
  • runtime behavior: HEADLESS=true yarn jest test/integration/middleware/core
  • build behavior : HEADLESS=true yarn jest test/integration/middleware/build-errors
  • development behavior: HEADLESS=true yarn jest test/development/middleware-warnings

Notes to reviewers

The limitation happens in next's web adapter. The initial implementation was to check response.body existence, but it turns out Response.redirect() may return an empty stream. Hence why the proposed implementation specifically looks at response headers.

Because this is a breaking change, I had to adjust several tests cases, previously returning JSON/stream/text bodies. When relevant, these middlewares are returning data using response headers.

About DevEx: relying on AST analysis to detect forbidden use cases is not as good as running the code.
Such cases are easy to detect:

new Response('a text value')
new Response(JSON.stringify({ /* whatever */ })

But these are false-positive cases:

function returnNull() { return null }
new Response(returnNull())

function doesNothing() {}
new Response(doesNothing())

However, I see no good reasons to let user build an middleware with the cases above, hence why the build will fail, even if technically speaking, they are not setting the response body.

[feugy]

Closing in favor of vercel#36835