Prior to this change any "hole" in a prerender that would block the
shell was considered an error and you would be presented with a very
generic message explaining all the different ways you could have failed
this validation check.
With this change we use a new technique to validate the static shell
which can now tell the difference between waiting on uncached data or
runtime data. It also improves the heuristics around generateMetadata
and generateViewport errors.
Added new error pages for runtime sync IO and ensure we only validate
sync IO after runtime data if the page will be validating runtime
prefetches.
Restored the validation on HMR update so you can get feedback after
saving a new file.
---
We've also discovered that hanging inputs are not handled correctly.
Fixing this is non-trivial and will be done in a follow-up, so for now,
we're disabling the failing tests.
---------
Co-authored-by: Josh Story <story@hey.com>
Co-authored-by: Hendrik Liebau <mail@hendrik-liebau.de>
## What?
Rename `experimental.dynamicIO` to `experimental.cacheComponents` across
the Next.js codebase.
## Why?
We're going to be merging the functionality of the `ppr`, `dynamicIO`
and `useCache` experimental flags into the singular `cacheComponents`
flag to reduce complexity of the codebase and simplify adoption for
users wanting to experiment with experimental features.
## How?
- Renamed the configuration option from `experimental.dynamicIO` to
`experimental.cacheComponents`
- Added deprecation handling with automatic migration for the old option
name
- Updated all documentation, tests, and internal references
- Updated Rust code in SWC transforms and Turbopack
- Maintained backward compatibility with deprecation warnings
NAR-158
stacked on #78575
When I changed the dynamic validation rules to be based on the existence
of a static shell I removed an important protection for apps that have
static metadata. Now that metadata is implicitly rendered within a
Suspense boundary it is always opted into allowing dynamic. For dynamic
and partially static pages this is fine because we are going to be
generating a response per request anyways. But if you have a fully
static page and then later accidentally make your metadata dynamic your
page will deopt to partially static without any warning.
This change reintroduces the heuristic where if the only dynamic thing
on the page is metadata the build errors. If there is at least one other
dynamic thing on the page then dynamic metadata is allowed.
A similar change is not necessary for viewport because that is never
rendered in a Suspense boundary and the only way to have dynamic
viewports is to opt the entire app into dynamic with a Suspense boundary
around your root layout
Joseph