Currently the edge runtime does not support static generation so this adds a warning when `force-static` is leveraged with `edge-runtime` as it will cause unexpected behavior. Support is being investigated so this isn't a hard error at the moment.
x-ref: [slack thread](https://vercel.slack.com/archives/C03S8ED1DKM/p1684783403551589)
This PR fixes a warning that previous looked like the following:
```
Warning: fetch for [object Request] specified "cache: default" and "revalidate: 60", only one should be specified.
```
Follow-up to https://github.com/vercel/next.js/pull/49628 this updates
the `export const fetchCache` handling and `cache: 'no-store'` handling
as discussed which also aligns with our docs here
https://nextjs.org/docs/app/api-reference/file-conventions/route-segment-config#fetchcache
- `export const fetchCache = 'force-cache'`: forces all fetches to be
cached regardless of `cache: 'no-store'` but cacheable `revalidate`
values still take priority
- `export const fetchCache = 'default-cache'`: ensures fetches are
cached even if they come after a `cache: 'no-store'` fetch but don't
override `cache: 'no-store'` itself.
- without `export const fetchCache`, we still disable fetch cache for
successive fetches after a fetch that does `cache: 'no-store'`
x-ref: [slack
thread](https://vercel.slack.com/archives/C03KAR5DCKC/p1683732826894469)
This ensures we don't fail to return the full body when storing to
fetch-cache in edge-runtime. Also ensures the fetch cache tests are
running for Node.js v16 correctly.
Fetch handling was also failing on Node.js v16 due to react's use of
`res.clone()` being broken with undici which is fixed in the latest
version of edge-runtime so this bumps that.
x-ref: [slack
thread](https://vercel.slack.com/archives/C03S8ED1DKM/p1681310566927429)
This unblocks further optimization opportunities as well as fixes for
systematic problems such as NEXT-227. After this PR, only production
mode of non-app projects will be running on the legacy main process
mode.
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
### What?
Our current logic of detecting if a route allows dynamic params or not
(`fallback`) is flawed, and this PR fixes it.
### Why?
Right now, if no `generateStaticParams` is specified we return
`fallback: undefined` during dev. However, for an app with multiple
params, it may have multiple `generateStaticParams` defined in different
levels. If some level isn't covered by any `generateStaticParams`, we
still can't determine the fallback value.
### How?
I added a naive implementation to check if all params are covered by
`generateStaticParams` in the current or inner layers.
Closes NEXT-946
### What?
Change the caching logic for fetch-cache to only cache successful
responses.
### Why?
Currently fetch-cache will cache any response, without checking the http
status code. But situations like 500 and 304 and others should not be
cached, because we want to re-fetch from the origin.
### How?
Add an extra check before deciding to call `incrementalCache.set()`
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
This ensures we properly honor the `export const fetchCache` config and
also ensures we properly bypass fetch-cache when an On-Demand
Revalidation is occurring.
The `export const dynamic` handling is not changed here as that was
behaving correctly and should not influence fetch cache handling only
whether a page is prerendered fully or treated as SSR.
Fixes: https://github.com/vercel/next.js/issues/47273
x-ref: [slack
thread](https://vercel.slack.com/archives/C042LHPJ1NX/p1679078572123979)
This marks all pages in development as supporting dynamic HTML. Detection for runtime violations of dynamic generation is completed during the production build.
Fixes#46356
fix NEXT-644 ([link](https://linear.app/vercel/issue/NEXT-644))
Co-authored-by: Tim Neutkens <6324199+timneutkens@users.noreply.github.com>
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
This ensures revalidate can be fetch specific instead of cache key
specific and adds a test case to ensure config based revalidate isn't
overridden by fetch based revalidate.
This ensures we leverage the fetch cache when calling
`generateStaticParams` and also ensures paths with
`generateStaticParams` without `dynamicParams = false` don't error when
only partial params are provided.
x-ref: [slack
thread](https://vercel.slack.com/archives/C035J346QQL/p1678149362238089)
This updates to no longer skip caching POST or authed requests with the
fetch cache and instead we bail when `cookies()` or `headers()` is used
prior which is a better heuristic to signal user specific data would be
related to the fetch request.
x-ref: [slack
thread](https://vercel.slack.com/archives/C042LHPJ1NX/p1678130069138849)
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have a helpful link attached, see
[`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
Since it's perfectly valid to do an authorized request during revalidate we shouldn't consider this a reason to throw the static to dynamic error during runtime. If an authorized request is done during build and caching isn't enabled for a path it will still bail from being turned into a Prerender.
x-ref: [slack thread](https://vercel.slack.com/archives/C03KAR5DCKC/p1677734108126679)
## Bug
- [x] Related issues linked using `fixes #number`
- [x] Integration tests added
- [ ] Errors have a helpful link attached, see [`contributing.md`](https://github.com/vercel/next.js/blob/canary/contributing.md)
Follow-up to https://github.com/vercel/next.js/pull/46287 this updates
how we load the cache handler for the incremental cache so it's
compatible with edge and also adds regression testing with a custom
handler.
Updates handling for app dir caching for edge runtime and adds additional tests.
x-ref: NEXT-511
Co-authored-by: JJ Kasper <22380829+ijjk@users.noreply.github.com>
