### What?
* order of CSS between layout and page
* order of CSS between page and next/dynamic
### Why?
### How?
* overrides webpack CSS chunk loading to use react CSS loading to allow
them to share the order
This takes the `layerAssets` property from the previous PR and actually
renders it, replacing the previous style handling. This ensures that
when multiple page segments are rendered on screen, all of their
associated CSS files are loaded. The existing `findHeadInCache` method
only ever returns a single head node, which means it’d miss stylesheets.
Fixes#59308Fixes#63465
Follow-up to https://github.com/vercel/next.js/pull/65825 this ensures
we don't skip the static optimization specifically for metadata routes
as this most often should be static as they aren't dynamic content and
are requested very frequently.
This configures the default client router cache `staleTime.dynamic`
value to be `0`.
This means that:
- Navigating between pages will always fire off a network request to get
RSC data for the page segment, rather than restoring from router cache
- Loading states will remain cached for 5 minutes (or whatever
`config.experimental.staleTimes.static` is set to)
- Shared layout data will continue to remain cached due to [partial
rendering](https://nextjs.org/docs/app/building-your-application/routing/linking-and-navigating#4-partial-rendering)
- Back/forward behavior will still restore from cache to ensure the
browser can restore scroll position.
It's possible to opt-out of this, and into the previous behavior, by
setting the
[`staleTimes`](https://nextjs.org/docs/app/api-reference/next-config-js/staleTimes)
config in `next.config.js`:
```js
/** @type {import('next').NextConfig} */
const nextConfig = {
experimental: {
staleTimes: {
dynamic: 30
},
},
}
module.exports = nextConfig
```
<!-- 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)
### BREAKING CHANGE
This changes the behavior of the default image `loader` so that
[`Content-Disposition`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition#as_a_response_header_for_the_main_body)
header is now `attachment` for added protection since the API can serve
arbitrary remote images.
The new default value, `attachment`, forces the browser to download the
image when visiting directly. This is particularly important when
`dangerouslyAllowSVG` is true. Most users will not notice the change
since visiting pages won't behave any differently, only visiting images
directly.
Users can switch back to the old behavior by configuring `inline` in
next.config.js
```js
module.exports = {
images: {
contentDispositionType: 'inline',
},
}
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
## 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
### 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>
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>
The tests added in https://github.com/vercel/next.js/pull/46219 were
never correctly testing the headers because `detectContentType()` is
called first and only when we can't detect the type from the response
body do we fallback to the `Content-Type` header.
I also refactored some of the tests because the `ctx: any` type was
causing some tests to not run when testing different configuration
options.
Closes NEXT-3321
`server-utils` should not be imported into middleware as it contains
imports that won't work in the edge runtime. Those imports aren't
technically used, but it was causing a warning nonetheless.
This adds a regression test to confirm the warning is only present when
actually importing a Node.js module in userland.
Closes NEXT-3246
<!-- 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?
Add support to import attributes.
### Why?
The old import assertions syntax is deprecated and the proposal is
updated. See https://github.com/babel/babel/pull/15536
### How?
Add support to import attributes and keep old import assertions working
by using `@babel/plugin-syntax-import-attributes` with the
`deprecatedAssertSyntax` option.
Docs: https://babeljs.io/docs/babel-plugin-syntax-import-attributes
---------
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
Co-authored-by: Steven <steven@ceriously.com>
### What?
Add a validation for parallel routes with the same path.
This PR enables
`test/e2e/app-dir/conflicting-page-segments/conflicting-page-segments.test.ts`
### Why?
To match the behavior in the default mode.
### How?
Closes PACK-2912
### 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
Determine if the client module is a CJS file and `default` export is
imported, then we include the whole module instead of using webpack
magic comments to only extract `default` export.
## Why
Unlike ESM, The `default` export of CJS module is not just `.default`
property, we need to include `__esModule` mark along with `default`
export to make it function properly with React client module proxy
Fixes#64518
Closes NEXT-3119
cc @shuding
CI run failed after #63053 on turbo production, which had not yet been
targeted for turbo.
x-ref: #63103
---------
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
Co-authored-by: Leah <8845940+ForsakenHarmony@users.noreply.github.com>
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
### 🤔 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.
### What
CSS imports in components that loaded by `next/dynamic` in client
components will cause the css are missing initial in
SSR, and loaded later on client side which will lead to FOUC. This PR
fixes the issue and get CSS preloaded in the SSR for dynamic components.
### Why
The CSS from client components that created through `next/dynamic` are
not collected in the SSR, unlike RSC rendering we already collect the
CSS resources for each entry so we included them in the server rendering
so the styles are availble at that time. But for client components, we
didn't traverse all the client components and collect the CSS resources.
In pages router we kinda collect all the dynamic imports and preload
them during SSR, but this approach is not able to be applied to app
router due to different architecture. Since we already have all the
dynamic imports info and their related chunks in
react-loadable-manifest, so we can do the similar "preloading" thing in
app router. We use the current dynamic module key (`app/page.js ->
../components/foo.js`) which created by SWC transform and match it in
the react loadable manifest that accessed from `AsyncLocalStorage`, to
get the css files created by webpack then render them as preload
styleshee links. In this way we can SSR all the related CSS resources
for dynamic client components.
The reason we pass down the react loadable manifest through
`AsyncLocalStorage` is that it's sort of exclude the manifest from RSC
payload as it's not required for hydration, but only required for SSR.
Note: this issue only occurred in dynamic rendering case for client
components.
### Other Changes Overview
- Change the react loadable manifest key from pages dir based relative
path to a source dir based relative path, to support cases with both
directory or only one of them
Closes NEXT-2578
Fixes#61212Fixes#61111Fixes#62940
Replacement for #64021 but only with production test
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
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
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
### 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
### What
When calling `revalidatePath` or `revalidateTag` in a server action for
an intercepted route with dynamic segments, the page would do a full
browser refresh.
### Why
When constructing rewrites for interception routes, the route params
leading up to the interception route are "voided" with a
`__NEXT_EMPTY_PARAM__` demarcation. When it comes time to look up the
values for these dynamic segments, since the params aren't going to be
part of the URL, they get matched via `FlightRouterState`
([ref](d67d658ce7/packages/next/src/server/app-render/app-render.tsx (L153-L201))).
The `shouldProvideFlightRouterState` variable only passes it through for
RSC requests; however, since the server action will perform the action &
return the flight data in a single pass, that means the updated tree
from the server action isn't going to receive the `FlightRouterState`
when constructing the new tree. This means the old tree will have a
`["locale", "en", "d"]` segment, and the new tree from the server action
will have `"[locale]"`. When the router detects this kind of segment
mismatch, it assumes the user navigated to a new root layout, and
triggers an MPA navigation.
### How
This unconditionally provides the `FlightRouterState` to
`makeGetDynamicParamFromSegment` so that it can properly extract dynamic
params for interception routes. We currently enforce interception routes
to be dynamic due to this `FlightRouterState` dependency.
Fixes#59796
Closes NEXT-2079
`applyRouterStatePatchToTree` had been refactored to support the case of
not skipping the `__DEFAULT__` segment, so that `router.refresh` or
revalidating in a server action wouldn't break the router. (More details
in this #59585)
This was a stop-gap and not an ideal solution, as this behavior means
`router.refresh()` would effectively behave like reloading the page,
where "stale" segments (ones that went from `__PAGE__` -> `__DEFAULT__`)
would disappear.
This PR reverts that handling. The next PR in this stack (#63608) adds
handling to refresh "stale" segments as well.
Note: We expect the test case that was added in #59585 to fail here, but
it is re-enabled in the next PR in the stack.
Note 2: #63608 was accidentally merged into this PR, despite being a
separate entry in the stack. As such, I've copied the issues from that
PR into this one so they can be linked. See the notes from that PR for
the refresh fix details.
Fixes#60815Fixes#60950Fixes#51711Fixes#51714Fixes#58715Fixes#60948Fixes#62213Fixes#61341
Closes [NEXT-1845](https://linear.app/vercel/issue/NEXT-1845)
Closes [NEXT-2030](https://linear.app/vercel/issue/NEXT-2030)
<!-- 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-2903
