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
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
### 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
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
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
### 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.
