2016-10-25 20:44:56 +02:00
|
|
|
# build output
|
2016-10-06 01:52:50 +02:00
|
|
|
dist
|
2017-02-16 23:55:28 +01:00
|
|
|
.next
|
2021-07-27 17:07:28 +02:00
|
|
|
target
|
2022-06-26 05:53:54 +02:00
|
|
|
packages/next/wasm/@next
|
2023-01-18 20:35:28 +01:00
|
|
|
packages/*/packed-*.tgz
|
2016-10-25 20:44:56 +02:00
|
|
|
|
|
|
|
|
# dependencies
|
|
|
|
|
node_modules
|
2017-07-23 19:51:12 +02:00
|
|
|
package-lock.json
|
2018-09-02 15:17:37 +02:00
|
|
|
yarn.lock
|
2018-12-13 16:56:48 +01:00
|
|
|
!/yarn.lock
|
2018-01-31 08:35:10 +01:00
|
|
|
test/node_modules
|
2022-11-25 11:24:56 +01:00
|
|
|
.pnpm-store/
|
2016-10-25 20:44:56 +02:00
|
|
|
|
2018-02-27 13:16:17 +01:00
|
|
|
# logs & pids
|
2017-05-10 01:24:34 +02:00
|
|
|
*.log
|
2018-02-27 13:16:17 +01:00
|
|
|
pids
|
2021-11-25 18:41:20 +01:00
|
|
|
*.cpuprofile
|
2016-10-25 20:44:56 +02:00
|
|
|
|
2016-11-15 09:24:20 +01:00
|
|
|
# coverage
|
|
|
|
|
.nyc_output
|
|
|
|
|
coverage
|
2017-04-06 12:09:26 +02:00
|
|
|
|
2017-05-09 23:03:20 +02:00
|
|
|
# test output
|
2019-03-29 16:05:53 +01:00
|
|
|
test/**/out*
|
2019-07-11 19:35:39 +02:00
|
|
|
test/**/next-env.d.ts
|
2017-04-06 12:09:26 +02:00
|
|
|
.DS_Store
|
2020-08-17 19:39:57 +02:00
|
|
|
/e2e-tests
|
2021-09-29 19:38:21 +02:00
|
|
|
test/tmp/**
|
2022-12-16 09:58:04 +01:00
|
|
|
test/.trace
|
2023-01-18 20:35:28 +01:00
|
|
|
test/traces
|
2018-11-13 11:05:58 +01:00
|
|
|
|
|
|
|
|
# Editors
|
|
|
|
|
**/.idea
|
2020-12-29 17:12:36 +01:00
|
|
|
**/.#*
|
feat(middleware)!: forbids middleware response body (#36835)
_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`
2022-05-20 00:02:20 +02:00
|
|
|
.nvmrc
|
2019-03-27 01:42:49 +01:00
|
|
|
|
2020-05-19 11:11:14 +02:00
|
|
|
# examples
|
2019-03-27 01:42:49 +01:00
|
|
|
examples/**/out
|
2020-05-19 11:11:14 +02:00
|
|
|
examples/**/.env*.local
|
2019-03-29 16:05:53 +01:00
|
|
|
|
2020-05-21 14:07:27 +02:00
|
|
|
pr-stats.md
|
2020-11-09 06:56:39 +01:00
|
|
|
test-timings.json
|
2020-05-31 22:53:08 +02:00
|
|
|
|
|
|
|
|
# Vercel
|
|
|
|
|
.vercel
|
|
|
|
|
.now
|
2021-10-29 19:57:55 +02:00
|
|
|
|
|
|
|
|
# Cache
|
2021-11-25 18:41:20 +01:00
|
|
|
*.tsbuildinfo
|
2022-12-10 18:35:13 +01:00
|
|
|
.swc/
|
2023-01-18 20:35:28 +01:00
|
|
|
.turbo
|
