This reverts the below changes to avoid a breaking change in pages with
importing `react-dom/server` as this is disallowed in `app` but
shouldn't be in `pages`.
Revert "Bundle the installed react for middleware (#65811)"
Revert "Error in build for middleware when import client-only (#65792)"
This reverts commit fdd8f0c65f.
This reverts commit 082072ca95.
x-ref: [slack
thread](https://vercel.slack.com/archives/C03S8ED1DKM/p1716305493514869)
Since, https://github.com/vercel/next.js/pull/65830, I've been seeing
weird flakes from
`test/e2e/app-dir/app-invalid-revalidate/app-invalid-revalidate.test.ts`.
```
TIMED OUT: /Invalid revalidate value "1" on "\/", must be a non-negative number or "false"/
```
The build output looks like this:
```
▲ Next.js 14.3.0-canary.73
Creating an optimized production build ...
[snip]
Error: Invalid revalidate value "1" on "/_not-found", must be a non-negative number or "false"
[snip]
Generating static pages (2/4)
> Build error occurred
Error: Export encountered an error on /_not-found, exiting due to prerenderEarlyExit: true being set
```
Note that there's no `Invalid revalidate value "1"` message for `/`, so
the test will fail.
This looks like a race condition: the invalid `revalidate` value is set
in a layout, so if `_not-found` happens to be prerendered before `/`,
it'll abort the whole prerender (because of `prerenderEarlyExit: true`).
so if the timing is right, the test -- which is looking for build errors
for `/` -- will never see them and time out.
There might be more of these, but unfortunately they're basically race
conditions, so I think we'll have to squash them as they come up.
CC @ijjk
## Background
Currently route handlers will be attempted to statically generate the
same as normal pages in app router. If a route handler accessed dynamic
data such as `cookies()`, `headers()`, `req.url`, or similar we would
bail from this static generation but this didn't handle the case where
you would do data fetching via a non-fetch based library e.g. `redis` or
even using `Date.now()` or `Math.random()` so users would expect these
to be run every request like normal API endpoints but they would be
static so wouldn't be executed again after a build.
## New Behavior
As discussed this disable the default static generation handling for
route handlers as we've seen this confuse our users since in most cases
when creating a route handler you are handling dynamic workloads. This
doesn't remove the ability to static generate route handlers though as
you can still manually specify:
If you specify `export const revalidate = 1` we will still bail if
dynamic data is accessed to prevent accidental `revalidate` configuring
but this can be avoided via `force-static` being used as well.
```js
export const dynamic = 'force-static'
// or
export const dynamic = 'error'
// or
export const revalidate = false
// or
export const revalidate = 1 // value great than 0
// or
export const generateStaticParams() {}
```
---------
Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
Currently `OPTIONS` requests to page handlers (eg `pages/foo.tsx` or
`app/foo/page.tsx`) will respond as though it's handling a `GET`
request. There should be no reason for these routes to handle `OPTIONS`
requests as the only valid option is `GET`.
We do not need to special-case actions here because those will always be
invoked from the same origin as the canonical browser URL.
<!-- 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-3305
## 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`.
cc @icyJoseph @ztanner
NOTE: The canary release
[`v14.1.1-canary.51`](https://github.com/vercel/next.js/releases/tag/v14.1.1-canary.51)
and below work as expected.
### Why?
Introduced from #61535, the initial prefetch cache is set based on the
`location.pathname`.
When a page is loaded WITH the search param, the cache key does not
contain information of the search param.
The issue is when on a dynamic page reading the `searchParams` value,
the value doesn't change if navigated as:
```
/?q=foo --> /
```
The prefetch cache hits, not re-rendering, and the `searchParams` value
is not passed properly.
### How?
For the prefetch cache, add the `location.search` as well.
Since `createPrefetchCacheKey` uses
[`createHrefFromUrl`](https://github.com/vercel/next.js/blob/canary/packages/next/src/client/components/router-reducer/create-href-from-url.ts)
which includes `location.search`, I'm expecting the change won't affect
current cache key behavior.
Fixes#64170Fixes#65030
---------
Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
Adds support for nested `unstable_after()`.
This pattern previously threw a "Not supported yet" error, but works
now:
```js
function MyComponent() {
after(() => asyncWork());
return <div>...</div>
}
async function asyncWork() {
after(() => { /* look ma, nesting!*/ })
// more stuff...
}
```
### Implementation notes
Switched `AfterContext` to use a proper promise queue
([`p-queue`](https://www.npmjs.com/package/p-queue)) instead of plain a
callback array to support adding more callbacks as we execute (i.e. from
nested `after`s). Used a package because I didn't want to reinvent the
wheel here.
As a nice bonus, `p-queue` lets us limit the concurrency of running
tasks if we're worried about resource consumption. **This PR doesn't do
that**, but it's very easy to add. That could be controlled via
`process.env.NEXT_AFTER_MAX_CONCURRENT_TASKS`, a next.config.js option
(`unstable_after: { maxConcurrentTasks: 5 }`), or something like that.
Implements `unstable_after`, which lets the user schedule work to be
executed after the response is finished.
### Implementation notes
- `unstable_after()` is a dynamic function (bypassable only with `export
dynamic = "force-static"`)
- Usable in: server components (including `generateMetadata`), actions,
route handlers, middleware
- It is meant to run its callbacks even if a response didn't complete
successfully (thrown error) or called `notFound()`/`redirect()`
- Currently gated behind a `experimental.after` feature flag, because it
touches many runtime bits (including a React monkeypatch...)
- The state for `unstable_after()` in a given request lives in
`requestAsyncStorage` (added via `RequestAsyncStorageWrapper`)
- the implementation is based around two functions that we inject via
`renderOpts`:
- `waitUntil(promise)` - keep a function invocation alive until a
promise settles. it is provided as a platform primitive in serverless
contexts, and a noop in `next start`
- for serverless (nodejs), Next.js will attempt to get `waitUntil` from
`globalThis[Symbol.for('@next/request-context')].get().waitUntil`. This
should be considered unstable for now. See
`packages/next/src/server/after/wait-until-builtin.ts` for details.
- `onClose(callback)` **[NEW]** - run something when a response is done.
basically `res.on('close', callback)`, but also implemented for Web APIs
- unfortunately, for Web, this requires some potentially expensive
tricks - see `packages/next/src/server/web/web-on-close.ts`
the 'should show an experimental warning' test in
`react-compiler-test.ts` has been randomly flaking for me:
```
Expected substring: "Experiments (use with caution)"
Received string: " ⚠ `experimental.ppr` has been defaulted to `true` because `__NEXT_EXPERIMENTAL_PPR` was set to `true` during testing.
⚠ `experimental.ppr` has been defaulted to `true` because `__NEXT_EXPERIMENTAL_PPR` was set to `true` during testing.
▲ Next.js 14.3.0-canary.69
- Local: http://localhost:40095
"
```
when the actual CLI output is:
```
⚠ `experimental.ppr` has been defaulted to `true` because `__NEXT_EXPERIMENTAL_PPR` was set to `true` during testing.
⚠ `experimental.ppr` has been defaulted to `true` because `__NEXT_EXPERIMENTAL_PPR` was set to `true` during testing.
▲ Next.js 14.3.0-canary.69
- Local: http://localhost:40095
- Experiments (use with caution):
· reactCompiler
```
which indicates that we're reading the CLI output too early
### What
Error when users installing react@18 and requires higher version
### Why
The architecture now already requires to have `react@beta` or
`react@rc`. Especially where we need to load `react-server` condition of
react, which is erroring now in react 18.
- Ensure React Compiler runs on first-party code in Turbopack (Excludes
node_modules, but also fully skips running Babel on node_modules)
- Ensure React Compiler runs on first-party code in Webpack (Excludes
node_modules, but also fully skips running Babel on node_modules)
- Ensure React Compiler only runs on browser code -- Per React team
recommendation, it only optimizes browser-facing code currently.
- Ensure React Compiler runs on Pages Router in Webpack -- Was already
the case for Turbopack.
<!-- 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 #
-->
### What
Fix a bug introduced in #65694 , use app-page runtime for app router
layers
### Why
This is basically reverted the route context picking up logic we had
before.
During the test we found the error thrown
> Module not found: shared-runtime module router-context cannot be used
in rsc layer
Which is caused by a `next/router` imports in rsc page. Decided to
revert to what it was before as the most safe way to load share module
contexts.
It's caused by `next-contentlayer` usage that they're using
`next/router` in server component MDX, but we cannot lint error that
from node_modules. (We actually can, but disabled that due to various
mis-usage of server/client hooks we had before)
In `test/production/graceful-shutdown/index.test.ts`, 2 tests cases are
always failing, disabled them for now to investigate later.
In
`test/e2e/app-dir/actions-allowed-origins/app-action-allowed-origins.test.ts`,
the hard-coded `port` was used sometimes already been used, so we change
that to a "random" port which can help find an available port instead of
`'0'`.
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What
This PR exposes new experimental configuration for next.js,
`experimental.reactCompiler`. Under the hood, this option configures to
use new experimental react compiler
(https://react.dev/learn/react-compiler#). `reactCompiler` value can be
either boolean or an object contains partial set of compiler itself's
configuration option.
For the webpack and turbopack both it is enabled by adding a babel
plugin for the react compiler. If user have an existing .babelrc, plugin
will be appended to the config. Otherwise, swc will still kicks in (for
webpack) or turbopack for the general transform but only compiler babel
plugin will run via babel.
---------
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
When we provide the `set-cookie` string in `x-middleware-set-cookie`, we
need to ensure that multiple values are properly delimited.
We also make sure the cookies that get passed into `RequestCookies`
aren't in `ResponseCookie` form, to prevent something like `Path=/` from
being part of `cookies()`.
<!-- 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 #
-->
### What
Let `middleware` and `instrumentation` apply `react-server` exports
condition names first. When bundle the react and react-dom, bundle the
installed version instead of the built-in version.
Renamed "app" group for webpack layers to "bundled", which indicates it
will bundle all the dependencies.
### Why
Middleware and instrument are sort of isolated from app router and pages
router, if they're using react should pick up from the installed
version. Since they're in server layer so they only need to bundle the
`react-server` conditions.
x-ref: [slack
thread](https://vercel.slack.com/archives/C046HAU4H7F/p1715790385748169)
This PR ensures that any arbitrary binary data can be passed across the
RSC boundary, especially when inlined in HTML. While the Flight payloads
in RSC requests (`text/x-component`) already work, it's a different case
when we inline them directly in HTML as that's required to be a valid
string in UTF-8.
So instead of always inlining the UTF-8 decoded chunk (`new
TextDecoder('utf-8')`), we fallback non-decodable chunks to base64 and
send as a special item in `__next_f` so we can safely change it back to
a binary typed array.
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What
Disable auto polyfill for process in edge runtime.
### Why
React uses process.emit behind a typeof guard now. This leads to process
being bundled and process.emit being called which triggers build
warnings since we stub process APIs since they're not supported in Edge
runtime.
There's condition like `"object" === typeof process && "function" ===
typeof process.emit` in the react build now where the 2nd condition is
falsy. Stop polyfilling to skip that condition since it's mainly for
Node.js runtime
Related to #65692
### What?
This PR adds an experimental option `clientTraceMetadata` that will use
the existing OpenTelemetry functionality to propagate conventional
OpenTelemetry trace information to the client.
The propagation metadata is propagated to the client via meta tags,
having a `name` and a `content` attribute containing the value of the
tracing value:
```html
<html>
<head>
<meta name="baggage" content="key1=val1,key2=val2">
<meta name="traceparent" content="00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01">
<meta name="custom" content="foobar">
</head>
</html>
```
The implementation adheres to OpenTelemetry as much as possible,
treating the meta tags as if they were tracing headers on outgoing
requests. The `clientTraceMetadata` will contain the keys of the
metadata that're going to injected for tracing purpose.
### Why?
Telemetry providers usually want to provide visibility across the entire
stack, meaning it is useful for users to be able to associate, for
example, web vitals on the client, with a span tree on the server. In
order to be able to correlate tracing events from the front- and
backend, it is necessary to share something like a trace ID or similar,
that the telemetry providers can pick up and stitch back together to
create a trace.
### How?
The tracer was extended with a method `getTracePropagationData()` that
returns the propagation data on the currently active OpenTelemetry
context.
We are using `makeGetServerInsertedHTML()` to inject the meta tags into
the HTML head for dynamic requests.
The meta tags are generated through using the newly added
`getTracePropagationData()` method on the tracer.
It is important to mention that **the trace information should only be
propagated for the initial loading of the page, including hard
navigations**. Any subsequent operations should not propagate trace data
from the server to the client, as the client generally is the root of
the trace. The exception is initial pageloads, since while the request
starts on the client, no JS has had the opportunity to run yet, meaning
there is no trace propagation on the client before the server hasn't
responded.
Situations that we do not want tracing information to be propagated from
the server to the client:
- _Prefetch requests._ Prefetches generally start on the client and are
already instrumented.
- _Any sort of static precomputation, including PPR._ If we include
trace information in static pages, it means that all clients that will
land on the static page will be part of the "precomputation" trace. This
would lead to gigantic traces with a ton of unrelated data that is not
useful. The special case is dev mode where it is likely fine to
propagate trace information, even for static content, since it is
usually not actually static in dev mode.
- _Clientside (soft) navigations._ Navigations start on the client and
are usually already instrumented.
### Alternatives considered
An implementation that purely lives in user-land could have been
implemented with `useServerInsertedHTML()`, however, that implementation
would be cumbersome for users to set up, since the implementation of
tracing would have to happen in a) the instrumentation hook, b) in a
client-component that is used in a top-level layout.
### Related issues/discussions
- https://github.com/vercel/next.js/issues/47660
- https://github.com/vercel/next.js/discussions/62353 (Could be used as
an alternative to the server-timing header)
- https://github.com/getsentry/sentry-javascript/issues/9571
---------
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
### Fixing a bug
fixes#65580
### What?
#65580
### Why?
Currently, afterInteractive is given as the default strategy prop, but
afterInteractive is not set for the child retrieved through
React.Children, and it is an empty prop and is not added to the script
loader, so the script is not executed.
### How?
Added item to script loader when `child.props.strategy` is undefined.
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
<!-- 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?
Adding support for supporting a custom fontFamily name when using
next/font
### Why?
By default, next/font hashes the font name when generating css to
achieve proper scoping.
However, that makes it impossible to use next/font with 3rd party
libraries that provide CSS with pre-defined font names.
### How?
To solve this, I've added a new argument to the next/font function call
– `usedFontFamilyName`.
It allows developers to pick the fontFamily name that is going to be
used in the CSS output instead of the default one and make it work with
vendor CSS files.
```
import { Inter } from "next/font/google";
const inter = Inter({
subsets: ["latin"],
fixedFontFamily: "Inter",
});
```
Fixes [#43452](https://github.com/vercel/next.js/discussions/43452)
---
Edit:
I've changed the implementation to use `disabledFontFamilyHashing`
boolean flag which removes the hashing but keeps the original font
family name instead of allowing a custom name
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
### What
Remove `missingSuspenseWithCSRBailout` and always treate the conditions
where it was used as `true`.
### Why
This was an intended behavior introduced in 14.1, which requires users
to always add suspense boundaries if it's using any hook that could bail
out to client rendering. `missingSuspenseWithCSRBailout` as `true` was
the default behavior and you could disable it with
`missingSuspenseWithCSRBailout: false` in next config. Now after the
removal you will not be able to opt-out it.
### What
Reland #57448 , add react-server condition resolving and apply
server-only rules to middleware
Closes NEXT-1653
Closes NEXT-3333
### Why
Middleware as the pre-routing layer that is indended to be light-weight.
Since it's on edge runtime and only run on server but not on client, it
doesn't need to include the client react bundles. Hence we apply
`react-server` export condition, that if users import React we can only
bundle server required APIs and if users use React client hooks we can
error.
Adding some tests based on this Twitter thread:
https://twitter.com/NicoloRibaudo/status/1788919867002785984
Here's what I found:
- Added a new test suite testing for:
- Private fields
- Turbopack: Works
- Webpack: Works on latest
- Earlier versions of Next.js with Webpack you'd see an error failing to
parse coming from `acorn`, which webpack uses internally.
- Verified it's not failing on `next@latest` in [this
sandbox](https://codesandbox.io/p/devbox/brave-mcnulty-gszh3q?file=%2Fapp%2Fpage.tsx%3A59%2C32).
- `import` `with { type: 'json' }`
- Turbopack: Works
- Webpack: Works
- `export as` I.e. `export { x as abc }`
- Turbopack: Works
- Webpack: Works
- RegExp with `/v`
- Node.js: ⚠️ Not enabled in the test because Node.js does not support
it currently in 18.x which we run tests against.
- Turbopack: Works
- Webpack: Fails in Webpack currently on `acorn` parsing the JavaScript
## Results
In case you want to play with the test here's a codesandbox with the
same code that is in the tests:
- `next@latest`: https://codesandbox.io/p/devbox/brave-mcnulty-gszh3q
- Url: https://gszh3q-3000.csb.app/
Dev: Webpack
```
PASS test/e2e/app-dir/ecmascript-features/ecmascript-features.test.ts
ecmascript-features
✓ should work using cheerio
✓ should work using browser
```
Build: Webpack
```
PASS test/e2e/app-dir/ecmascript-features/ecmascript-features.test.ts
ecmascript-features
✓ should work using cheerio
✓ should work using browser
```
Dev: Turbopack
```
PASS test/e2e/app-dir/ecmascript-features/ecmascript-features.test.ts
ecmascript-features
✓ should work using cheerio
✓ should work using browser
```
Build: Turbopack
```
PASS test/e2e/app-dir/ecmascript-features/ecmascript-features.test.ts
ecmascript-features
✓ should work using cheerio
✓ should work using browser
```
<!-- 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 #
-->
Remove font loaders resolving for `@next/font`, users should directly
rely on `next/font`, they're intended to be removed.
Also removed the legacy tests
When a server action performs a redirect, we send an RSC request to the
redirect URL so that everything can be handled in a single roundtrip.
However, we forward the `next-action` header to that request. This means
that the intra-app RSC request will be incorrectly associated with an
action, and any rewrites we do for `next-action` requests (such as the
work in the Next.js builder to ensure actions are routed to streaming
outputs) won't be handled correctly.
<!-- 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 #
-->
This test was failing with my changes in
https://github.com/vercel/next.js/pull/64932 because it was using the
new Next.js changes, but not the corresponding react-dom changes.
An alternative solution would be to update the react-dom versions to
match those in the rest of the project (19 beta), but I think this is
better overall.
After removing the dependencies, this test works in my branch.
## What
Ensures `nonce` is added to script and link tags Next.js renders.
Additional cases it now handles:
- We already passed `nonce` to the React rendering, though not
consistently on all cases where `renderToStream` is called, I'm
surprised there haven't been more reports of this, but now it will pass
it on all cases where React rendering is called that I could find
- In `get-layer-assets.tsx` we now pass `nonce` to both the `script` and
`link` tags
- When calling `ReactDOM.preload` the nonce was missing as well, ensured
that the nonce is included in that case as well.
Added a test that mimicks the reproduction by adding `next/font` in this
case.
Fixes#64037
Closes PACK-2973
<!-- 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 #
-->
### What
Remove the auto appending `.xml` extension to the sitemap routes when
it's a dynamic route.
### Why
Previously we were adding `.xml` to `/[...paths/]sitemap` routes, but
the bad part is when you use it to generate multiple sitemaps with
`generateSitemaps` in format like `/[...paths/]sitemap.xml/[id]`, which
doesn't look good in url format and it can be inferred as xml with
content-type. Hence we don't need to add `.xml` in the url.
Before this change it could also result into the different url between
dev and prod:
dev: `/sitemap.xml/[id]`
prod: `/sitemap/[id].xml`
Now it's going to be aligned as `/sitemap/[id]`. Users can add extension
flexiblely.
Closes NEXT-3357
This test failed in dev. It has 2 problems:
1. the nanoid only contains named export
2. we should wait for the content changed then check the browser url
```
● app-dir action handling › fetch actions › should handle redirects to routes that provide an
invalid RSC response
expect(received).toBe(expected) // Object.is equality
Expected: "http://localhost:50473/pages-dir"
Received: "http://localhost:50473/client"
891 |
892 | await retry(async () => {
> 893 | expect(await browser.url()).toBe(`${next.url}/pages-dir`)
```
Closes NEXT-3369
### What
Follow up for #64294 where we could preload all the JS and CSS chunks
for `next/dynamic` component.
* Rename `preload-css` component to `preload-chunks` and remove the
filter for css chunks
* Preload JS chunks with `defer`
### Why
Preloading all the async chunks of `next/dynamic` can make rendering
more efficiently when combined with the initial chunks. Since those
chunks are splitted on client but still essential for the page
#### After vs Before
We can see the waterfall starts much earlier for the dynamic chunk
(881.8a0e88...js)
<img width="500"
src="https://github.com/vercel/next.js/assets/4800338/9bab2c32-37c3-4c7a-93e2-3aa43b2ec7c8">
<img width="500"
src="https://github.com/vercel/next.js/assets/4800338/0fba7499-bb69-41c4-ab72-e9952f3d7f68">
### What
* Extract `buildId` and server action encryption key into environment
variables for edge to make code more deterministic
* Fixed the legacy bad env names from #64108
* Always sort `routes` in prerender manifest for consistent output
* Change `environments` to `env` in middleware manifest, confirmed with
@javivelasco this is a fine change without need to bumping the version
### Why
Dynamic variants like `buildId`, SA `encryptionKey` and preview props
are different per build, which results to the non determinstic edge
bundles. Once we extracted them into env vars then the bundles become
deterministic which give us more space for optimization
Closes NEXT-3117
Reverts vercel/next.js#65425
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
### What?
make sure children is first in loader tree to fix head css bug on client
navigation
### Why?
### How?
Fixes PACK-3028
---------
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
### What
Support `esmExternals` working in app router
### Why
`esmExternals` was disabled for app router that most of the packages are
picking up the CJS bundles for externals. This PR enables to resolve the
ESM bundle for external packages.
We have two issues discovered while enabling the flag, any esm external
packages will fail in client page SSR and server action. We fixed them
by changing the below bundling logics:
* When a client page having a async dependency, we can await the page
during in rendering
* When a server action having a async dependency, we changed the server
action entry creation with webpack along with the server client entry
creation together, then webpack can handle the modules async propagation
properly.
Fixes#60756
Closes NEXT-2435
Closes NEXT-2472
Closes NEXT-3225
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
This PR promotes and renames experimental configuration options related
to server bundling:
- `serverComponentsExternalPackages` -> `serverExternalPackages`
- `bundlePagesExternals` -> `bundlePagesRouterDependencies`
Existing docs for `serverComponentsExternalPackages` was changed.
New docs for `bundlePagesRouterDependencies` were added.
Closes NEXT-3332
### What
* Extract `buildId` and server action encryption key into environment
variables for edge to make code more deterministic
* Fixed the legacy bad env names from #64108
* Always sort `routes` in prerender manifest for consistent output
* Change `environments` to `env` in middleware manifest, confirmed with
@javivelasco this is a fine change without need to bumping the version
### Why
Dynamic variants like `buildId`, SA `encryptionKey` and preview props
are different per build, which results to the non determinstic edge
bundles. Once we extracted them into env vars then the bundles become
deterministic which give us more space for optimization
Closes NEXT-3117
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Enabling Partial Prerendering (PPR) for an entire application is
ideally, the goal for teams wanting to test out the feature or adopt it
in their applications to get ready for when it becomes the default
rendering pattern. For large applications, with many routes the new
behaviours of old API's may prove a difficult pill to swallow all at
once.
This aims to enable incremental adoption of PPR for pages and routes
that want to support it in a similar way to how existing segment-level
configurations. Segments can now add:
```ts
export const experimental_ppr = true
```
To enable PPR for that segment and those descending segments. Any subset
of those routes that have it enabled can add:
```ts
export const experimental_ppr = false
```
<details>
<summary>An aside on the choice of <code>experimental_ppr</code>
name</summary>
<blockquote>
<p>It is against common JS semantics to use snake-case, and preference
is given to camel-case instead. The choice to make this snake-case was
to re-enforce that this is an experimental feature, an ugly incremental
path, and ideally, developers should aim to remove all references of it
from their codebase.</p>
<p>Additionally, this mirrors what we've done for unstable API's like
`unstable_cache`.</p>
</blockquote>
</details>
To disable PPR for that segment and those descending segments. To use
this new option, the `experimental.ppr` configuration in
`next.config.js` must be set to `"incremental"`:
```js
// next.config.js
module.exports = {
experimental: {
ppr: "incremental",
},
}
```
If a segment does not export a `experimental_ppr` boolean, it is
inferred from it's parent. If no parent has it defined, it's default
value is `false` and therefore disabled.
Once all your segments have PPR enabled via this config, it would be
considered safe for teams to set their `experimental.ppr` value in the
`next.config.js` to `true`, enabling it for the entire app and for all
future routes.
### Aside
I also took the liberty to rename `isPPR` and `supportsPPR` to be the
clearer `isAppPPREnabled` and `isRoutePPREnabled`.
---------
Co-authored-by: Hendrik Liebau <mail@hendrik-liebau.de>
When `notFound()` is thrown from metadata, it's caught by a
`<MetadataOutlet />` rendered as a sibling to the page component. But we
currently only pass the custom not-found component to the
`<NotFoundBoundary />` for the `children` slot. This means that if a
parallel route throws a `notFound()` in `generateMetadata`, it'd be
caught by the root not found, which would be unexpected.
This mirrors the logic for determining whether or not a `notFound`
boundary should be provided. A side effect of this is that if you throw
a `notFound()` in `generateMetadata` for a segment that _only_ has
parallel routes, and no `children` slot, it won't be caught by the
boundary. But fixing this will require a larger refactor.
<!-- 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-3320
### Why?
`polyfill-nomodule.js` is a pre-built file containing polyfills for
older browsers (gated by the `<script>` tag `nomodule` attribute).
### How?
- The turbopack server needs to emit a raw OutputAsset for this file, so
that it is copied into the output chunks directory.
- That file needs to be passed into `polyfillFiles`, and preserved when
we're merging manifests inside of the development server.
### Test Plan
```
HEADLESS=true pnpm testonly-dev test/e2e/app-dir/app/index.test.ts -t 'should serve polyfills for browsers that do not support modules'
HEADLESS=true pnpm testonly-dev-turbo test/e2e/app-dir/app/index.test.ts -t 'should serve polyfills for browsers that do not support modules'
```
Build a project with `next dev --turbo` and inspect:
Verify that the polyfill file exists and resolves in the browser.
Closes PACK-2993
This should fix the following scenarios,
- Given a page defined like `app/foo/[...bar]/page.tsx`
- Given a page defined like `app/bar/[[...foo]]/page.tsx`
- Given a parallel route defined like `app/@slot/[...catchall]/page.tsx`
If you navigate to `/foo/bar` the `params` prop in the parallel route
would be
```js
params: {
catchall: [
'foo',
[ 'bar' ]
]
}
```
And if you navigate to `/bar/foo` the `params` prop in the parallel
route would be
```js
params: {
catchall: [
'bar',
'[ ...foo ]'
]
}
```
With the fix in place, the `params` prop in the parallel route will be,
```js
params: {
catchall: [
'foo',
'bar',
]
}
```
And
```js
params: {
catchall: [
'bar',
'foo',
]
}
```
Respectively
Fixes an issue with https://github.com/vercel/next.js/pull/65063 where
the catch-all param only contains dynamic segments and is missing
non-dynamic route segments.
This makes building breadcrumbs extremely hard as we're missing
information to properly render the correct breadcrumb components.
This fix makes parallel route catch-all params behave like the standard
catch-all params in non-parallel routes
---------
Co-authored-by: Zack Tanner <1939140+ztanner@users.noreply.github.com>
### What
Follow up for #62873
Only apply credentials in metadata manifest tag for preview deployment
### Why
When the CORS header is "\*" and if you're including credentials in
request it will block by browser. For manifest's case, if it's fetching
from a publich CDN with responsing the CORS header "\*" and mismatching
with the current website domain it will get blocked. Previously we
introduced that change mostly for vercel deployment auth protection, now
we're going to check if it's preview deployment and also the same
origin, if yes then we'll include credentails for manifest request
Closes NEXT-3208
### What
Removing the Suspense boundary on top of `next/dynamic` by default, make
it as `React.lazy` component with preloading CSS feature.
### Why
Extra Suspense boundary is causing extra useless rendering. For SSR, it
shouldn't render `loading` by default
Related: #64060
Related: #64687
Closes
[NEXT-3074](https://linear.app/vercel/issue/NEXT-3074/app-router-content-flickering-with-reactcreatecontext-and-nextdynamic)
This is sort of a breaking change, since removing the Suspense boundary
on top of `next/dynamic` by default. If there's error happening in side
the dynamic component you need to wrap an extra Suspense boundary on top
of it
### What
When a page throws a `notFound()` error in `generateMetadata`, and the
page contains parallel route(s), an unhandled runtime error would be
thrown rather than displaying the not found page.
### Why
We use the `<MetadataOutlet />` component to throw any errors caught
during metadata resolution once the metadata is rendered by React so
that it can be caught by an error boundary, so that it doesn't throw
during metadata resolution. A promise is tracked & resolved with an
error once the metadata tree is rendered. Once the promise resolves, the
outlet component will throw.
However, every `__PAGE__` segment that would be rendered as part of the
page the user is on will render this `<MetadataOutlet />` component. We
only need a single outlet per segment as only a single error needs to be
thrown & caught.
### How
This will only render a `MetadataOutlet` for the first parallel route
that is encountered at each segment depth, as we only need a single
handler to throw the error.
Fixes#65013
Closes NEXT-3222
When you do client navigation to a dynamic page with call like
`headers()`, it wil send RSC request for that page. We want to skip the
`_rsc` query in the logging as it's disruptive.
Closes NEXT-3077
Closes#64355
This extends #64520 to cover cases where client components originate
from node_modules (foreign code).
Test Plan: Extended the integration test to cover this
Closes#64412
Fixes PACK-3014
---------
Co-authored-by: OJ Kwon <1210596+kwonoj@users.noreply.github.com>
If a forwarded server action redirects, don't attempt to follow the
redirect as it can lead to errors. For example, if the forwarded request
followed a redirect to the same URL and had to forward the request
again, it'd hit a loop. The redirect will be handled by the
`X-Action-Redirect` which will be set when the forwarded action hits the
`createRedirectRenderResult` case.
<!-- 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-3243
<!-- 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 #
-->
### What?
When pages are rendered using partial prerendering (PPR), they can
easily trigger cases that attempt to interrupt static rendering. If a
user calls `fetch` from within a `unstable_cache` callback with `cache:
"no-store"`, we currently break out, as that fetch operation is called
within a cached callback.
### Why?
Without this change, using `unstable_cache` would have limited affect
when dealing with external code that explicitly sets `cache: "no-store"`
preventing it from utilizing the user-specified-cache.
### How?
This modifies the fetch patching so it doesn't bail static rendering due
to dynamic fetches within an `unstable_cache` callback.
Closes NEXT-3220
A common pattern for parallel routes is breadcrumbs. For example, if I
have a lot of dynamic pages, and I want to render a parallel route that
renders as a breadcrumb to enumerate those dynamic params, intuitively
I'd reach for something like `app/@slot/[...allTheThings]/page.tsx`.
Currently however, `[...allTheThings]` would only match params to a
corresponding `app/[allTheThings]/page.tsx`. This makes it difficult to
build the breadcrumbs use-case unless you re-create every single dynamic
page in the parallel route as well.
This adds handling to provide unmatched catch-all routes with all of the
params that are known. For example, if I was on
`/app/[artist]/[album]/[track]`, and I visited `/zack/greatest-hits/1`,
the parallel `@slot` params would receive: `{ allTheThings: ['zack',
'greatest-hits', '1'] }`
Fixes#62539
Closes NEXT-3230
### What
Cookies set/updated/removed in middleware won't be accessible during the
render in which they were set
### Why
Middleware will properly set a `set-cookie` header to inform the client
of the cookie change, but this means the `AsyncLocalStorage` context
containing the cookies value wouldn't be updated until the next time the
request headers were parsed. In other words, on the first request the
cookie would be sent but wouldn't be available in the `cookies()`
context. And then the following request would properly have the cookie
values.
### How
This uses a proxy on the `ResponseCookies` used in middleware to add a
middleware override header with the cookie value. When we instantiate
the cached cookies, we merge in whatever headers would have been set by
middleware, so that they're available in the same render that invoked
middleware.
### Test Plan
This changeset adds a test to confirm cookies set/deleted in middleware
are available in a single pass. Verified with a deployment
[here](https://vtest314-e2e-tests-ldx7olfl1-ztanner.vercel.app/rsc-cookies).
Fixes#49442
Closes NEXT-1126
This PR adds a new `experimental-test` command to Next.js CLI.
It has 3 main functions:
- auto installing missing playwright dependencies
- auto generating missing playwright config
- running tests via `playwright test`
I'm currently working on sharing a public RFC that will have more
information. I will link that here when its available.
Closes NEXT-3076 NEXT-3032
---------
Co-authored-by: samcx <sam@vercel.com>
### What
The "auto" prefetching behavior differs between dev/prod, resulting in
confusing DX when configuring `experimental.staleTimes = { static: 0,
dynamic: 0 }`.
### Why
Prefetching is intentionally disabled in dev, but we still will create
an "auto" prefetch on navigation. When configuring
`experimental.staleTimes` to have a `0` value in both static/dynamic
cases (a pattern that isn't a good idea, but should still have
consistent DX), it means that any auto prefetching that happens is
effectively discarded immediately, as we also would also not be able to
re-use the loading data.
In prod, we would have created a "temporary" prefetch for this case,
which is effectively not a prefetch at all and gets the full RSC data.
However in dev, we've special-cased these prefetches to be "auto", so
the client won't ever receive fresh data after the first time the cache
is seeded.
### How
This removes the special-handling for dev to instead be similar to other
prefetches that are created ad-hoc, and marks it as a "temporary"
prefetch kind. This has the added benefit of not triggering 2 separate
RSC calls in dev when only one is really needed.
### Test Plan
Client cache tests were previously disabled in dev because caching
behavior does intentionally differ between dev/prod. But we can at the
very least assert that the "auto" prefetching behavior is consistent
between the two environments, so that's what has been added to the tests
here.
This also adds a test for the `experimental.staleTimes = { static: 0,
dynamic: 0 }` case.
x-ref:
https://github.com/vercel/next.js/discussions/54075#discussioncomment-9202650
<!-- 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-3209
We currently have logic spread in multiple places that normalize `nxtP`
parameters into their regular names, ie `nxtPfoo` -> `foo`. However we
don't apply this same logic to `nxtI`, which conceptually is another
parameter but for route interception. As a result, the interception
route would 404 when deployed because it'd be missing the interception
parameter.
This moves the normalization check into a util and updates the spots I
could find where we handle `nxtP` to also handle `nxtI`.
### Test Plan
Added a new test, and validated via these deploys:
**Working**:
[Link](https://vtest314-e2e-tests-m889gxi4p-vtest314-ijjk-testing.vercel.app/)
**Non-Working**:
[Link](https://vtest314-e2e-tests-8sa5t9uau-vtest314-ijjk-testing.vercel.app/)
Fixes#62207
Closes NEXT-3204
### What?
We tried to support proxy in next/font with turbopack, but wasn't able
to make upstream `reqwest` to support it with https protocol schemes.
Skipping for now for the RC and will revisit later.
### What
Apply the react aliases for app dir also to the files with
`pagesExtension`
### Why
In the page bundle of mdx page:
In RSC layer react is referencing to the insatlled react 18.2.0 's
`jsx-runtime` to create each JSX element. The react 18.2 JSX runtime
access `propTypes` of the component type and then it crashes 💥
In RSC layer it should use the built-in react canary's `jsx-runtime`.
The reason that it didn't use the built-in one is we're using customized
`pageExtension` `["mdx"]` for mdx, where we didn't apply all these rules
for the files with `pageExtension`, but only the js and ts files by
default.
For mdx specifically, we cannot only applied to
`(page|layout|route).[page extension]` cause every mdx file needs to
have proper resolution. Since this doesn't break transform, it's safe to
apply for all files with page extension.
Fixes#58888
Closes NEXT-3187
### What
- closes#63896
PR implements parsing JSValue for the matcher config if given item is an
object. We had those types already declared in place but somehow parsing
ignores it.
The function we use to generate a string with named parameters to pass
into `path-to-regexp` currently doesn't properly handle non-word
characters (namely, for the purposes of this bugfix, hyphens). As a
result, `pathToRegexp` will convert something like `/foo/:bar-baz` into
`/^\/foo(?:\/([^\/#\?]+?))-baz[\/#\?]?$/i`, effectively only treating
the `:foo` as part of the regex capture group and leaving a dangling
-baz.
This means using an interception route within a dynamic segment (such as
`/foo/[bar-baz]`) would not properly trigger the route interception
Fixes#64766
### What?
I submitted PR #64499 , it got merged, but it contains a mistake.
I'm terribly sorry about this!
By removing the traceparent from the cachekey, we mistakenly removed the
header from the original object.
Causing the actual request to be executed without the traceparent
header.
### Why?
Creating a cachekey should not alter the original object.
### How?
Flip the arguments for Object.assign
---------
Co-authored-by: Jeffrey <jeffrey@jeffreyzutt.nl>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
<!-- 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 #
-->
### What?
This ensures that the body limit option is enforced on all request
bodies sent to the Node.js runtime, not just the multipart field size
limits.
### Why?
The documentation states that this should limit the body size,
previously it only limited the field size.
### How?
This uses a `Transform` stream from Node.js. [Based on my
benchmarks](https://gist.github.com/wyattjoh/c470d98095da2f95f5920396aba2a206)
using the transform stream added next to no overhead, yet it did
simplify the implementation quite a bit. Assuming this is due to the
already performant stream support within Node.js.
Closes NEXT-3151
When a server action triggers a redirect, we're incorrectly applying a
refresh marker to the segment they were on, rather than the segment they
were being redirected to. As a result, when revalidation occurs (via
`revalidateX` or `router.refresh()`), the top-level segment would be
replaced with data for an incorrect segment.
For example, if triggering a redirect action from `/redirect` to `/`,
the router state tree would save a reference to `/redirect`. The next
time a refresh or revalidate happens, it'd refresh the segment data for
`/redirect` instead of `/`.
Fixes#64728
Closes NEXT-3156
When the router cache can't find a cache node for the requested segment,
it performs a request to the server to get the missing data. This
request to the server currently will always include the `next-url`
header, and on soft-navigations, the router will route the request to
the intercepted handler. This lazy fetch is treated as a soft navigation
by the server, and will incorrectly return data for the intercepted
route.
Similar to the handling in `router.refresh`, and the server action
reducer, we should not include the `next-url` header if there's no
interception route currently in the tree, as otherwise we'll be
erroneously triggering the intercepted route.
Fixes#64676
Closes NEXT-3146
Reverts vercel/next.js#64271
This appears to be causing problems rendering error boundaries on SPA
navigations and needs further investigation
Closes NEXT-3150
## What?
- Changes webpack output target to `es6` (required for `async function`
output)
- Adds tests for top level await in server components and client
components (App Router)
- Converted the async-modules tests to `test/e2e`
- Has one skipped test that @gnoff is going to look into. This shouldn't
block merging this PR 👍
Adds additional tests for top level `await`.
Since [Next.js
13.4.5](https://github.com/vercel/next.js/releases/tag/v13.4.5) webpack
has top level await support enabled by default.
Similarly Turbopack supports top level await by default as well.
TLDR: You can remove `topLevelAwait: true` from the webpack
configuration.
In writing these tests I found that client components are missing some
kind of handling for top level await (async modules) so I've raised that
to @gnoff who is going to have a look.
<!-- 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-3126
Fixes https://github.com/vercel/next.js/issues/43382
### Why
For app page rendering on edge, the `AsyncLocalStorage` (ALS) should be
bundled as same instance across layers. We're accessing the ALS in
`next/dynamic` modules during SSR for preloading CSS chunks. There's a
bug that we can't get the ALS store during SSR in edge, I digged into it
and found the root cause is:
We have both import paths:
`module (rsc layer) -> request ALS (shared layer)`
`module (ssr layer) -> request ALS (shared layer)`
We expect the ALS to be the same module since we're using the same layer
but found that they're treated as different modules due to applying
another loader transform on ssr layer. They're resulted in the same
`shared` layer, but with different resource queries. This PR excluded
that transform so now they're identical across layers.
### What
For webpack, we aligned the loaders applying to the async local storage,
so that they're resolved as the same module now.
For turbopack, we leverage module transition, sort of creating a new
`app-shared` layer for these modules, and apply the transition to all
async local storage instances therefore the instances of them are only
bundled once.
To make the turbopack chanegs work, we change how the async local
storage modules defined, separate the instance into a single file and
mark it as "next-shared" layer with import:
```
any module -> async local storage --- use transition, specify "next-shared" layer ---> async local storage instance
```
Closes NEXT-3085
### What
When rendering a parallel slot multiple times in a single layout, in
conjunction with using an error boundary, the following TypeError is
thrown:
> Cannot destructure property 'parallelRouterKey' of 'param' as it is
null
### Why
I'm not 100% sure of the reason, but I believe this is because of how
React attempts to dededupe (more specifically, "detriplficate") objects
that it sees getting passed across the RSC -> client component boundary
(and an error boundary is necessarily a client component). When React
sees the same object twice, it'll create a reference to that object and
then use that reference in future places where it sees the object. My
assumption is that there's a bug somewhere here, as the `LayoutRouter`
component for the subsequent duplicated parallel slots (after the first
one) have no props, hence the TypeError.
### How
Rather than passing the error component as a prop to `LayoutRouter`,
this puts it as part of the `CacheNodeSeedData` data structure. This is
more aligned with other properties anyway (such as `loading` and `rsc`
for each segment), and seems to work around this bug as the
`initialSeedData` prop is only passed from RSC->client once.
EDIT: Confirmed this is also fixed after syncing the latest React, due
to https://github.com/facebook/react/pull/28669Fixes#58485
Closes NEXT-2095
`initialCanonicalUrl` differs from the `canonicalUrl` that gets set on
the client, such as when there's a basePath set.
This hoists the `canonicalUrl` construction up so we can re-use it when
adding refetch markers to the tree.
This also renames `pathname` -> `path` since it also includes search
params. I added a test to confirm no extra erroneous fetches happened in
both cases.
Fixes#64584
Closes NEXT-3130
Since `AppRouterState` is promise-based (so we can `use` the values and
suspend in render), the state itself isn't stable between renders. Each
action corresponds with a new Promise object. When a link is hovered, a
prefetch action is dispatched, even if the prefetch never happens (for
example, if there's already a prefetch entry in the cache, and it
doesn't need to prefetch again). In other words, the prefetch action
will be dispatched but won't necessarily change the state.
This means that these no-op actions that don't actually change the state
values will trigger a re-render. Most of the context providers in
`AppRouter` are memoized with the exception of `LayoutRouter` context.
This PR memoizes those values so that consumers are only notified of
meaningful updates.
Fixes#63159
Closes NEXT-3127
### What
When middleware.js is present, the logging is duplicated. We should
filter out the 1st middleware request and only log the actual one going
through request handler / renderer
Closes NEXT-3125
When an action is marked as "discarded", we enqueue a refresh, since the
navigation event will be invoked immediately without waiting for the
action to finish. We refresh because it's possible that the discarded
action triggered some sort of mutation/revalidation, and we want the
router to still be able to respond to that new data.
However there's a bug in this logic -- it'll only enqueue the refresh
action if there were no other actions in the queue, ignoring the case
where something is still in the queue. This makes sure that the refresh
is handled after `runRemainingActions` finishes.
When adding a test for the server component case (which doesn't hit this
refresh branch), I noticed `LayoutRouter` caused React to suspend
indefinitely, because it got stuck in the `use(unresolvedThenable)`
case. We should only suspend indefinitely if we kicked off a the
`SERVER_PATCH` action, as otherwise it's possible nothing will ever
break out of that branch.
Fixes#64517
Closes NEXT-3124
Resolves#64412
This adds a client transition to the app route `ModuleAssetContext` and
the corresponding transforms so that client components can be safely
imported and referenced (as their proxies) in app routes.
Test Plan: Added an integration test
Closes PACK-2964
### What?
The string value of `Metadata.openGraph.emails` throws error:
```tsx
export const metadata = {
openGraph: {
type: 'article',
emails: 'author@vercel.com',
},
};
```
Error:
```sh
r.map is not a function
```
The type is:
```tsx
type OpenGraphMetadata = {
// ...
emails?: string | Array<string>
}
```
### Why?
Basic values such as `emails` and `phoneNumbers` were not included when
`ogType` was set while resolving the values.
### How?
Include basic values when resolving the metadata.
Fixes#63415
This ensures we properly skip calling a fetch during build-time that has
`cache: 'no-store'` as it should only be called during runtime instead.
Fixes: https://github.com/vercel/next.js/issues/64462
Closes NEXT-3114
## Why?
For multi-root layouts (route groups on the root with their root
layouts, no layout file on the root), it is not possible to use global
`not-found` since the `layout` is missing on the root.
```sh
.
└── app/
├── (main)/
│ └── layout.js
├── (sub)/
│ └── layout.js
└── not-found.js --> ERR: missing layout
```
Current Behavior:
```sh
not-found.js doesn't have a root layout. To fix this error, make sure every page has a root layout.
```
## What?
Let multi-root layouts also benefit from the global `not-found`.
## How?
Wrap root `not-found` with default layout if root layout does not exist.
Although this solution is not `multi-root` specific, it won't produce
critical issues since a root `layout` is required for other cases.
Fixes#55191#54980#59180
### 🤔 What's in there?
We've deprecated config's `analyticsId` in 14.1.1 [almost 3 months
ago](https://github.com/vercel/next.js/releases/tag/v14.1.1-canary.2).
Users can opt in fot `@vercel/speed-insights`, or use
`useReportWebVitals` to report to any provider they'd like.
This PR:
- removes `analyticsId` key from configuration
- stops setting `__NEXT_PUBLIC_ANALYTICS_ID` env variable when the key
was present
- stops injecting `performance-relayer` file, when the variable is set
- cleans up related test code.
Since the router processes events sequentially, we special case
`ACTION_NAVIGATE` events to "discard" a pending server action so that it
can process the navigation with higher priority. We should apply this
same logic to `ACTION_RESTORE` events (e.g. `router.back()`) for the
same reason.
Fixes#64432
Closes NEXT-3098
`fetchCache` is a more fine-grained segment level cache-control
configuration that most people shouldn't have to use. Current semantics
of `dynamic = "force-dynamic"` will still treat the fetch as cacheable
unless explicitly overriding it in the fetch, or setting a segment level
`fetchCache`.
The `dynamic` cache configuration should be seen as a "top-level"
configuration, while more fine-grained controls should inherit logical
defaults from the top-level. Otherwise this forces people to opt-into
the `fetchCache` configuration, or manually override each `fetch` call,
which isn't what you'd expect when forcing a segment to be dynamic.
This will default to not attempting to cache the fetch when
`force-dynamic` is used. As a result, I had to update one of the
`app-static` tests to use `revalidate: 0` rather than `force-dynamic`,
as the revalidate behavior is slightly different in that it won't modify
the revalidation time on a fetch if it's non-zero.
Closes NEXT-2067
The fix is not correct, we already have request ALS wrapping the request
in app-render, shouldn't get another one for edge adapter. This is
actually a bundler bug
Reverts vercel/next.js#64382
Closes NEXT-3097
### What
Wrap async local storage for all edge runtime routes in adapter
Basically fixed the case reported in [this
tweet](https://x.com/keegandonley/status/1778538456458854880)
### Why
We're relying on the ALS for dynamic css preloading but we didn't wrap
the ALS for request handlers for edge. So if you have CSS imports in
`next/dynamic` in edge runtime it would break.
Closes NEXT-3085
<!-- 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 #
-->
### What?
This adds a missing test case for a page which accesses dynamic API's
within `generateMetadata`. It also adds a test case to verify that any
of the URL's being tested can succeed based on the components link
components (it relies on finding a link to click in the browser).
Closes NEXT-3004
## Why
Currently, Server Action handlers are just normal routes and they
accepting POST requests. The only way to differentiate a normal request
(page access, API route, etc.) from a Server Action request is to check
that if it's a POST and has a Server Action ID set via headers or body
(e.g. `multipart/form-data`).
Usually, for existing page and API routes the correct handlers (page
renderer, API route handler) will take precedence over Server Action's.
But if the route doesn't exist (e.g. 404) it will still go through
Server Action's handler and result in an error. And we're eagerly
logging out that error because it might be an application failure, like
passing a wrong Action ID.
## How
In this PR we are making sure that the error is only logged if the
Action ID isn't `null`. This means that it's an intentional Server
Action request with a wrong ID. If the ID is `null`, we just handle it
like 404 and log nothing.
Fixes#64214.
Closes NEXT-3071
### What
Bump the edge runtime manifest version and add `environments` property
to each route for inlining values for deployment build.
### Why
In edge runtime, extract the preview props into edge functions manifest
that holding the non-deterministic inline values, then the output build
will be more deterministic that helps deployment speed
x-ref: https://github.com/vercel/vercel/pull/11390
x-ref: https://github.com/vercel/vercel/pull/11395
Closes NEXT-3012
Closes NEXT-1912
Building on #58293, this expands escaping of url-unsafe characters in
paths to “required” scripts and styles in the app renderer.
This also refactors the test introduced in #58293 and expands it to
include stylesheet references as well as checking resources in the head,
which include special characters like turbopack references like
`[turbopack]`.
Test Plan: `TURBOPACK=1 pnpm test-dev
test/e2e/app-dir/resource-url-encoding`
Closes PACK-2911
Provides a `revalidateReason` argument to `getStaticProps` ("stale" |
"on-demand" | "build").
- Build indicates it was run at build time
- On-demand indicates it was run as a side effect of [on-demand
revalidation](https://nextjs.org/docs/pages/building-your-application/data-fetching/incremental-static-regeneration#on-demand-revalidation)
- Stale indicates the resource was considered stale (either due to being
in dev mode, or an expired revalidate period)
This will allow changing behavior based on the context in which it's
called.
Closes NEXT-1900
## Why?
When we fetch the same cache key (URL) but add an additional tag, the
revalidation does not re-fetch correctly (the bug just uses in-memory
cache again) when deployed.
:repro: →
https://github.com/lostip/nextjs-revalidation-demo/tree/main
---------
Co-authored-by: Ethan Arrowood <ethan@arrowood.dev>
### What
When submitting a server action on a page that doesn't import the action
handler, a "Failed to find server action" error is thrown, even if
there's a valid handler for it elsewhere.
### Why
Workers for a particular server action ID are keyed by their page
entrypoints, and the client router invokes the current page when
triggering a server action, since it assumes it's available on the
current page. If an action is invoked after the router has moved away
from a page that can handle the action, then the action wouldn't run and
an error would be thrown in the server console.
### How
We try to find a valid worker to forward the action to, if one exists.
Otherwise it'll fallback to the usual error handling. This also adds a
header to opt out of rendering the flight tree, as if the action calls a
`revalidate` API, then it'll return a React tree corresponding with the
wrong page.
Fixes#61918Fixes#63915
Closes NEXT-2489
Currently acornjs has an issue with compiling undici, add undici
externalize, once it's resolved we can remove the externalization for it
```
You may need an additional loader to handle the result of these loaders.
| // 5. If object is not a default iterator object for interface,
| // then throw a TypeError.
> if (typeof this !== 'object' || this === null || !(#target in this)) {
| throw new TypeError(
| `'next' called on an object that does not implement interface ${name} Iterator.`
Import trace for requested module:
../../../../node_modules/.pnpm/undici@6.12.0/node_modules/undici/lib/web/fetch/util.js
../../../../node_modules/.pnpm/undici@6.12.0/node_modules/undici/lib/web/fetch/headers.js
../../../../node_modules/.pnpm/undici@6.12.0/node_modules/undici/index.js
./app/undici/page.js
```
Closes NEXT-3030
Fixes#64018
Adds support for modern configurations introduced in TS 5.4
Expected output: not modifying the `module`, `esModuleInterop` configs
since `module: preserve` is present
```
We detected TypeScript in your project and reconfigured your tsconfig.json file for you. Strict-mode is set to false
by default.
The following suggested values were added to your tsconfig.json. These values can be changed to fit your project's n
eeds:
- lib was set to dom,dom.iterable,esnext
- allowJs was set to true
- skipLibCheck was set to true
- strict was set to false
- noEmit was set to true
- incremental was set to true
- include was set to ['next-env.d.ts', '**/*.ts', '**/*.tsx']
- exclude was set to ['node_modules']
The following mandatory changes were made to your tsconfig.json:
- isolatedModules was set to true (requirement for SWC / Babel)
- jsx was set to preserve (next.js implements its own optimized jsx transform)
```
---------
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
When adding refresh markers for refetching segments that are "stale"
(the soft navigation case where they are still in the Router State Tree
but not part of the page that we're rendering), they only contained a
reference to the pathname. Once the actual refresh was triggered we
added the current search params to the request.
However, this causes an issue: segments in the `FlightRouterState` can
contain searchParams (ie, `__PAGE__?{"foo": "bar}` is what the segment
becomes when adding `?foo=bar` to a page). This means that when we
refresh those nodes from the server, it won't know how to find the
`CacheNode` for the stale segment since we won't have them in the
refetch tree. This updates to keep a reference to the searchParams that
were part of the request that made it active.
While fixing this, I also noticed that we were missing a spot to add the
refetch marker in `applyRouterStatePatchToTree` in the case of a root
refresh (caught by these tests failing in PPR)
[x-ref](https://github.com/vercel/next.js/discussions/63900#discussioncomment-9002137)
<!-- 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-3007
### What?
Fixes#61611
### Why?
Any one having custom server may be having logic to set cookies during
GET requests too. Currently nextjs in app directory does not allow to do
so but with custom server its very much possible.
### How?
By merging cookies of redirect response and server action POSt response
### Tests
I have added one more test to existing suite and it passing with fix in
place.
### Notes
This bug is reproducible only if developer has custom server on top of
next app but still very probable
---------
Co-authored-by: Shu Ding <g@shud.in>
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What
Fix the status code in static generation metadata for `/_not-found`
route, aligning it as 404 for both dev and build
### Why
`/_not-found` route should still return 404 code as it's reserved as
default not found route
Closes NEXT-3001
### What?
Match on `pages_api_unknown-domain-no-await_.*?\.js/` instead of
`/at.+\/pages\/api\/unknown-domain-no-await.js/`
### Why?
Turbopack generates a different chunk path for js files. This PR fixes
one integration test case.
### How?
Closes PACK-2883
### What
When triggering an interception route that has a parent with dynamic
params, and then later going to "refresh" the tree, either by calling
`router.refresh` or revalidating in a server action, the refresh action
would silently fail and the router would be in a bad state.
### Why
Because of the dependency that interception routes currently have on
`FlightRouterState` for dynamic params extraction, we need to make sure
the refetch has the full tree so that it can properly extract earlier
params. Since the refreshing logic traversed parallel routes and scoped
the refresh to that particular segment, it would skip over earlier
segments, and so when the server attempted to diff the tree, it would
return an updated tree that corresponded with the wrong segment
(`[locale]` rather than `["locale", "en", "d]`).
Separately, since a page segment might be `__PAGE__?{"locale": "en"}`
rather than just `__PAGE__`, this updates the refetch marker logic to do
a partial match on the page segment key.
### How
This keeps a reference to the root of the updated tree so that the
refresh always starts at the top. This has the side effect of
re-rendering more data when making the "stale" refetch request, but this
is necessary until we can decouple `FlightRouterState` from interception
routes.
shout-out to @steve-marmalade for helping find this bug and providing
excellent Replays to help track it down 🙏
x-ref:
- https://github.com/vercel/next.js/discussions/63900
<!-- 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-2986
Currently we aren't detecting the draft mode case properly in
`unstable_cache` so the cache is unexpectedly being leveraged. This
ensures we bypass the cache for `unstable_cache` in draft mode the same
way we do for the fetch cache handling.
Fixes: https://github.com/vercel/next.js/issues/60445
Closes NEXT-2987
This ensures we don't attempt passing a closed body to a
Request/Response object when a request is aborted as this triggers the
disturbed/locked error condition.
<details>
<summary>Example error</summary>
```sh
TypeError: Response body object should not be disturbed or locked
at extractBody (node:internal/deps/undici/undici:4507:17)
at new Request (node:internal/deps/undici/undici:5487:48)
at new NextRequest (/private/var/folders/cw/z0v1fby13ll4ytx_j3t8hhqh0000gn/T/next-install-d72b2dfb54a1417294505ab189942a38fd6bc139c24b9a8089fc3248568ff902/node_modules/.pnpm/file+..+next-repo-aef41a0c8a591889bcb0dc2e751aa71aa1c2e78c82d9e9b2fe3515c3d40f6c03+packages+n_wd7e7pnjmf2re4cc3l4tp6yzqe/node_modules/next/dist/server/web/spec-extension/request.js:33:14)
at NextRequestAdapter.fromNodeNextRequest (/private/var/folders/cw/z0v1fby13ll4ytx_j3t8hhqh0000gn/T/next-install-d72b2dfb54a1417294505ab189942a38fd6bc139c24b9a8089fc3248568ff902/node_modules/.pnpm/file+..+next-repo-aef41a0c8a591889bcb0dc2e751aa71aa1c2e78c82d9e9b2fe3515c3d40f6c03+packages+n_wd7e7pnjmf2re4cc3l4tp6yzqe/node_modules/next/dist/server/web/spec-extension/adapters/next-request.js:94:16)
at NextRequestAdapter.fromBaseNextRequest (/private/var/folders/cw/z0v1fby13ll4ytx_j3t8hhqh0000gn/T/next-install-d72b2dfb54a1417294505ab189942a38fd6bc139c24b9a8089fc3248568ff902/node_modules/.pnpm/file+..+next-repo-aef41a0c8a591889bcb0dc2e751aa71aa1c2e78c82d9e9b2fe3515c3d40f6c03+packages+n_wd7e7pnjmf2re4cc3l4tp6yzqe/node_modules/next/dist/server/web/spec-extension/adapters/next-request.js:70:35)
at doRender (/private/var/folders/cw/z0v1fby13ll4ytx_j3t8hhqh0000gn/T/next-install-d72b2dfb54a1417294505ab189942a38fd6bc139c24b9a8089fc3248568ff902/node_modules/.pnpm/file+..+next-repo-aef41a0c8a591889bcb0dc2e751aa71aa1c2e78c82d9e9b2fe3515c3d40f6c03+packages+n_wd7e7pnjmf2re4cc3l4tp6yzqe/node_modules/next/dist/server/base-server.js:1365:73)
```
</details>
Fixes: https://github.com/vercel/next.js/issues/63481
Closes NEXT-2984
Closes NEXT-2904
Trying to submit a server action when JS is disabled (ie, no action
header in the request, and in the "progressively enhanced" case) for a
static resource results in a 405 error when deployed to Vercel. In the
absence of an action ID header, the request content-type is used to
signal that it shouldn't try and hit the static cache. However with
multipart/form-data, this will include the boundary. This updates the
matcher to consider a boundary string.
Fixes#58814
Closes NEXT-2980
This introduces an experimental router flag (`experimental.staleTimes`)
to change the router cache behavior. Specifically:
```ts
// next.config.js
module.exports = {
experimental: {
staleTimes: {
dynamic: <seconds>,
static: <seconds>,
},
},
};
```
- `dynamic` is the value that is used when the `prefetch` `Link` prop is
left unspecified. (Default 30 seconds)
- `static` is the value that is used when the `prefetch` `Link` prop is
`true`. (Default 5 minutes)
Additional details:
- Loading boundaries are considered reusable for the time period
indicated by the `static` property (default 5 minutes)
- This doesn't disable partial rendering support, **meaning shared
layouts won't automatically be refetched every navigation, only the new
segment data**.
- This also doesn't change back/forward caching behavior to ensure
things like scroll restoration etc still work nicely.
Please see the original proposal
[here](https://github.com/vercel/next.js/discussions/54075#discussioncomment-6754339)
for more information. The primary difference is that this is a global
configuration, rather than a per-segment configuration, and it isn't
applied to layouts. (We expect this to be a "stop-gap" and not the final
router caching solution)
Closes NEXT-2703
### What?
This fixes an issue where the `nonce` attribute isn't set on
`next/script` elements that has the `afterInteractive` (the default)
strategy resulting in `<link rel="preload" as="script"/>` tags without a
nonce.
### Why?
For apps that uses 3rd party scripts (or any script) with a nonce loaded
via `next/script` this is necessary unless you want them all to use
`beforeInteractive` which isn't super nice for performance.
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What & Why
There was some code added in the catch-all route normalization that
doesn't seem to make sense -- it was checking if the provided `appPath`
depth was larger than the catch-all route depth, prior to inserting it.
But it was comparing depths in an inconsistent way (`.length` vs
`.length - 1`), and the catch all path was also considering the `@slot`
and `/page` suffix as part of the path depth.
This means that if you had a `@modal/[...catchAll]` slot, it wouldn't be
considered for a page like `/foo/bar/baz`, because `/foo/bar/baz`
(depth: 4 with the current logic) and `/@modal/[...catchAll]/page`
(depth: 3 with the current logic) signaled that the `/foo/bar/baz` route
was "more specific" and shouldn't match the catch-all.
I think this was most likely added to resolve a bug where we were
inserting optional catch-all (`[[...catchAll]]`) routes into parallel
slots. However, optional catch-all routes are currently unsupported with
parallel routes, so this feature didn't work properly and the partial
support introduced a bug for regular catch-all routes.
### How
This removes the confusing workaround and skips optional catch-all
segments in this handling. Separately, we can add support for optional
catch-all parallel routes, but doing so will require quite a bit more
changes & also similar handling in Turbopack. Namely, if have a
top-level optional catch-all, in both the Turbopack & current Webpack
implementation, that top-level catch-all wouldn't be matched. And if you
tried to have an optional catch-all slot, in both implementations, the
app would error with:
> You cannot define a route with the same specificity as a optional
catch-all route ("/" and "/[[...catchAll]]")
because our route normalization logic does not treat slots specificity
differently than pages.
**Note**: This keeps the test that was added when this logic was first
introduced in #60776 to ensure that the case this was originally added
for still passes.
Fixes#62948
Closes NEXT-2728
Closes: https://github.com/vercel/next.js/issues/63623
When a relative assetPrefix was set (e.g. `/custom-asset-prefix`),
bundle fetching would always return a 404 as the assetPrefix was not
removed from filesystem path
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
<!-- 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?
Fixes#63871
-->
### What?
Adds safe traversal to rewrite `has` items in a certain new
(`isInterceptionRouteRewrite()` added in the v14.2.0 canaries) check to
the rewrite routes.
### Why?
The new check assumed that all `has` arrays had at least one item, when
previously Next.js accepted rewrites with empty `has`. Adding safe
traversal doesn't negatively impact the check, as the check only needs
rewrites with the first item.
Fixes#63871
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What
Strip the search query for the `urlPathname` passed down to metadata
handling.
### Why
This is because the `urlPathname` from `staticGenerationStore` contains
query, so it will contain `?rsc` query for client navigation, which lead
to the relative path canonical url (e.g. `./`) will have the search
query along with it. This PR is to remove that and make sure always uses
pathname.
Reported by @pacocoursey
Closes NEXT-2963
### What & Why
When an RSC triggers `navigate` after the shell has already been sent to
the client, a meta tag is inserted to signal to the browser it needs to
perform an MPA navigation. This is primarily used for bot user agents,
since we wouldn't have been able to provide a proper redirect status
code (since it occurred after the initial response was sent).
However, the router would trigger a SPA navigation, while the `<meta>`
tag lagged to perform an MPA navigation, resulting in 2 navigations to
the same URL.
### How
When the client side code attempts to handle the redirect, we treat it
like an MPA navigation. This will suspend in render and trigger a
`location.push`/`location.replace` to the targeted URL. As a result,
only one of these navigation events will win.
Fixes#59800Fixes#62463
Closes NEXT-2952
Closes NEXT-2719
When a server action performs a redirect, we currently initiate a `HEAD`
request to the targeted URL to verify if it has a proper RSC response.
If it does, it then invokes a GET and streams the response. This leads
to an extra request to the server which can be costly and poor for
performance. If the `GET` returns an invalid RSC response, we'll discard
the response. The client router will also see the invalid response which
will signal that it needs to perform an MPA navigation to the targeted
URL.
<!-- 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-2956
