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
### 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
### What
In static generation phase of app page, if there's any case that we're
receiving 3xx/4xx status code from the response, we 're setting it into
the static generation meta now to make sure they're still returning the
same status after build.
### Why
During static generation if there's any 3xx/4xx status code that is set
in the response, we should respect to it, such as the ones caused by
using `notFound()` to mark as 404 response or `redirect` to mark as
`307` response.
Closes NEXT-2895
Fixes#51021Fixes#62228
Recently the serverActionReducer was updated to no longer use React's
thenable type to carry resolution/rejection information. However the
rejection reason was not updated so now when a server action fails we
were rejecting with `undefined` rather than the rejected reason. This
change updates the reject to use the rejection value.
Closes NEXT-2943
This ensures that even if a `loading.js` returns `null`, that we still
render a `Suspense` boundary, as it's perfectly valid to have an empty
fallback.
This was accidentally lost in #62346 -- this brings back the
`hasLoading` prop which will check the loading module itself (rather
than the `ReactNode`) for truthiness, and I've added a test to avoid
another regression.
<!-- 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-2936
### What
* Remove the erroring of force-dynamic is not able to use during static
generation
* Export the route segments properly in sitemap conventions
### Why
We discovered this error is showing up when users are using
force-dynamic with generating multi sitemaps.
When you have a dynamic `route /[id]/route.js` , and you have
generateSitemaps defined which is actually using `generateSitemaps`
under the hood , then you set the route to dynamic with `export dynamic
= 'force-dynamic'`.
We should keep the route still as dynamic. `generateStaticParams` is
only for generating the paths, which is static in build time. And the
`force-dynamic` is going to be applied to each generated path.
Closes NEXT-2881
Followup on https://github.com/vercel/next.js/pull/52520 and
https://github.com/vercel/next.js/pull/54014
**Enhancements**
- Removes `--experimental-test-proxy` CLI argument from `next dev` and
`next start`
- Adds a new experimental config option `testProxy?: boolean`
- Instead of throwing an error, return the `originalFetch` response if
the current request context does not contain the `Next-Test-*` HTTP
headers
**Why?**
These changes allow us to write mixed Integration + E2E tests within the
same Playwright process.
```ts
// some-page.spec.ts
test.describe('/some-page', () => {
test('some integration test', async ({ page, next }) => {
// by using the `next` fixture, playwright will send the `Next-Test-*` HTTP headers for
// every request in this test's context.
next.onFetch(...);
await page.goto(...);
await expect(...).toBe('some-mocked-value');
});
test('some e2e test', async ({ page }) => {
// by NOT using the `next` fixture, playwright does not send the `Next-Test-*` HTTP headers
await page.goto(...);
await expect(...).toBe('some-real-value');
});
})
```
Now I can run `next dev` and locally develop my App Router pages AND run
my Playwright tests against instead of having to,
- run `next dev` to locally develop my change
- ctrl+c to kill server
- run `next dev --experimental-test-proxy` to locally run my integration
tests
---------
Co-authored-by: Sam Ko <sam@vercel.com>
This ensures that the instrumentation hook for Node.js will run
immediately during `next start` instead of waiting for the first request
like does it `next dev`.
However, if there is a separate instrumentation hook for Edge, that will
still be lazy evaluated and wait until the first request.
Fixes#59999
Fixes NEXT-2738
### What
Actions that revalidate the router state by kicking off a refetch (such
as `router.refresh()` or dev fast refresh) would incorrectly trigger an
interception route if one matched the current URL, or in the case of
already being on an intercepted route, would trigger the full detail
page instead.
### Why
Interception rewrites use the `nextUrl` header to determine if the
requested path should be rewritten to a different path. We currently
forward that header indiscriminately, which means that if you were on a
non-intercepted route and called `router.refresh()`, the UI would change
to the intercepted content instead (since it would treat it the same as
a soft-navigation).
### How
This updates various reducers to only forward the `nextUrl` header if
there's an interception route present in the tree. If there is, we want
to refresh its data, rather than the data for the underlying page. The
reverse is also true: if we were on the "full" page, and triggered a
`router.refresh()`, we won't forward `nextUrl` meaning it won't fetch
the interception data.
In order to determine if an interception route is present in the tree, I
had to add a new segment type for dynamic interception routes, as by the
time they reach the client they are stripped of their interception
marker.
**Note: There are a series of bugs related to `router.refresh` with
parallel/interception routes, such as the previous page/slot content
disappearing when triggering a refresh. This does not address all of
those cases, but I'm working through them!**
Fixes#60844Fixes#62470
Closes NEXT-2737
Currently when we generate payloads in app router, the order of RSC
chunks aren't deterministic even if the content stays the same. This
means that any caches that rely on etags for detecting changes in
content aren't able to reliably cache/and avoid invalidating properly.
To avoid this we can manually sort the content before generating the
etag. Eventually this can be fixed upstream in react although that is a
bigger lift so we are doing this for now to alleviate the issue.
x-ref: [slack
thread](https://vercel.slack.com/archives/C042LHPJ1NX/p1709937748240119?thread_ts=1709856182.174879&cid=C042LHPJ1NX)
Closes NEXT-2825
In #61573, I updated the navigation reducer to request a new prefetch
entry if it's stale. But this has the unintended consequence of making
instant loading states effectively useless after 30s (when the prefetch
would have expired). Blocking navigation and then rendering the loading
state isn't ideal - if we have some loading data in a cache node, we
should re-use it.
Now that #62346 stores loading data in the `CacheNode`, we can copy over
`loading` during a navigation.
This PR repurposes `fillCacheWithDataProperty` which wasn't being used
anywhere, to instead be a utility we can use to programmatically trigger
a lazy fetch on a particular segment path by nulling out it's data while
copying over other properties. We could have used the existing util
as-is, but ideally we only have a single spot where lazy fetching can
happen, which currently is in `LayoutRouter`.
When a stale prefetch entry is detected, rather than applying the data
to the tree, this PR will copy over the `loading` nodes and will
"delete" the data so it can be refetched.
<!-- 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-2806
### What?
This fixes more CSS ordering issues with production and webpack dev.
* CSS Modules must not be side effect free as side effect free modules
are per definition order independent which is not true for CSS
* fix order of iterating module references
* disable splitChunks for CSS
* special chunking for CSS with loose and strict mode
* more test cases
Closes PACK-2709
### What?
* Allow to apply webpack loaders depending on "conditions".
* add a few next specific conditions depending on context type
### Why?
Some loaders need different behavior depending on context
### How?
Closes PACK-2748
### What?
* rename test case
* improve error message and handle edge case for require resolving
* fix test case actually testing externals (webpack was silently
bundling, Turbopack showed error that helped to find the broken test
case)
### Why?
### How?
Closes PACK-2662
This ensures we properly set the matched header when applying a
middleware skip optimization so that the client router has enough
context to finish resolving the dynamic route params.
Fixes: https://github.com/vercel/next.js/issues/59561
Closes NEXT-2803
### What
When a route handler uses an API that opts it into dynamic rendering
(such as `no-store` on a fetch), and also specifies a `revalidate` time,
the `revalidate` time is ignored and route is treated as fully static.
### Why
`revalidate: 0` and `revalidate: false` have different semantic
meanings: `false` essentially means cache forever, whereas `0` means
it's dynamic. Since `0` is also falsey, the code we have to fallback
with a default `revalidate` value for route handlers is incorrectly not
marking the route as dynamic, and as a result, caching the route without
an expiration time.
### How
This updates the fallback handling for app routes respect a revalidation
value of `0`, so that the page can properly be marked dynamic.
### Test Explanation
This adds 2 new routes handlers: both have a revalidation time specified
& use `no-store` on a fetch, but only one of them specifies `export
const dynamic = 'force-static'`. The one that doesn't specify
`force-static` is correctly omitted from the prerender manifest. The one
that is `force-static` is correctly in the prerender manifest with the
right expiration time. An additional test case was added to verify that
this data refreshes after the specified interval.
Closes NEXT-2764
Addresses some feedback in #62821. This will re-allow implementations
like:
```js
'use server'
export const f = wrapper(async () => {})
```
Where `wrapper` creates a sync function that returns a promise. Although
it will still be silently converted to an async function under the hood.
Closes NEXT-2790
This ensures we properly catch/handle `generateMetadata` errors during
eager evaluating of nested `generateMetadata` functions in the tree.
Previously if we eager evaluated a child metadata function that threw an
error e.g. `notFound()` and but the parent metadata function took longer
the thrown error would be an unhandled rejection causing the process to
crash depending on the environment.
Fixes: NEXT-2588
Closes NEXT-2786
### What?
make sure that we don't error for dynamic requests on server side.
It will throw at runtime when using a dynamic request.
### Why?
Not all packages are fully bundler compatible, but still work when only
using the parts that work. We don't want to block users from using them
by having an hard compile error.
### How?
Closes PACK-2675
<!-- 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 #
-->
The value `undefined` can be saved to the incremental cache as
`undefined` (`JSON.stringify(undefined)`) with no errors, but when
retrieving it, we attempt to parse it as JSON using
`JSON.parse(undefined)`. This throws an error. We should instead
deserialize `undefined` as `undefined` when retrieving.
relevant discussion: #59087
---------
Co-authored-by: Sam Ko <sam@vercel.com>
### What
Exclude the cases like external urls and relative urls with query from
appending trailing slash when it's needed.
The process is:
- If it's a uncertain string path (relative url, could start with `'./'`
or `/`), convert to relative that starts with `/`;
- then we covert the url (string or URL) to string url
- We do the check if we need to append the trailing slash
### Why
In #62109 we added functionality that can only append trailing slash
when we appended trailing slash to some metadata url like `canonical`
url and open graph url when the config is enabled.
For urls with queries, the trailing slash can also be omitted.
For the external urls (different origin comparing to `metadataBase`) we
don't need to append trailing slash as they're not the same web app.
x-ref: [slack
thread](https://vercel.slack.com/archives/C0676QZBWKS/p1709845946033929)
Closes NEXT-2762
Closes NEXT-2753
Gives the users pathname context on routes that access Dynamic API's so
that if these errors are caught they can modify their code accordingly.
This is a followup to #61332.
Closes NEXT-2695
This upgrades to the latest edge-runtime packages as it includes
exposing `performance`. This was reverted previously as our publishes
were failing with a specific change that has since been removed
upstream.
Closes NEXT-2730
### What
I noticed the font manifest generated by Turbopack was always empty.
Debugging showed that the path to the client_root was always incorrect
when calculating `get_font_paths_from_root`. And also fixed an issue
where for certain paths, the (`/index`) manifest key should contain the
original path.
Closes PACK-2666
We didn't set the property of manifest before, this PR fixes the missing
prop
> If the manifest requires credentials to fetch, the crossorigin
attribute must be set to use-credentials, even if the manifest file is
in the same origin as the current page.
x-ref: https://developer.mozilla.org/en-US/docs/Web/Manifest
Fixes NEXT-2706
As mentioned in the new-added error messages, and the [linked
resources](https://react.dev/reference/react/use-server#:~:text=Because%20the%20underlying%20network%20calls%20are%20always%20asynchronous%2C%20%27use%20server%27%20can%20only%20be%20used%20on%20async%20functions.):
> Because the underlying network calls are always asynchronous, 'use
server' can only be used on async functions.
> https://react.dev/reference/react/use-server
It's a requirement that only async functions are allowed to be exported
and annotated with `'use server'`. Currently, we already have compiler
check so this will already error:
```js
'use server'
export function foo () {} // missing async
```
However, since exported values can be very dynamic the compiler can't
catch all mistakes like that. We also have a runtime check for all
exports in a `'use server'` function, but it only covers `typeof value
=== 'function'`.
This PR adds a stricter check for "use server" annotated values to also
make sure they're async functions (`value.constructor.name ===
'AsyncFunction'`).
That said, there are still cases like synchronously returning a promise
to make a function "async", but it's still very different by definition.
For example:
```js
const f = async () => { throw 1; return 1 }
const g = () => { throw 1; return Promise.resolve(1) }
```
Where `g()` can be synchronously caught (`try { g() } catch {}`) but
`f()` can't even if they have the same types. If we allow `g` to be a
Server Action, this behavior is no longer always true but depending on
where it's called (server or client).
Closes#62727.
### What?
* upgrades turbopack for `getResolve` in webpack loaders
* add missing resolve-url-loader to turbopack for full sass support
Closes PACK-2634
## Description
Refactor the [Next.js
CLI](https://nextjs.org/docs/app/api-reference/next-cli) to use
[commander](https://github.com/tj/commander.js) instead of
[arg](https://github.com/vercel/arg).
## Why?
- Auto-generated, properly formatted help command + output. With `arg`,
much of the help commands were manually added via a single
`console.log`, causing deviations over time.
- Ergonomic, ease of adding new subcommands and rules
## Breaking Changes
- Update the experimental `next experimental-compile` and `next
experimental-generate` build commands in favor of `next build
--experimental-build-mode=compile/generate`
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
## What?
Working on fixing `test/e2e/conflicting-app-page-error`, this adds a
compiler error for the case where App Router routes conflict with Pages
Router routes. It's not 1:1 the same error as in webpack because in the
webpack version we hijacked the App Router resolving logic to assume
there's a certain set of paths, where Turbopack has the full route to
route tree resolving implementation which doesn't assume there's a
single page that can be resolved.
The tests are updated to reflect this change.
<!-- 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-2592
## What?
Migrates the Sass support tests from `test/integration` (legacy test
suite) to `test/e2e`, this way all these tests run against both
development and production, whereas previously most of them would only
run against production.
This is helpful as it ensures the tests are running against Turbopack
too, which is highlighting some missing features in Sass support for
Turbopack.
I've had to rewrite most of the tests to check against the actual
rendered output in the browser instead of CSS output in the `.next`
folder, the majority of these now run regardless of implementation
details.
<details>
<summary>Tests that failed with Turbopack</summary>
```
FAIL e2e/app-dir/scss/url-global-partial/url-global-partial.test.ts (84.9 s)
● SCSS Support loader handling › CSS URL via file-loader sass partial › should render the page
thrown: "Exceeded timeout of 60000 ms for a test.
Add a timeout value to this test to increase the timeout, if this is a long-running test. See https://jestjs.io/docs/api#testname-fn-timeout."
13 | })
14 |
> 15 | it('should render the page', async () => {
| ^
16 | const browser = await next.browser('/')
17 | expect(
18 | await browser.elementByCss('.red-text').getComputedCss('color')
at it (e2e/app-dir/scss/url-global-partial/url-global-partial.test.ts:15:5)
at describe (e2e/app-dir/scss/url-global-partial/url-global-partial.test.ts:7:3)
at Object.describe (e2e/app-dir/scss/url-global-partial/url-global-partial.test.ts:6:1)
FAIL e2e/app-dir/scss/composes-external/composes-external.test.ts (84.765 s)
● CSS Module Composes Usage (External) › should render the module
thrown: "Exceeded timeout of 60000 ms for a test.
Add a timeout value to this test to increase the timeout, if this is a long-running test. See https://jestjs.io/docs/api#testname-fn-timeout."
12 | })
13 |
> 14 | it('should render the module', async () => {
| ^
15 | const browser = await next.browser('/')
16 | expect(
17 | await browser.elementByCss('#verify-yellow').getComputedCss('color')
at it (e2e/app-dir/scss/composes-external/composes-external.test.ts:14:3)
at Object.describe (e2e/app-dir/scss/composes-external/composes-external.test.ts:6:1)
FAIL e2e/app-dir/scss/composes-basic/composes-basic.test.ts (35.629 s)
● CSS Module Composes Usage (Basic) › should render the module
expect(received).toBe(expected) // Object.is equality
Expected: "rgb(255, 255, 0)"
Received: "rgb(0, 0, 0)"
16 | expect(
17 | await browser.elementByCss('#verify-yellow').getComputedCss('color')
> 18 | ).toBe(colorToRgb('yellow'))
| ^
19 | expect(
20 | await browser
21 | .elementByCss('#verify-yellow')
at Object.toBe (e2e/app-dir/scss/composes-basic/composes-basic.test.ts:18:7)
FAIL e2e/app-dir/scss/npm-import-nested/npm-import-nested.test.ts (90.889 s)
● Good Nested CSS Import from node_modules › should render the page
thrown: "Exceeded timeout of 60000 ms for a test.
Add a timeout value to this test to increase the timeout, if this is a long-running test. See https://jestjs.io/docs/api#testname-fn-timeout."
12 | })
13 |
> 14 | it('should render the page', async () => {
| ^
15 | const browser = await next.browser('/')
16 | expect(
17 | await browser.elementByCss('.red-text').getComputedCss('color')
at it (e2e/app-dir/scss/npm-import-nested/npm-import-nested.test.ts:14:3)
at Object.describe (e2e/app-dir/scss/npm-import-nested/npm-import-nested.test.ts:6:1)
FAIL e2e/app-dir/scss/nm-module-nested/nm-module-nested.test.ts (81.941 s)
● Valid Nested CSS Module Usage from within node_modules › should render the page
thrown: "Exceeded timeout of 60000 ms for a test.
Add a timeout value to this test to increase the timeout, if this is a long-running test. See https://jestjs.io/docs/api#testname-fn-timeout."
12 | })
13 |
> 14 | it('should render the page', async () => {
| ^
15 | const browser = await next.browser('/')
16 | expect(await browser.elementByCss('#other2').getComputedCss('color')).toBe(
17 | colorToRgb('red')
at it (e2e/app-dir/scss/nm-module-nested/nm-module-nested.test.ts:14:3)
at Object.describe (e2e/app-dir/scss/nm-module-nested/nm-module-nested.test.ts:6:1)
```
</details>
<!-- 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-2550
---------
Co-authored-by: Tobias Koppers <tobias.koppers@googlemail.com>
## What?
#62528 caused test/e2e/app-dir/not-found/conflict-route to fail
compilation in Turbopack, this compiler error was previously already
reported by Turbopack but Next.js didn't show it, which #62528 resolved.
This PR changes the handling for the not-found handling to be consistent
between development and build, which ensures that the "special" page no
longer conflicts with app/not-found/page.js.
Closes NEXT-2617
Note: this is a reworked iteration of
https://github.com/vercel/next.js/pull/62585 which wasn't sufficient.
<!-- 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?
Do not fail when `useSelectedLayoutSegment` or
`useSelectedLayoutSegments` APIs are called in the Pages Router.
### Why?
This makes migration easier and creates consistency with our other App
Router-specific APIs that inherit the same behavior.
### How?
Similar to #47490, we return `null` if there is no Layout context
(indicating being in Pages Router)
Types are also overridden in the navigation compact module declaration
which kicks in during start to correct the types if we detect a `pages/`
directory.
Note to reviewer: #47490 didn't add a test, so I added one top-level,
let me know if you have a better suggestion for placing.
Closes NEXT-2506
Fixes#61464
### What?
Fixes https://github.com/vercel/next.js/issues/62525
Closes NEXT-2620
Since codes below do not consider searchParams, `redirect` in server
action removes all searchParams passed from client side.
93e4bb823c (diff-c809d50461027cdba7c092e564818b1172133d337abc5c513f829c94c8483dc6R186)
So I just add conditional branch for searchParams.
---
lint, prettier was applied.
Also I have done tests by commands below. and it was all passed.
```
pnpm testonly --testPathPattern "integration" -t "redirect"
```
---------
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
### What?
generateSitemaps function returns a 404 for /sitemap/[id].xml in
production
### Why?
While finding the correct sitemap partition from the array, we check the
param against the id. Which works in dev because id and param are both
without trailing .xml. But it fails in production as param has a
trailing .xml (/sitemap/[id] works in production because it falls back
to dynamic loading and param and id are both without .xml)
### How?
If we are in production environment, check the id with a trailing .xml
because that's whats returned from generateStaticParams, an array of
__metadata_id__ with trailing .xml
Fixes#61969
---------
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
This moves the locale redirect handling out of `base-server` as it
shouldn't be handled here and should be at the routing level. This
avoids the duplicate handling with middleware that causes the incorrect
detection/infinite looping. Test case from separate PR was carried over
to prevent regression.
Fixes: https://github.com/vercel/next.js/issues/55648
Closes: https://github.com/vercel/next.js/pull/62435
Closes: NEXT-2627
Closes: NEXT-2628
---------
Co-authored-by: Nourman Hajar <nourmanhajar@gmail.com>
Co-authored-by: samcx <sam@vercel.com>
### What
Change from processing the file with `next-metatdata-route-loader`
directly into passing the file as loader query, and leave an empty
resource file for it. This will resolve the error that users were seeing
with `manifest.json` convention.
```
Import trace for requested module:
../../../../packages/next/dist/build/webpack/loaders/next-metadata-route-loader.js?page=%2Fmanifest.jso
n%2Froute&isDynamic=0!./app/manifest.json?__next_metadata_route__
getStaticAssetRouteCode page /manifest.json/route this.resourcePath /Users/huozhi/workspace/next.js/tes
t/e2e/app-dir/metadata-json-manifest/app/manifest.json
```
### Why
I looked at the loader process that the final resource processed by
webpack is `json!next-metadata-route-loader...`, which means the builtin
json loader processing json file after the metadata route loader. I
didn't get chance to solve the ordering issue, so I changed the
resourcePath to empty "", and pass the file path as query into the
loader to avoid json-loader processing it after transpilation.
Fixes#59923
Closes NEXT-2630
Closes NEXT-2439
This ensures our dynamic routes that have the same specificity as
`_next/static/:path*` don't get matched unexpectedly when the
`_next/static` asset doesn't exist. We were holding off on making this
change explicit due to compatibility concerns but these are no longer a
concern and the unexpected matching is more of a concern.
Closes: CSM-11
Fixes: https://github.com/vercel/next.js/issues/19270
Closes NEXT-2613
### What
Fixes `redirect()` call under suspense boundary, redirect url should
include the `basePath` in the url.
### Why
`redirect()` under suspense boundaries will go through server html
insertion, which is being used every time by suspense boundary resolved,
new errors will triggered from SSR streaming. It was missing before.
Fixes NEXT-2615
Fixes#62407
### What?
We should treat the warning for CSR bailout the same as the hard-error,
and show the stack trace for either case.
### Why?
It might be useful to track down the source of this warning.
### How?
We have the stack info already, but we only showed it during the error
logging. We should show it for warnings too.
This is similar to #61200
Closes NEXT-2624
### What
When the popstate action is fired (as is the case in a browser back
button), if the page you're going back to has missing cache node data,
the router will crash.
### Why
Almost all router actions will suspend at the app-router level with the
exception of `ACTION_RESTORE`. This was to address an issue where
suspending in the router would add enough delay for browser scroll
restoration behavior not to work.
As a result, when going back to the page with missing data, app-router
wouldn't suspend but layout-router would suspend on the missing data
while triggering a lazy fetch. We trigger a server-patch with the
applied lazy data, but when React replays the render, it will replay the
branch without the cache node data applied. This results in the router
getting caught in a loop of suspending, applying the cache node,
replaying the branch without the cache node, and eventually crashing due
to an error thrown by React to prevent re-suspending indefinitely.
### How
This adds a property to the cache node to signal if the lazy data has
been resolved. If it has been, we won't call the server patch action
again.
Fixes#61336
Closes NEXT-2438
### What
Introduce a `react-server` export condition of `next/navigation`, which
only take effects in RSC layer. And it will only contain `notFound` and
`redirect` related APIs, which can be shared in both server components
and client components environment. This export excludes those APIs
working with React context which are only working in client components.
### Why
We fixed an issue bad alias for react-server condition of react itself
in
https://github.com/vercel/next.js/pull/61522/files#diff-ecb951c8d26893f6d1e4425a873b399d52346ef63eb90fba79d980cef2fabe8cL35
, this was a good fix. But we found that if you're using edge runtime
with `next/navigation` it will error with bundling that you're attempted
to import some client component hooks such as `useContext` from react.
So we introduced a `react-server` version of `next/navigation` that
doesn't interoplate with any client hooks, can we'll bundle that one
instead of original `next/navigation` when you're using it in server
components or app routes.
Closes NEXT-2583
Closes NEXT-2519
Fixes#62187
With Server Actions, a module-level encryption can happen when you do:
```js
function wrapAction(value) {
return async function () {
'use server'
console.log(value)
}
}
const action = wrapAction('some-module-level-encryption-value')
```
...as that action will be created when requiring this module, and it
contains an encrypted argument from its closure (`value`). This
currently throws an error during build:
```
Error: Missing manifest for Server Actions. This is a bug in Next.js
at d (/Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/chunks/1772.js:1:15202)
at f (/Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/chunks/1772.js:1:16917)
at 714 (/Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/app/encryption/page.js:1:2806)
at t (/Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/webpack-runtime.js:1:127)
at 7940 (/Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/app/encryption/page.js:1:941)
at t (/Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/webpack-runtime.js:1:127)
at r (/Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/app/encryption/page.js:1:4529)
at /Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/app/encryption/page.js:1:4572
at t.X (/Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/webpack-runtime.js:1:1181)
at /Users/shu/Documents/git/next.js/test/e2e/app-dir/actions/.next/server/app/encryption/page.js:1:4542
```
Because during module require phase, the encryption logic can't run as
it doesn't have Server/Client references available yet (which are set
during the rendering phase).
Since both references are global singletons to the server and are
already loaded early, this fix makes sure that they're registered via
`setReferenceManifestsSingleton` before requiring the module.
Closes NEXT-2579
This test case was added in #59752, but this doesn't seem like the
correct behavior.
The original PR was intended to be smart about resolving `/default.tsx`
to a route group default (e.g. `/(foo)/default.tsx`) when one wasn't
specified. But since the route group is creating a new hierarchy in the
tree and defines its own layout, if the route group layout doesn't
specify a default, then the not found behavior seems correct.
To fix unexpected not-found behavior in this case, you should specify a
default at the same level as the layout where the missing slot(s) might
be rendered.
Closes NEXT-2565
This onClick isn't actually being used by the test and seems to be
causing a flake unrelated to the test assertions. This removes the
unused code for now so we can still keep the relevant part of the test
in-tact. (Specifically, this test is asserting that we're using the
correct prefetch cache entry for interception routes that originate from
different trees but resolve to the same 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-2568
## Description
We need to manually update the `@capsizecss/metrics` every time it
updates so we get the latest fallback fonts.
## Changes
- https://github.com/vercel/next.js/issues/47115
Closes NEXT-2547
This adds a new span to allow tracking the sum of all client component
loading times for a specific request along with the count of items
loaded.
Closes NEXT-2540
---------
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
### What
When a prefetch cache entry becomes "stale", it'll remain stale until
eventually it gets evicted. However during that stale window, the cache
is never revalidated, and so instant navigations stop working and data
is fetched from origin every navigation.
### Why
The `lastUsedTime` entry on the prefetch cache is currently only updated
after the first read. Once it becomes stale, `applyFlightData`'s
recursive functions will see that there is no longer a reusable prefetch
cache entry, and will trigger a lazy fetch of the new data on every
subsequent navigation.
### How
This updates prefetch cache handling to always ensure we’re using a
fresh or reusable prefetch cache entry. This means that stale prefetch
entries will be refreshed on a navigation event. As a result of this,
I’ve had to disable one of our tests that relies on this stale cache
behavior. It’s not ideal that we’re blocked on the loading boundary when
fetching child segment data—ideally we can refactor this to cache the
loading component in the CacheNode and copy it over on navigations,
similar to how ‘head’ is handled. I’ll work on this in a separate PR.
Note: The new client cache test for this is disabled in PPR for the same
reason as the other tests: auto prefetching with PPR navigations is
currently loading fresh data rather than reusing the prefetch cache.
Fixes#58969Fixes#58723
Closes NEXT-1904
### What & Why
This PR helps fixes a long time tree-shaking issue that if you're import
some identifiers from client components, the whole client component is
being included in the client chunk. Because we're using import eager
mode in webpack to include all the client component modules that make
sure they're present in SSR entry and browser entry when they're
transformed to client reference on RSC layer.
But the way we collect client components is a bit "aggressive" where
contains some spaces to optimize.
### How
We change the collected client components from simpliy collecting it
resolved module request, into collecting both the imported identifiers
(by server components) and the module request. And when we inserted the
used client components imports into the SSR and Client entry, leverage
webpack magic comments `"webpackExports"` to only contain the used
exports in the bundle. Thank you webpack for this nice feature : )
Along the way we also fixed an issue that when you only used default
export, the `default` export itself should also be proxied when the
bundle is in ESM.
#### Notice
There's a limitation yet that it can't work with barrel file, if you
have a shared component `index.js` to re-export the changes several
client components there and you only partially import few from
`index.js` it won't work. For the cases that the node_modules package
contain a barrel file importing multiple client components, please use
[optimizePackageImports](https://nextjs.org/docs/app/api-reference/next-config-js/optimizePackageImports)
config for now. We'll have follow up optimizations
### Testing Result
If we compare the `react-aria-components` the reproduction from #60246,
you'll see the result being optimized a lot:
#### After vs Before
134KB being tree-shaked out 🤯
```
Route (app) Size First Load JS
┌ ○ / 324 B 127 kB
├ ○ /_not-found 872 B 86.5 kB
└ ○ /other-page 174 B 127 kB
```
```
Route (app) Size First Load JS
┌ ○ / 325 B 261 kB
├ ○ /_not-found 870 B 86.5 kB
└ ○ /other-page 176 B 261 kB
```
Fixes#60246
Related report: https://github.com/adobe/react-spectrum/issues/5639
Closes NEXT-2527
phase 1 of NEXT-1799
---------
Co-authored-by: Shu Ding <g@shud.in>
### What?
Fix one assertion about CSS files emitted by turbopack.
### Why?
Turbopack generates `/_next/static/chunks/2225ce._.css`, which does not
match the regex.
Note that it has `._.css`. The previous assertions match on
`[^.]+\.css`, which does not support two dots in the file name.
I tried `/<link rel="stylesheet" href=".+\.css(\?v=\d+)?"/g`, but it
captured 3 `link` tags at once. So I used `/<link rel="stylesheet"
href="[^<]+\.css(\?v=\d+)?"/g`.
### How?
Closes PACK-2413
As discussed almost all webpack plugins shouldn't have issues with this
being enabled by default so removing the default condition where we
disable this optimization due to custom webpack config is more
beneficial and in the rare case a custom plugin has issues it can still
be manually disabled.
Closes NEXT-2523
### What?
* add support for esmExternals in pages
* fix default of esmExternals to true
* fix serverComponentExternalPackages support
* add test case
fixes PACK-2311
fixes PACK-1916
Fixes https://github.com/vercel/turbo/issues/4544
### What?
Fix one assertion about CSS files emitted by turbopack.
### Why?
Webpack generates 3 links with `?v=` query, and 2 extra links without
`?v=` query. Turbopack does not have query string, so we match 5 links.
### How?
Closes PACK-2414
### What
* Narrow down the metadata base warnings only when there's any relative
urls need to be resolved, if there's only absolute urls present, no need
to resolve and we don't warn.
* Polish the error message, updated from "metadata.metadataBase is not
set ..." to "metadataBase property in metadata export is not set ..."
### Why
It will be confusing if we're still show metadataBase warning when
there's no need to set one, since the social image cards only have
absolute urls
Closes NEXT-2426
### What
We should respect the `trailingSlash` config for metadata canonical url,
this PR is adding the handling for strip or keep the trailing slash for
canonical url. Passing down trailingSlash config to metadata resolving
to decide how we handle it.
### Why
The tricky one was `/` pathname, when visiting the origin directly, that
it will always have at least `/` in the URL instance. But for the
default `origin`, it shouldn't show the `/` if the `trailingSlash`
config is `false`. Also it should show trailing slash for all pathnames
if that config is enabled.
BTW there's a `__NEXT_TRAILING_SLASH` env but since we're using the
fixed nextjs runtime module, so this can't be dynamically replaced in
the metadata resolving modules. So we didn't use it
Fixes#54070
Closes NEXT-2424
### What
Following an anchor link to a hash param, and then attempting to use
`history.pushState` or `history.replaceState`, would result in an MPA
navigation to the targeted URL.
### Why
In #61822, a guard was added to prevent calling `ACTION_RESTORE` with a
missing tree, to match other call-sites where we do the same. This was
to prevent the app from crashing in the case where app router internals
weren't available in the history state. The original assumption was that
this is a rare / unlikely edge case. However the above scenario is a
very probable case where this can happen, and triggering an MPA
navigation isn't ideal.
### How
This updates `ACTION_RESTORE` to be resilient to an undefined router
state tree. When this happens, we'll still trigger the restore action to
sync params, but use the existing flight router state.
Closes NEXT-2502
We switched to `pnpm` for testing instead of `yarn` for e2e tests
containing customized node_modules packages, it works with
`node_modules` folder before. Rename the existing `node_modules_bak`
hack to make it easy to test with.
Previously we use `yarn` but it will clean `node_modules` folder so we
have to use another script to copy packages, it's not a required thing
now so we can test package from node_modules directly without renaming
folders locally
Closes NEXT-2496
### What
Disable swc transform optimizer for node_modules in browser layer of app
router bundles
Fixes#61858Fixes#60644Fixes#60920Fixes#61740
Closes NEXT-2418
### Why
In browser there could be not only one runtime, it could have both js
worker and browser. In js worker the `typeof window` is not as same as
in browser, so disabling the swc optimizer which will replace the code.
Leave the condition as it as.
### Why?
I really dislike the way `.chain` works right now, it shouldn't mutate
the `BrowserInterface`, this PR changes it so it's just a pure chain
without weird side effects.
One example with the current version (before this PR):
```
const el = browser.elementByCss('#version-2')
await el.text()
// throws
await el.text()
```
### Additional Changes
- removes selenium (which is completely unused)
- updates playwright
- makes the playwright tracing not error all the time
### What
When a global not found page is rendered, and when the not-found page or
containing layout has a link with `prefetch: auto` back to the root
page, the router would update the URL but not correctly swap out the
not-found component with the page component.
### Why
With auto prefetching (which is the default when `prefetch` is left
unspecified on a link), the router will perform a partial prefetch on
dynamic pages. This means it'll fetch the flight data _without_ React
nodes and store it in the prefetch cache. On navigation, this is used to
determine where we already have cached React nodes and where we need to
trigger a lazy fetch to get new data. However, global not found pages
are peculiar in that they will always contain a data path like: `['', {
children: ['__PAGE__', {}] }]` since they are inserted at the root. This
means that if there's also a page component that corresponds with the
same path, the router will incorrectly think it already has cache node
data for it.
### How
During SSR when the `asNotFound` flag signals to the renderer that the
component we're rendering is matching the global not-found page, we
modify the segment key to be something unique so the data path won't
collide with a top-level page.
In
[fc01c8e](fc01c8e7f7)
I added handling only on the server to modify the segment key. This
still fixes the issue, but at the cost of triggering an MPA navigation
on the client because it's treated as a root layout change
In
[69d5687](69d5687765)
I added client handling to not treat this special segment key as a root
layout change, and to signal to the router it needs to refetch the data.
This ensures we don't do an MPA navigation.
Fixes#61956
Closes NEXT-2481
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
Moved app-dir path params parsing logic from `useParams` to `AppRouter`.
This allows for the use of `PathParamsContext` in the `useParams` hook
for both pages and app routers. In addition, this allows for memoization
of the layout tree which fixes undesired re-renders of the `useParams`
hook.
Fixes [#58788](https://github.com/vercel/next.js/issues/58788)
Closes NEXT-2434
---------
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
### What
Fix the externals resolving for server rendering layer for app router.
For SSR requests, if it's next externals, we resolved and return early,
if we didn't resolve, keep going through the following externals
resolving
### Why
Previously on app router's SSR bundling layer, we didn't go through the
following requests when seeing an server external package, it will keep
bundling even it's in server components external packages.
A bug found in #61983
Closes NEXT-2473
### What
When navigating back to a page that you had already loaded, it currently
results in a prefetch cache miss and will re-trigger any data
fetching/loading despite it being available.
### Why
When creating the initial router state, the prefetch cache is
initialized to an empty map.
### How
This uses the `initialTree` passed from the server to seed the cache for
that route with flight data.
Closes NEXT-2001
### What
Prefetches to pages within a shared layout would frequently cache miss
despite having the data available. This causes the "instant navigation"
behavior (with the 30s/5min TTL) to not be effective on these pages.
### Why
In #59861, `nextUrl` was added as a prefetch cache key prefix to ensure
multiple interception routes that correspond to the same URL wouldn't
clash in the prefetch cache. However this causes a problem in the case
where you're navigating between sub-pages. To illustrate the issue,
consider the case where you load `/foo`. This will populate the prefetch
cache with an entry of `{foo: <PrefetchCacheNode}`. Navigating to
`/foo/bar`, with a link that prefetches back to `/foo`, will now result
in a new cache node: `{foo: <PrefetchCacheNode>, /foo/bar%/foo:
<PrefetchCacheNode>}` (where `Next-URL` is `/foo/bar`). Now we have a
cache entry for the full data, as well as a cache entry for a partial
prefetch up to the nearest loading boundary. Now when we navigate back
to `/foo`, the router will see that it's missing data, and need to
lazy-fetch the data triggering the loading boundary.
This was especially noticeable in the case where you have a route group
with it's own loading.js file because it creates a level of hierarchy in
the React tree, and suspending on the data fetch would result in the
group's loading boundary to be triggered. In the non-route group
scenario, there's still a bug here but it would stall on the data fetch
rather than triggering a boundary.
### How
In #61794 we conditionally send `Next-URL` as part of the `Vary` header
if we detect it could be intercepted. We use this information when
creating the prefetch entry to prefix it, in case it corresponds with an
intercepted route.
Closes NEXT-2193
### What
When navigating to a page that uses a loading boundary + parallel route,
an empty white screen would be displayed rather than the loading state /
final state
### Why
With parallel routes, the RSC data is an array of data paths, each
corresponding with one of the parallel segments rendered on the page.
During the navigation event, when we iterate over this data, we call
`applyFlightData` with this data path & an empty cache node.
`applyFlightData` checks to see if the flight data contains cache nodes
("seed data"). If it doesn't, then that means it has no work to do, and
it bails out. Pre-PPR and in the case of having a `loading.js` file,
`walkTreeWithFlightRouterState` doesn't return any seed data, just
router state. This means that `applyFlightData` will not have any work
to do on the new cache node, and leaves it untouched.
Once `applyFlightData` is finished, but while still in the flight data
path loop, we reassign `currentCache` to the empty cache object we
created prior to `applyFlightData`. But since that cache node has
remained empty, the next iteration of the loop is going to be inspecting
a now empty cache, rather than the actual "current" cache. Now there's
no existing cache to copy into the new cache. The app now doesn't know
about any cache nodes.
### How
It doesn't seem like we should be re-assigning `currentCache` to the new
cache. In the context of a navigation, it seems more accurate to always
assume `currentCache` is the cache _now_, since it won't actually be
applied to the state until the action has finished (`mutable.cache` is
currently taking care of this).
Closes NEXT-2223
Fixes#61080
followup to: https://github.com/vercel/next.js/pull/60645
### Background
When prerendering the determination of whether a prerender is fully
static or partially static should not be directly related to whether
there is a postponed state or not. When rendering RSC it is possible to
postpone because a dynamic API was used but then on the client (SSR) the
postpone is never encountered. This can happen when a server component
is passed to a client component and the client component conditionally
renders the server component.
Today if this happens the entire output would be considered static when
in fact the flight data encoded into the page and used for bootstrapping
the client router contains dynamic holes. Today this is blocked by an
error that incorrectly assumes that this case means the user caught the
postpone in the client layer but as shown above this may not be the
case.
### Implementation
A more capable model is to think of the outcome of a prerender as having
3 possible states
1. Dynamic HTML: The HTML produces by the prerender has dynamic holes.
we save the static prelude but expect to resume the render later to
complete the HTML. This means we will resume the RSC part of the render
as well
2. Dynamic Data: The HTML is completely static but the RSC data encoded
into the page is dynamic. We don't want to resume the render but we do
need to produce new inlined RSC data during a Request.
3. Static: The HTML is completely static and so is the RSC data encoded
into the page. We save the entire HTML output and there will be no
dynamic continuation when this route is visited.
Really 1 & 3 are the same as today (Partially static & Fully Static
respectively) but case 2 which today errors in a confusing way is now
supported.
In addition implementing the Dynamic Data case the old warning about
catching postpones is removed. The reason we don't want this is that
catching postpones is potentially a valid way to do optimistic UI. We
probably want a first-party API for it at some point (and maybe we'll
add the warning back in once we do) but imagine you do something dynamic
like look up a user but during prerender you want to render as if the
user is logged out. you could call `getUser()` in a try catch and render
fallback UI if it throws. In this case we'd detect a dynamic API was
used but we wouldn't have a corresponding postpone state which would put
us in the Dynamic Data case (2).
Another item to note is that we can produce a fully static result even
if there is a postponed state because users may call postpone themselves
even if they are not calling dynamic APIs like headers or cookies. When
this happens we don't want to statically capture a page with postponed
boundaries in it. Instead we immediately resume the render and abort it
with a postponed abort signal. This will cause the boundaries to
immediately enter client render mode which should speed up recovery on
the client.
#### Technical Note
Another note about the implementation is that you'll see that regardless
of which case we are in, if there is a postponed state but we consider
the page to be Dynamic Data meaning we want to serialize all the HTML
and NOT do a resume in the dynamic continuation then we immediately
resume the render with and already aborted AbortSignal. The purpose here
is to mark any boundaries which have dynamic holes as being
client-rendered.
As a general rule if the render produces a postponed state we must do
one of the following
1. save the postponed state and ensure there is a dynamic continuation
that calls resume
2. immediately resume the render and save the concatenated output and
ensure the dynamic continuation does NOT call resume.
or said another way, every postponed state must be resumed (even if it
didn't come from Next's dynamic APIs)
#### Perf considerations
This PR modifies a few key areas to improve perf.
Reduces quantity of *Stream instances where possible as these add
significant overhead
Reduces extra closures to lower allocations and keep functions in
monomorphic form where possible
Closes NEXT-2164
In #61794, the routes manifest is used to find the interception route rewrites in `next-server` and computed on the fly in `next-dev-server` based on `appPaths`.
The edge runtime doesn't have access to the routes manifest nor a full list of app paths. This writes an entry for the edge runtime to make the interception routes readable, and adds plumbing to return them in the `getInterceptionRouteRewrites` handling in `web-server`. This is what we use to signal to the server whether to return ‘Next-URL’ in the Vary for RSC requests.
This piggybacks on the existing interception routes test but adds an edge runtime case.
Closes NEXT-2304
To ensure that we properly cache data for routes that change based on `Next-URL` (which is used for route interception), this adjusts how we set the `Vary` header to conditionally include `Next-URL`.
The `Next-URL` request header only impacts the response for routes that are intercepted. When we detect that path we're handling could be intercepted, we add `Next-URL` to the vary. This signals in #61235 to prefix these cache entries with `nextUrl` if the response might vary based on it.
Closes NEXT-2398
### What
Exclude precompiled react packages from browser layer loaders coverage.
### Why
Since we're transpiling all the browser layer code now after #59569,
then SWC will also compile react. But when it compiles
`react.production.min.js` it gives me with the code and ESM helper
inserted
```js
import { _ as _type_of } from "@swc/helpers/_/_type_of"; // This is not correct
var l = Symbol.for("react.element"), n = Symbol.for("react.portal"), p = Symbol.for("react.fragment"), q = Sym
bol.for("react.strict_mode"), r = Symbol.for("react.profiler"), t = Symbol.for("react.provider"), u = Symbol.f
```
This makes bundler think it's a ESM package but actually it's CJS, which
converts the module into `{ default: .., __esModule }` instead of the
original react module.
When you're using `React.useEffect` or other API through namespace
import (`import * as React from 'react'`), this will break the module
exports check in bundling as the property doesn't directly attached to
the module now. This PR disabled the transform for precompiled react
packages now and will see the deeper issue in next-swc side later.
Fixes#60890Fixes#61185
Closes NEXT-2362
### What?
depends on https://github.com/facebook/react/pull/28108
* fixes CSS Ordering issues due to CSS duplication in production mode
* The issues still happen in dev mode
* Highlights broken CSS Ordering for more dev cases, e. g. CSS in client
components
Closes PACK-2300
### What
This adds support for navigation signals like `notFound()` and
`redirect(url)` when Partial Prerendering has been enabled.
### Why
Navigation API's like `notFound()` and `redirect(url)` throw errors in
order to interrupt the rendering of components. When a page both invokes
API's that cause the render to be marked as dynamic (like
`unstable_noStore()`) and also a navigation API, these errors may race
to the end. In the case where the navigation error does not beat out the
error emitted by dynamic API's will still trigger the detection warning
that's present to warn you about situations where you may have
accidentally caught the error.
### How
This resolves this issue by explicitly checking for navigation signals
(errors) thrown during the render, and not displaying the "caught
dynamic API" error and console warning.
Closes NEXT-2037
### What & Why
We have a modularize imports config for `next/server` before, which will
transform the `next/server` imports to directly import from the actual
file, for instance: `import { NextRequest } from 'next/server'` will
become `import { NextRequest } from
'next/dist/server/web/exports/next-request'`, where the NextRequest is
exported as default export. This is fine in most case until you're using
a ESM pkg, then it will be resolved as `{ default: NextRequest }`
according to the spec. Since it's a ESM import to a CJS module in
`next/dist`.
Since we already have the ESM alias introduced in #59852 , this can
handle the case more properly.
### How
Remove the modularize imports config for `next/server`, use the ESM api
alias instead.
Migrate the cjs optimizer tests from middleware to a separate endpoint
`/cjs/server`. As now ESM imports for next/server are not going to get
tree-shaken in dev, but since we don't have image response there it's
still fine.
Closes NEXT-2376
Closes NEXT-2374
### What
When navigating to a page with dynamic params using a certain casing,
and then following a link to another page using _different_ casing for
the same param, the router would get stuck in an infinite suspense
cycle.
### Why
On the client we normalize cache keys by lowercasing the values for
dynamic segments. However the RSC data for each segment wouldn't have
this same casing logic applied. This is causing the router to not
recognize that there is already RSC data available for that segment,
resulting in an infinite suspense cycle.
### How
The `toLowerCase()` logic shouldn't be needed here. Technically we could
leave this in place and update `matchSegment` to also apply the
lowercase logic, but currently there are too many utility functions that
parse segments to comfortably make that change. I confirmed that the bug
related to why we lowercased these router cache keys is no longer
present after making this change.
Fixes#61722
Closes NEXT-2377
### What
Client-side transitioning to a page that triggered a loading boundary
with async metadata would cause the transition to stall, potentially
getting stuck in a refetch loop.
### Why
In layout-router, we trigger a "lazy fetch" when we encounter a segment
that we don't have cache nodes for. This calls out to the server and
suspends until the data fetch is resolved, and applied to the router
tree. However after suspending but before updating the client router, we
set `childNode.lazyData` to null. When we unsuspend from the server
patch action, `childNode.rsc` might still be missing and clearing
`lazyData` means we've blown away the reference to the fetch we already
had pending, triggering a refetch loop.
### How
This removes the logic that mutates the cache node in render, as this is
not concurrent safe, and doesn't appear to be needed for anything.
Fixes#61117
Closes NEXT-2361
---------
Co-authored-by: Jiachi Liu <inbox@huozhi.im>
### What
#### Core
This PR respect the error's digest when recieves new error occurred from
server side, and it will be logged into client on production with the
same `digest` property.
If we discover the original RSC error in SSR error handler, retrieve the
original error
#### Tests
* Move the errors related tests from `test/e2e/app-dir/app` to a
separate test suite `test/e2e/app-dir/errors`
* Add a new test case for logging the original RSC error
* Add a new test case for logging the original Server Action error
### Why
This will help associate the `digest` property of the errors logged from
client with the actual generated server errors. Previously they're
different as we might re-compute the digest proper in handler that react
server renderer thinks it's a new error, which causes we have 2
different errors logged on server side, and 1 logged on client side. The
one on client side can associate to the server errors but it's from
react renderer which is not the original error.
Closes NEXT-2094
Fixes#60684
### What
When attaching a rejection listener to a server action promise, in the case of network errors, the rejection handler would be skipped and it'd throw an error that crashes the application.
### Why
When we refactored these reducers to no longer suspend, it caused the rejection handling logic we have to no longer make sense. In this case we're working with a native promise that won't have a `status` property, so we'd re-throw the error and not call `reject`.
### How
This removes the special status handling logic and makes the rejection handler always call `reject` with the error. This will either be handled by user code or let the error bubble to an error boundary.
I also cleaned up some mutable code that is no longer needed now that these reducers aren't replayed.
Closes NEXT-1715
Closes NEXT-2323
Fixes#58638
### What
When using a default slot that re-exports another page, the CSS entries
(and presumably other client reference modules, like JS entries) that
correspond with the re-exported page won't be loaded, resulting in CSS
styles not being applied.
### Why
`next-app-loader` constructs the path to the default segment but special
cases the `children` slot (which is used as the page), to mark the
segment as an empty string. This is so that the parallel default file
can be loaded. However the way that `defaultPath` is constructed, it
assumes that `actualSegment` won't be an empty string, and constructs an
invalid path like so:
`app/example//default.tsx`
When we go to look up the JS/CSS entries from the client reference
manifest, the key will be incorrect and so it won't find the files for
it, resulting in this bug.
### How
This moves the `/` delimiting to be part of the creation of the
`actualSegment` variable so that we only append it when we know we
aren't setting it to be an empty string.
Fixes#52245Fixes#49871
Closes NEXT-2309
Closes NEXT-2310
When using `next/dynamic` in server components to load a client
component with named export, we shouldn't dot into the prop name since
client component reference as it's already a valid react component type.
It would work with `default` prop but not other named exports.
Let's say `mod` is a dynamic imported module
```
mod.Button.default
```
will become the client reference key
```
mod#Button#default
```
Which means in module `mod`, get `Button` export, then `default`
property of it, which is wrong but it's a valid key in the client
reference roxy.
This PR checks if they're client module, then return itself as dynamic
imported component type for `next/dynamic` if it is one.
Fixes#61046
Closes NEXT-2229
