Log how long it takes to evaluate next.configs
Sometimes it is very slow this can help users understand at least that
it is due to their config
Example dev log
```
running pnpm next --turbopack────────────────────────────────────────────────────────────────╯
▲ Next.js 16.3.0-canary.52 (Turbopack)
- Local: http://localhost:61086
- Network: http://10.103.12.203:61086
✓ Ready in 272ms
✓ Running next.config.js took 13ms
```
Example build log
```
✓ Running next.config.js took 10ms
▲ Next.js 16.3.0-canary.52 (Turbopack)
- Experiments (use with caution):
✓ mdxRs
⚠ The "middleware" file convention is deprecated. Please use "proxy" instead.
To migrate automatically, run:
npx @next/codemod@canary middleware-to-proxy .
Learn more: https://nextjs.org/docs/messages/middleware-to-proxy
Creating an optimized production build ...
```
A few things to discuss
* the bundler logging is incorrect in dev! If you use the `withRspack`
plugin it will change the bundler to rspack but the next.js version
string was already printed!
* we eval config before printing the version in build but afterwards in
dev so the evaluation timing line is a little surprising
* this demonstrates that we do evaluate the config after 'Ready in' in
dev, fine but maybe confusing for people?
In production, when throwing an error in `'use cache'` at runtime, we
are currently logging the obfuscated error that React is producing when
crossing the cache-server boundary. This is not ideal for investigating
production issues so we're also logging the original error in the `'use
cache'` wrapper as a work-around. But this error does not have a digest,
which makes it non-obvious that it's the same error as the obfuscated
one.
With this PR we are fixing this by storing the original error (with a
digest) in the `reactServerErrorsByDigest` map (moved to the work
store), and retrieving it in the server environment when we log the
error. Thus the obfuscated error is not logged, and the original error
with a digest is logged instead.
In development, we keep the existing behavior of logging the transported
error, which also includes the dev-only `environmentName` property
`'Cache'`.
As part of this fix, we're consolidating the
`createFlightReactServerErrorHandler` and
`createHTMLReactServerErrorHandler` functions, which had a big overlap
and confusing names, into a single `createReactServerErrorHandler`
function.
closes NAR-536
In production, when throwing an error in `'use cache'` at runtime, we are currently logging the obfuscated error that React is producing when crossing the cache-server boundary. This is not ideal for investigating production issues so we're also logging the original error in the `'use cache'` wrapper. But this error does not have a digest, which makes it non-obvious that it's the same error as the obfuscated one.
This PR is just adding a test fixture for this case, so that we can see the changes when improving the error handling in the upstack PR.
Currently we only abort React renders that are prerendered so this
change in practice only affects prerendering. The intent is to not
report unhandledRejections that are downstream of an abort because the
signal these errors provide is very limited. If you do have unrelated
unhandled rejections they'll usually show up before aborting or in a
dynamic page render so even if they are incidentally supressed in the
prerender context you should still be able to observe them.
Arguably we should go further and never report unhandled rejections
because there are still valid patterns where you initiate work
prospectively and then abandon it by choosing a fork or by returning
early (i.e. notFound()). This change doesn't attempt to cover every
possible case.
The implementation is a bit intense. We need the ability to stop
propagating the event which is not natively supported with Node's
EventEmitter interface. Instead we patch the listener methods to
delegate the filtering to an inner listener queue. If you add/remove or
otherwise manipulate the listener list we always ensure our listener is
first and can opt to omit propagating the event. If you want to
uninstall the this patch you just need to unregister this listener
specifically which can be accessing used
`process.listeners('unhandledRejection')[0]`
This patch only exists for the node environment because we do not do any
prerendering in edge runtimes. In the future if we add aborting to
environments like edge runtime we may need an alternative solution to
this problem
In #81162 we removed the support for accessing request data
synchronously when `experimental.cacheComponents` is enabled. However,
we missed updating the `cookies()` and `headers()` promises that are
created at runtime to not be "exotic" promises, i.e. promises that also
have the cookies/headers methods defined on them. Those two cases are
now updated as well with this PR. (Params, search params, and draft mode
were already handled correctly in the original PR.)
In the next major version we'll remove the support for the legacy
synchronous access independent of the `cacheComponents` flag.
## 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
Luke Sandberg