## Background
Historically during prerendering we have waiting until all paths have
been attempted before we exit the process and fail the build. This is
nice if you want to collect all potential errors to address them at the
same time although this has the drawback of slowing down builds if
things are timing out or if the same error is occurring across numerous
paths.
## New Behavior
This changes our default behavior to immediately exit when the first
error occurs during prerendering so that builds don't stall out from
timeout errors or from the same error occurring across numerous paths.
This will help from holding up CI or similar un-necessarily.
If users want to opt-in to the previous behavior the flag is still
present under `experimental.prerenderEarlyExit`.
followup to: https://github.com/vercel/next.js/pull/60645
### Background
When prerendering the determination of whether a prerender is fully
static or partially static should not be directly related to whether
there is a postponed state or not. When rendering RSC it is possible to
postpone because a dynamic API was used but then on the client (SSR) the
postpone is never encountered. This can happen when a server component
is passed to a client component and the client component conditionally
renders the server component.
Today if this happens the entire output would be considered static when
in fact the flight data encoded into the page and used for bootstrapping
the client router contains dynamic holes. Today this is blocked by an
error that incorrectly assumes that this case means the user caught the
postpone in the client layer but as shown above this may not be the
case.
### Implementation
A more capable model is to think of the outcome of a prerender as having
3 possible states
1. Dynamic HTML: The HTML produces by the prerender has dynamic holes.
we save the static prelude but expect to resume the render later to
complete the HTML. This means we will resume the RSC part of the render
as well
2. Dynamic Data: The HTML is completely static but the RSC data encoded
into the page is dynamic. We don't want to resume the render but we do
need to produce new inlined RSC data during a Request.
3. Static: The HTML is completely static and so is the RSC data encoded
into the page. We save the entire HTML output and there will be no
dynamic continuation when this route is visited.
Really 1 & 3 are the same as today (Partially static & Fully Static
respectively) but case 2 which today errors in a confusing way is now
supported.
In addition implementing the Dynamic Data case the old warning about
catching postpones is removed. The reason we don't want this is that
catching postpones is potentially a valid way to do optimistic UI. We
probably want a first-party API for it at some point (and maybe we'll
add the warning back in once we do) but imagine you do something dynamic
like look up a user but during prerender you want to render as if the
user is logged out. you could call `getUser()` in a try catch and render
fallback UI if it throws. In this case we'd detect a dynamic API was
used but we wouldn't have a corresponding postpone state which would put
us in the Dynamic Data case (2).
Another item to note is that we can produce a fully static result even
if there is a postponed state because users may call postpone themselves
even if they are not calling dynamic APIs like headers or cookies. When
this happens we don't want to statically capture a page with postponed
boundaries in it. Instead we immediately resume the render and abort it
with a postponed abort signal. This will cause the boundaries to
immediately enter client render mode which should speed up recovery on
the client.
#### Technical Note
Another note about the implementation is that you'll see that regardless
of which case we are in, if there is a postponed state but we consider
the page to be Dynamic Data meaning we want to serialize all the HTML
and NOT do a resume in the dynamic continuation then we immediately
resume the render with and already aborted AbortSignal. The purpose here
is to mark any boundaries which have dynamic holes as being
client-rendered.
As a general rule if the render produces a postponed state we must do
one of the following
1. save the postponed state and ensure there is a dynamic continuation
that calls resume
2. immediately resume the render and save the concatenated output and
ensure the dynamic continuation does NOT call resume.
or said another way, every postponed state must be resumed (even if it
didn't come from Next's dynamic APIs)
#### Perf considerations
This PR modifies a few key areas to improve perf.
Reduces quantity of *Stream instances where possible as these add
significant overhead
Reduces extra closures to lower allocations and keep functions in
monomorphic form where possible
Closes NEXT-2164
### What
Given user infomation when the dynamic errors are thrown, e.g. bad
`cookies` or `headers` usages. Now users can tell through the error
information to see which pathname is broken, and trace down the usage.
#### before
```
Page couldn't be rendered statically because ...
This page needs to bail out of prerendering at this point because ...
```
#### after
```
Route /cookies couldn't be rendered statically because ...
Route /server needs to bail out of prerendering at this point because ...
```
### Why
When you have multi pages in your app, such as 100+, and many page might
uses these. This is hard to trace down where exactly the error is from
Closes NEXT-2283
Cloese NEXT-2265
## What?
Skips more tests that are running `next build` which is not supported by
Turbopack yet.
## How?
Used an approach where all `next build` tests would fail if
`TURBOPACK=1` is set, which is how the tests run. This highlighted the
cases `next build` was still running.
<!-- 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 #
-->
Closes NEXT-1791
Instead of requiring React in `maybePostpone` (which is susceptible to referencing the wrong version of React during build time, such as in the case where the static worker patches fetch within an app-route, which doesn't have an experimental runtime), this provides the postpone API to the `staticGenerationStore`. That way we know the API is available in render which is when we'd expect to postpone.
The "postpone" terminology is internal to React and can be used for more
things than just this. It's also a mechanism we may or may not rely on.
---------
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
When postpone is caught by user code, this will cause PPR not to properly prerender the static parts and thus we need to fail the build. This also adds some messaging about how to fix the error.
Prior to this change, catching code that would normally trigger `postpone ` would silently fail, but the build outputs would be incorrect as there's no postpone data available.
Relands #57477 with additional tests & fixes
Rather than sending a warning, we should fail the build if a postpone
call is caught. We should also fail the build if there are any errors
during static generation similar to the non-ppr case.
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
