bf089562c7
_Hello Next.js team! First PR here, I hope I've followed the right practices._ ### What's in there? 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, and also removes `NextResponse.json()` which makes no sense any more. ### How to try it? - runtime behavior: `HEADLESS=true yarn jest test/integration/middleware/core` - build behavior : `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()`](https://github.com/vercel/next.js/blob/canary/packages/next/server/web/spec-compliant/response.ts#L42-L53) may set the response body (https://github.com/vercel/next.js/pull/31886). Hence why the proposed implementation specifically looks at response headers.~ `Response.redirect()` and `NextResponse.redirect()` do not need to include the final location in their body: it is handled by next server https://github.com/vercel/next.js/blob/canary/packages/next/server/next-server.ts#L1142 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: ```js new Response('a text value') new Response(JSON.stringify({ /* whatever */ }) ``` But these are false-positive cases: ```js function returnNull() { return null } new Response(returnNull()) function doesNothing() {} new Response(doesNothing()) ``` However, I see no good reasons to let users ship middleware such as the one above, hence why the build will fail, even if _technically speaking_, they are not setting the response body. ## Feature - [x] Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. - [ ] Related issues linked using `fixes #number` - [x] Integration tests added - [x] Documentation added - [ ] Telemetry added. In case of a feature if it's used or not. - [x] Errors have helpful link attached, see `contributing.md` ## Documentation / Examples - [x] Make sure the linting passes by running `yarn lint`
80 lines
1.9 KiB
TypeScript
80 lines
1.9 KiB
TypeScript
import type { I18NConfig } from '../../config-shared'
|
|
import { NextURL } from '../next-url'
|
|
import { toNodeHeaders, validateURL } from '../utils'
|
|
|
|
import { NextCookies } from './cookies'
|
|
|
|
const INTERNALS = Symbol('internal response')
|
|
const REDIRECTS = new Set([301, 302, 303, 307, 308])
|
|
|
|
export class NextResponse extends Response {
|
|
[INTERNALS]: {
|
|
cookies: NextCookies
|
|
url?: NextURL
|
|
}
|
|
|
|
constructor(body?: BodyInit | null, init: ResponseInit = {}) {
|
|
super(body, init)
|
|
|
|
this[INTERNALS] = {
|
|
cookies: new NextCookies(this),
|
|
url: init.url
|
|
? new NextURL(init.url, {
|
|
basePath: init.nextConfig?.basePath,
|
|
i18n: init.nextConfig?.i18n,
|
|
trailingSlash: init.nextConfig?.trailingSlash,
|
|
headers: toNodeHeaders(this.headers),
|
|
})
|
|
: undefined,
|
|
}
|
|
}
|
|
|
|
public get cookies() {
|
|
return this[INTERNALS].cookies
|
|
}
|
|
|
|
static json(body: any, init?: ResponseInit) {
|
|
const { headers, ...responseInit } = init || {}
|
|
return new NextResponse(JSON.stringify(body), {
|
|
...responseInit,
|
|
headers: {
|
|
...headers,
|
|
'content-type': 'application/json',
|
|
},
|
|
})
|
|
}
|
|
|
|
static redirect(url: string | NextURL | URL, status = 307) {
|
|
if (!REDIRECTS.has(status)) {
|
|
throw new RangeError(
|
|
'Failed to execute "redirect" on "response": Invalid status code'
|
|
)
|
|
}
|
|
|
|
return new NextResponse(null, {
|
|
headers: { Location: validateURL(url) },
|
|
status,
|
|
})
|
|
}
|
|
|
|
static rewrite(destination: string | NextURL | URL) {
|
|
return new NextResponse(null, {
|
|
headers: { 'x-middleware-rewrite': validateURL(destination) },
|
|
})
|
|
}
|
|
|
|
static next() {
|
|
return new NextResponse(null, {
|
|
headers: { 'x-middleware-next': '1' },
|
|
})
|
|
}
|
|
}
|
|
|
|
interface ResponseInit extends globalThis.ResponseInit {
|
|
nextConfig?: {
|
|
basePath?: string
|
|
i18n?: I18NConfig
|
|
trailingSlash?: boolean
|
|
}
|
|
url?: string
|
|
}
|