This PR tries to address some feedback around prefetching, like in #49607, where they were some warnings because we were over prefetching.
The tweaks in this PR:
- if there are no loading boundary below, we don't prefetch the full page anymore. I made that change a while ago but I think it wasn't the original intent from @sebmarkbage. Fixing that now. So now, we will prefetch the page content until the nearest loading boundary, only if there is any.
- there's now a queue for limiting the number of concurrent prefetches. This is to not ruin the bandwidth for complex pages. Thanks @alvarlagerlof for that one.
- also, if the prefetch is in the queue when navigating, it will get bumped.
- bonus: fixes a bug where we were wrongly stripping headers in dev for static pages
Test plan:
<img width="976" alt="CleanShot 2023-07-20 at 17 53 43@2x" src="https://github.com/vercel/next.js/assets/11064311/2ea34419-c002-4aea-94df-57576e3ecb2e">
In the screenshot you can see that:
- only 5 requests at a time are authorised
- when I clicked on 15, it got prioritised in the queue (did not cancel the rest)
- the prefetch only included the content until the loading boundary
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
### What
This PR changes the flow of not-found rendering process.
### Why
`not-found.js` was rendered in two ways before:
* 1 is SSR rendering the not-found as 404
* 2 is triggering the error on RSC rendering then the error will be
preserved in inline flight data, on the client it will recover the error
and trigger the proper error boundary.
The solution has been through a jounery:
No top-level not found boundary -> introduce metadata API -> then we
create a top level root not found boundary -> then we delete it due to
duplicated rendering of root layout -> now this
So the solution before this PR is still having a root not found boundary
wrapped in the `AppRouter`, it's being used in a lot of places including
HMR. As we discovered it's doing duplicated rendering of root layout,
then we removed it and it started failing with rendering `not-found` but
missing root layout. In this PR we redesign the process.
### How
Now the rendering architecture looks like:
* For normal root not-found and certain level of not-found boundary
they're still covered by `LayoutRouter`
* For other error renderings including not-found
* Fully remove the top level not-found boundary, when it renders with
404 error it goes to render the fallback page
* During rendering the fallback page it will check if it should just
renders a 404 error page or render nothing and let the error from inline
flight data to trigger the error boundary
pseudo code
```
try {
render AppRouter > PageComponent
} catch (err) {
create ErrorComponent by determine err
render AppRouter > ErrorComponent
}
```
In this way if the error is thrown from top-level like the page itself
or even from metadata, we can still catch them and render the proper
error page based on the error type.
The problematic is the HMR: introduces a new development mode meta tag
`<meta name="next-error">` to indicate it's 404 so that we don't do
refresh. This reverts the change brougt in #51637 as it will also has
the duplicated rendering problem for root layout if it's included in the
top level not found boundary.
Also fixes the root layout missing issue:
Fixes#52718Fixes#52739
---------
Co-authored-by: Shu Ding <g@shud.in>
### What and why?
The word "publicly" should be spelled consistently across the documentation. It is spelled currently as "publically" in a few places.
### How?
Fixed the spelling!
We have the logic to group the client compiler's entry names to make sure we generate one single manifest file for the page. This is complicated and requires a special step to "group" the entry names because a page can depend on a bunch of files from everywhere.
And currently, the normalization of "entryName → groupName" doesn't cover interception routes' conventions (`(.)`, `(..)` and `(...)`). This PR fixes that.
Closes#52862, closes#52681, closes#52958.
### What?
Stop `with-supabase` template from throwing errors on build
### Why?
Dynamic Routes now fail the build, rather than console.logging an error
### How?
Export the following from any routes that use the `cookies` function
```
export const dynamic = "force-dynamic";
```
Install `encoding` as a dev dependency until this is fixed downstream
The correct filename is seen on PagesOnly. But on AppOnly, the filename is not correct. It should be "hello" instead of "ClientComponent".
line to change:
from:
import('../components/ClientComponent').then((mod) => mod.Hello)
to:
import('../components/hello').then((mod) => mod.Hello)
line to change:
from:
import('../components/ClientComponent').then((mod) => mod.Hello)
to:
import('../components/hello').then((mod) => mod.Hello)
### What?
- Visiting a page in the app router without a proper component export doesn't show the dev overlay, but logs errors to the console
- When it does show the error overlay (e.g. during an HMR event), the error message was sharing the module code itself rather than the component path, making it hard to debug
### Why?
`createComponentTree` can throw these errors before the AppRouter tree is mounted, leaving the errors uncaught by the dev overlay.
### How?
This wraps the server root in the `ReactDevOverlay` when in dev mode with a minimal "HMR" for when the server component is edited (to reload the page).
Closes NEXT-308
### What?
* adds `Project.update` to update project options
* fix manifest paths to be under `server`
* pass `env` into project
* handle and expose issues in all methods
* expose server paths in WrittenEndpoint
As we're using nodejs with latest version of 18.x on CI, there's a new behavior change of `url.fileURLToPath` that didn't join the paths as expected
locally with node 16.x or 18.16
```
/private/var/folders/mh/y8kwzkls6v3_w3_k6q384cw80000gn/T/next-install-b033b516612809c6fb0a0de77c6e50f7d7f8af34dfd3d01812b99345352dc992/node_modules/.pnpm/file+..+next-repo-7e52b07043e986127273a2d951e5c412b0dd45fb24eb34001bd372e2afff79db+packages+n_vyqu6i4c4i3efp5pqsaeaoe5s4/node_modules/next/dist/compiled/@vercel/og/noto-sans-v27-latin-regular.ttf
```
in the actions runner with node 18.17 it's
```
/tmp/next-install-8efaa47c1546bed07990d8f130decceb6536e1a36146e7885cb68e3c3dea21f7/node_modules/.pnpm/file+..+next-repo-9679355e05341947e7aa0b42c994e3ac_krcuriy4thl7zawouf7sswlrgy/node_modules/next/dist/compiled/@vercel/og/index.node.js/../noto-sans-v27-latin-regular.ttf
```
You can see that `index.node.js` is still present in the path as a folder which is unexpected
```
index.node.js/../
```
x-ref: https://github.com/vercel/next.js/actions/runs/5600417148/jobs/10242827739?pr=52790
Added clarification that runtime edge can be defined on Layout level too.
Co-authored-by: Steven <229881+styfle@users.noreply.github.com>
Co-authored-by: Balázs Orbán <18369201+balazsorban44@users.noreply.github.com>
This pull request replaces `readdir` with `opendir` and simplifies the
implementation.
Co-authored-by: Steven <steven@ceriously.com>
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
Renames the webpack layers to be more semantical:
```
server compiler:
server layer → RSC layer
client layer → SSR layer
shared layer → shared layer
client compiler:
appClient layer → app browser layer
```
### What?
Minor update to next-swc to support `__INTERNAL_CUSTOM_TURBOPACK_BINDINGS` for the --experimental-turbo entrypoint as same as current --turbo.
This updates our `moduleResolution` to `bundler` as this matches our heuristics much more closely so is more accurate. This shouldn't be a breaking change is it should be compatible with our previous default.
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
### What?
While examining Next.js, I noticed unnecessary 'await' statements and
removed them.
### How?
I have removed the 'await' statements.
Is it acceptable to submit such minor modifications?
Then, please review it. Thank you.
Co-authored-by: 원건우 <wongeon-u@wongunwoo.local>
Co-authored-by: Steven <steven@ceriously.com>
The following files have been modified.
- `docs/02-app/01-building-your-application/05-optimizing/04-metadata.mdx`
programatically -> programmatically
- `docs/02-app/02-api-reference/04-functions/image-response.mdx`
ImageReponse -> ImageResponse
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
- Adds `next-router-worker` as the process title for the routing worker.
- Adds `next-render-worker-app` as the process title for the rendering
worker for `app`
- Adds `next-render-worker-pages` as the process title for the rendering
worker for `pages`
Currently it's hard to find these processes in e.g. activity monitor,
this helps explain what they are used for when someone is looking at the
running processes.
<!-- 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
- Run `pnpm prettier-fix` to fix formatting issues before opening the
PR.
- Read the Docs Contribution Guide to ensure your contribution follows
the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
### Adding or Updating 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 #
-->
When doing dynamic imports like `import(variable)`, Webpack _tries_ to statically analyze it and creates a regex like context module for it (which includes all possible modules). This `ContextModule` doesn't have a resource path so we need to use the identifier to track it.
Tested with @alexkirsz's repro here https://github.com/vercel/next.js/issues/50243#issuecomment-1628675346 and confirmed that it fixes the problem.
Closes#50243.