### What?
When using a `Request` object with fetch, we'll log a warning indicating that using the `cache` property in addition to `revalidate` is unsupported.
### Why?
`Request` sets some defaults on the request init, such as `cache: "default"`. This makes the warning confusing and there's no way to avoid it aside from switching the resource argument to be a URL string instead.
### How?
This keeps existing behavior but omits the log in the case where a request object is used and no explicit cache overrides are specified.
Fixes#58109
### Issue
In the client components world, when you're using `next/dynamic` with `ssr: false` to split chunks in pages of edge runtime, you could get the dynamic imported module still bundled in the server bundle for edge runtime. This could easily hit the bundle limit on edge runtime if you're loading a large size of non-SSR module.
This is caused by the whole chunk is still being included when we're creating the client entry. Since the client entry is imported eagerily, webpack will bundle all the modules under it, unless it's explicitly marked not being included.
### Fix
For client components, SSR rendering layer of bundle, non-SSR `next/dynamic` calls, we're transform the result of `dynamic()` call from to conditional import the dynamic loaded module.
From
```js
dynamic(() => import(...))
```
To
```js
dynamic(() => {
require.resolveWeak(...)
}, { ssr: false })
```
This will only be applied to SSR layer bundle client components non-SSR `next/dynamic` calls and only when webpack is bundling since turbopack doesn't need this. In this way, the server side will be stripped but it can still enter the module graph since we need to traverse if there's SA in client modules with using webpack API `require.resolveWeak`. And for client side bundle will still include the actual module.
Close NEXT-1703
I'm working on a refactor to seed the CacheNodes as soon as the Flight
payload is received, rather than lazily during the render phase. This
means we no longer need to pass a child element prop to LayoutRouter via
childProp.
ChildProp includes two fields: a segment and a child element. The child
element is the part that will soon be removed, because we'll instead
always read from the cache nodes.
But even after this refactor, we still need to pass the segment to
LayoutRouter. So as an incremental step, I've inlined both fields into
separate props:
- childProp.current -> initialChildNode. This will be removed in a later
step in favor of reading from the cache nodes. In fact, we already
always read from the cache nodes — childProp is ignored completely once
the cache node is populated, hence the updated name.
- childProp.segment -> childPropSegment. This probably isn't the best
name anymore but I'll leave renaming until later once more of this
refactor has settled.
---------
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Co-authored-by: @BRKalow <bryce@clerk.dev>
### What?
A number of our customers have been experiencing issues stemming from an
`x-forwarded-host` header that doesn't match the `host` header.
### Why?
[This PR](https://github.com/vercel/next.js/pull/57815) removes
functionality which sets `x-forwarded-host` to `req.headers['host']` and
relies solely on the server's hostname and port.
This can be seen locally when visiting the app via a localhost
subdomain.
The `x-forwarded-host` header will remain as `localhost:${port}` while
the actual requested host will contain the subdomain.
### Related
- https://github.com/vercel/next.js/pull/57815#issuecomment-1808496790
---------
Co-authored-by: BRKalow <bryce@clerk.dev>
Co-authored-by: Zack Tanner <zacktanner@gmail.com>
### What?
When navigating between pages (via `prefetch: false`) within a dynamic
segment, the shared layout is re-rendered. This can cause unexpected
behavior like layout data changing when navigating between child
segments.
### Why?
When prefetch is false, we're currently opting into an "optimistic
navigation" codepath, which will optimistically render layout-routers up
to the point where data is missing, while kicking off data fetches. It
attempts to determine where refetching needs to happen by traversing the
router cache nodes and checking where data is missing. However, it
locates these cache nodes by using "segments" obtained by
[deconstructing the
URL](https://github.com/vercel/next.js/blob/fix/optimistic-bailout/packages/next/src/client/components/router-reducer/reducers/navigate-reducer.ts#L142),
which won't accurately contain dynamic segment data. For ex, `/en` which
corresponds with `/app/[lang]/page.tsx` will have a cache node key of
`lang|en|d`, not `en`. Similarly, the optimistic tree that gets
constructed will also be incorrect, since it uses the URL segment.
### How?
My initial fix was to match the dynamic segment against the segment
constructed by the URL. But after discussion with @sebmarkbage and the
team, it seems more correct to remove the optimistic case all together
as there's no guarantee that the url will actually match to that
segment.
Fixes#50670
---------
Co-authored-by: Tim Neutkens <tim@timneutkens.nl>
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
### What?
Using `revalidateTag` or `revalidatePath` in a route handler will not
currently opt the handler into dynamic behavior. This means that if you
use these APIs and don't opt into dynamic behavior by some other means,
the revalidation call won't do anything as the route handler will be
served statically.
### Why?
During static generation, we do not currently indicate that usage of
these APIs should opt into dynamic usage.
### How?
This updates `revalidateTag` to throw a `DynamicUsageError` (similar to
our other scenarios, such as search params bailout, headers/cookies, or
fetch + revalidate/no-store)
Closes NEXT-1712
This serves to address a few problems as it relates to headers handling within the App Page render pipeline.
1. During static generation, we should not write to the response directly as the revalidation for static responses is performed out of band from the actual request/response as a stale version can be served early. This is partially addressed by modifying the `onHeaders` to only write when there it is not during static generation, but long term I'd hope to see that we can instead pass a immutable request and `null` for the response to help indicate to the render pipeline that it should instead persist the data into the `RenderResult` objects. Alternatively, the response could use a mocked version that would then supersede the `RenderResult` and be used instead.
2. The types for rendering App Pages were merged incorrectly, so this additionally restructures the way that we initialize those renderers such that only the options that are applicable to each renderer is passed down.
Requires vercel/turbo#6388
This uses the structure implemented in vercel/turbo#6388 to support formatted text when reporting. Right now only the `Line` and basic `String` cases are handled.
### What?
Adding a `performance.mark` for next/third-parties for feature measurement
### Why?
We’re working with the Chrome Speed Metrics team to develop an API to better identify specific features used by frameworks and/or CMS platforms. Instead of a entirely new API surface, we've agreed to use `performance.mark` as the signal along with mark_use_counter as a signature.
In the past, we've used HTML attributes for Next which have been helpful, but this will improve the accuracy of our feature detection. In this instance, this will better help us analyze and compare sites that use `@next/third-parties` versus those that don't, and to see if our efforts are actually improving performance.
It's worth noting that this metric will have a public arm, but we're starting to incorporate its usage now to gather early data. performance.mark calls are indeed low-overhead and shouldn't affect loading/rendering performance whatsoever.
The PR is the continuation of #56917 and #57030.
The PR replaces `fs-extra#copy` with Node.js built-in `fs.cp` API (which is almost identical to `fs-extra#copy`, and has been available since Node.js 16). The PR also provides a workaround for flaky Windows `fs.rename` operation (#57030).
cc @styfle @wbinnssmith
### What?
This stops Turbopack from erroring out when trying to parse apps using NextConfig's legacy `experimental.serverActions` boolean value.
### Why?
Old apps may not have removed the legacy boolean flag, but should still run.
### How?
At first I attempted updating Zod's configuration to use a default option config when a boolean was encountered, and passing the updated config to Turbopack, but this would hide the warning message. Then I tried implementing a custom `Deserializer` on the Rust side to handle boolean values and default. But, it was just so much easier to implement with a enum supporting both the current and the legacy configuration.
Closes PACK-1962
### What?
When `FetchCache` is used, cache gets were incorrectly bailing. This would result in unexpected behavior, like continuously revalidating a cache key, as described in #57978.
### Why?
#57902 introduced a refactor to the `FileSystemCache` and changed the interface of `get`, but this change was not propagated to `FetchCache`. Specifically, `fetchCache` was removed in favor of a new type `kindHint`. As a result, cache reads would always short circuit because `fetchCache` would never be defined.
### How?
This updates the interface on `FetchCache` to match what is defined on the base `CacheHandler`. I've also updated the args to both `get` and `set` to be derived from `CacheHandler` so we don't have any type inconsistencies in the future.
I will be following up with a test in the CLI repo to test against a deployed app (since minimalMode cannot be easily mocked in our test suite). Manually verified these changes against the repro in the original issue below, at the following URLs:
https://revalidate-vercel-test-iota.vercel.app/fetch-cache-testhttps://revalidate-vercel-test-iota.vercel.app/revalidate-tag-testFixes#57978Fixes#58306
Previously, the incremental cache returned objects with a readable stream (that were consumed). These can't be shared. Instead, this modifies the cache to instead return strings which are sharable.
This also fixes a bug related to revalidation when writing an updated prefetch RSC payload to the filesystem when PPR is enabled. Previously it just wrote to `.rsc` and now it correctly writes a `.prefetch.rsc` file instead.
