## For Contributors
I know it's an unstable api but this just makes it easier to test with.
This uses the type of the callback to `unstable_cache` as the return
type of `unstable_cache`.
See https://github.com/vercel/turbo/pull/4776
This adds support for:
* Default and custom global app 404 pages (`app/not-found`).
* Segment-level 404 pages (`app/segment/not-found`).
This also updates Turbopack:
* https://github.com/vercel/turbo/pull/4787 <!-- Tobias Koppers -
Bugfixes for free var and binding replacement -->
* https://github.com/vercel/turbo/pull/4789 <!-- Alex Kirszenberg -
Print a warning when importing Sass files -->
* https://github.com/vercel/turbo/pull/4776 <!-- Alex Kirszenberg -
Leave pathname formatting up to the caller -->
* https://github.com/vercel/turbo/pull/4790 <!-- Tobias Koppers - remove
inital compilation message by default -->
## TODO:
- [ ] ~~The dev overlay shows up when `notFound()` is called, it should
be hidden~~ (moved to WEB-980)
- [ ] ~~Navigating to the global 404 page doesn't work~~ (this is a bug
in Next.js, see NEXT-963)
- [x] Tests.
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
There was a bug reported in https://github.com/vercel/next.js/issues/42991#issuecomment-1532967037 that would hang on load.
After investigation, I noticed that it was because the cache node never applied the flight payload. It was because the requested flight payload was too deep into the tree whereas it should have been fetched from higher up in the tree because we specifically discarded that branch of the tree because it was stale.
When using the `not-found.js` file to match missed routes, `serverCSSForEntries` will always be empty as the `ComponentMod.pages` itself doesn't contain any actual entry. We need to handle that as a special case.
Closes#48133.
For edge runtime, we're modifying `res.statusCode` in actions handler, but we didn't forward the `res` object to it, previously we're using a fake `res` `{}`. This PR fixes it so that the propery status code will be returned to the client
[slack-thread](https://vercel.slack.com/archives/C052S77L05C/p1682988777740609)
This PR changes the router behaviour during prefetching.
- before: the router would prefetch the router tree + return the loading state of new router node if there were any
- after: the router will prefetch the router tree + prefetch the content of the new page up until the nearest loading boundaries
Example:
Note: `prefetched` here implies React content prefetching
```
.
└── app/
├── page.ts <- the page you're on, has links to /about and /post/[id]
├── layout.ts
├── post/
│ └── [id]/
│ ├── (comments)/
│ │ ├── loading.ts <- not prefetched
│ │ └── page.ts <- not prefetched
│ ├── layout.ts
│ └── page.ts <- not prefetched
└── about/
└── page.ts <- not prefetched
```
After
```
.
└── app/
├── page.ts <- the page you're on, has links to /about and /post/[id]
├── layout.ts
├── post/
│ └── [id]/
│ ├── (comments)/
│ │ ├── loading.ts <- prefetched
│ │ └── page.ts <- not prefetched
│ ├── layout.ts
│ └── page.ts <- prefetched
└── about/
└── page.ts <- prefetched
```
link NEXT-1078
### What?
Make it possible to pass `headers()` where the `Headers` type is
expected. An example would be `fetch`:
```ts
import { headers } from "next/headers"
// ...
fetch("https://example.com", {
headers: headers()
})
```
### Why?
`ReadonlyHeaders` _currently omits_ some mutating methods which make
sense since they don't make sense. 🙃. However, it makes
it necessary to pass the result anywhere where `Headers` is expected.
Since we already throw errors when these methods are called illegally,
we can make the type constraint a bit looser to avoid `as any` or
`Object.fromEntries(headers())` or similar.
### How?
Mark the unavailable methods as `@deprecated` which will visually mark
them in IDEs:
Closes NEXT-1075
## What?
Removes writing the `.vscode/settings.json` config. This config is
needed in order to leverage the new Next.js TypeScript plugin.
What we'll do instead is add a message in the docs on how to enable it.
We'll also explore a VSCode extension that warns when you don't have the
TypeScript plugin set up.
## How?
Removed the code related to writing `.vscode`.
Closes#42213
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation or adding/fixing Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
Follow up of #48867
- Statically optimize dynamic generated sitemap routes
- Previously the generated sitemap urls looks bit off
(`/route/sitemap.xml/[id]`), we polish it into `/route/sitemap/[id].xml`
in this PR
Not 100% convinced that this is the correct fix but it's the best I can
think of.
Previously, we would sometimes call location.assign()/.replace()
hundreds of times (or more) as I described in
https://github.com/vercel/next.js/issues/48438 and
https://github.com/vercel/next.js/issues/48309#issuecomment-1512290958.
Sometimes this would just make things slow but the navigation would
eventually succeed; sometimes this would just hang the browser.
Now we trigger it only once (or—for a reason I don't quite
understand—twice in dev, as you can see in the test) and never commit
that render.
This also fixes the bug I mentioned in
https://github.com/vercel/next.js/issues/48438#issuecomment-1528649776
where usePathname() and useSearchParams() would return the page we are
navigating to (even if that's an external page wholly unrelated to our
site!).
Fixes#48309, fixes#48438.
link NEXT-1028
Co-authored-by: Jimmy Lai <laijimmy0@gmail.com>
Currently we invoke the revalidate request directly in the current
server when `res.revalidate()` is called. However app needs to be
rendered in a separate worker so this results in an error of React. This
PR fixes it by sending the request via IPC so the main process will
delegate that to the correct render worker.
Closes#48948.
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
This ensures we properly handle edge runtime during build when loading pages as currently we are only check the page itself for the runtime flag although it can be nested higher up but we already have the relevant info in the middleware-manifest so we can use that during build.
Fixes:
```sh
info - Linting and checking validity of types
info - Collecting page data ..ReferenceError: self is not defined
at Object.<anonymous> (/Users/jj/dev/vercel/next.js/test/e2e/app-dir/app-edge/.next/server/app/edge/basic/page.js:1:1)
at Module._compile (node:internal/modules/cjs/loader:1254:14)
at Module._extensions..js (node:internal/modules/cjs/loader:1308:10)
at Module.load (node:internal/modules/cjs/loader:1117:32)
at Module._load (node:internal/modules/cjs/loader:958:12)
at Module.require (node:internal/modules/cjs/loader:1141:19)
at require (node:internal/modules/cjs/helpers:110:18)
at requirePage (/Users/jj/dev/vercel/next.js/packages/next/src/server/require.ts:126:10)
at <anonymous> (/Users/jj/dev/vercel/next.js/packages/next/src/server/load-components.ts:105:16)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
> Build error occurred
Error: Failed to collect page data for /edge/basic
```
* For sitemap if they're not using dynamic routes generation `generateSitemaps`, should optimize them as static sitemap
* For icons and social images, if they're not using `generateImageMetadata`, should optimize them as static path
Closes NEXT-1071
Fixes#48991
The `WebSocket` constructor exposed by `undici` is not working against some db connections.
That can be considered kind of expected since `undici` docs is saying it's experimental.
We're working into isolate the issue and report at `undici` repository, but for now, let's just use `ws` for all the node versions.
This PR:
* Adds more config keys that should be supported or can be ignored
* Cleans up supported key checking and allows nested keys that aren't experimental
* Removes logging for "only supported options" since the list is much longer now
## What?
Changes the logic for running node-file-trace to no longer rely on
parsing the webpack request. Instead using the module metadata set in
each loader to generate the path.
## How?
The `route` metadata is already provided on all entry loaders since I
added `preferredRegion` support, this can now leverage `route` as well
to generate the required path.
<!-- Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change(s) that you're making:
## For Contributors
### Improving Documentation or adding/fixing Examples
- The "examples guidelines" are followed from our contributing doc
https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md
- Make sure the linting passes by running `pnpm build && pnpm lint`. See
https://github.com/vercel/next.js/blob/canary/contributing/repository/linting.md
### Fixing a bug
- Related issues linked using `fixes #number`
- Tests added. See:
https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
### Adding a feature
- Implements an existing feature request or RFC. Make sure the feature
request has been accepted for implementation before opening a PR. (A
discussion must be opened, see
https://github.com/vercel/next.js/discussions/new?category=ideas)
- Related issues/discussions are linked using `fixes #number`
- e2e tests added
(https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs
- Documentation added
- Telemetry added. In case of a feature if it's used or not.
- Errors have a helpful link attached, see
https://github.com/vercel/next.js/blob/canary/contributing.md
## For Maintainers
- Minimal description (aim for explaining to someone not on the team to
understand the PR)
- When linking to a Slack thread, you might want to share details of the
conclusion
- Link both the Linear (Fixes NEXT-xxx) and the GitHub issues
- Add review comments if necessary to explain to the reviewer the logic
behind a change
### What?
### Why?
### How?
Closes NEXT-
Fixes #
-->
### What?
allows to change blur mode for structured images
also improve performance for static metadata images in app dir by avoiding computing blur placeholder
### Why?
we might want to change the blur mode (in dicussion)
### How?
adds an enum to control the mode
