### What?
Pages marked with `generateStaticParams` don't currently support server actions, and instead return a 405 Method Not Allowed, with no action being taken on the client. Additionally, pages that are marked static & use server actions are opted into dynamic rendering.
### Why?
The page that has `generateStaticParams` is marked as `isSSG` [here](ee2ec3dd1d/packages/next/src/server/base-server.ts (L1337)).
As a result, the request is short-circuited because a POST request isn't supported on static pages. Upon detecting a server action on a page marked SSG, we bypass the static cache and go straight to the lambda.
This PR introduces an experimental option to the prerender manifest that will allow for selectively bypassing the static cache
This also removes the need to bail out of static generation
Closes NEXT-1167
Closes NEXT-1453
Fixes#49408Fixes#52840Fixes#50932
Optimizes how we handle cache tags for soft tags (auto-added by Next.js)
and normal tags (added manually) and adds differentiating between
`revalidatePath('/blog/first')` and page/layout.
Soft tags are not stored across cache entry and instead auto sent along
when checking cache entries. This allows us to prevent storing
exponential amounts of tags across cache entries while still having the
relationship between them so that single path revalidation can work
properly.
x-ref: [slack
thread](https://vercel.slack.com/archives/C042LHPJ1NX/p1690586837903309)
Adding a default app router not-found error page in production. We introduced a custom global not-found page if you have `not-found.js` file under app directory. Next.js will still routed you to default pages 404 if there's no routes matched when you don't have a custom `not-found.js`.
This PR creates a default layout (only having `html` and `body`) and will use the default not-found component as children to build a default 404 page for app router, and server will route to that page when there's any app router pages existed. This will also fix the hmr issue that when you hit a pathname doesn't exist, nextjs will compile `/_error` for you which is not expected, now we're using `/not-found` instead
Closes NEXT-1359
Transitions the App Pages renderer into the entrypoint bundle.
- Adjusts the static path detection to handle route module's with App Pages
- Fixes bug in font manifest loading on Edge
This PR changes client manifest generation process. Instead of one big
manifest file that contains client references for the entire app, we're
now generating one manifest file per entry which only covers client
components that can be reached in the module graph.
Updates to not throw the dynamic server error inside of the patched
fetch as it's typical for fetch errors to be caught and handled and this
error is not meant to be caught by users. This instead throws it during
rendering so we can ensure we catch it instead of users.
x-ref:
https://github.com/vercel/next.js/actions/runs/5182384027/jobs/9339123096
## What?
Currently we use the initial compile to add entrypoints that we know are
going to be used in the application. For example the Next.js runtime,
`react`, `react-dom`, and such. While this was the right default when
Next.js only had `pages`, it's no longer true when both `pages` and
`app` exist. E.g. when you're working on a page using App Router we'd
still compile `pages/_app`, `pages/_document`, and `pages/_error` even
though those would not be used. In case of larger applications (e.g.
Vercel's application) this would mean thousands of extra modules being
compiled even though you don't need them for the page you're looking at.
Similarly we'd compile the Next.js runtime for App Router even when
you're only using `pages`.
This PR changes the handling to only compile the entries that are needed
for the current set of visited pages (on-demand-entries). If that set
only includes `app` entrypoints then the `pages` related files will be
excluded. If the set contains both `app` and `pages` both will be
included. Similarly for `amp`, if you don't use `amp: true` / `amp:
hybrid` the development runtime will not be compiled.
📔 Note: This is specifically for webpack, Turbopack already compiles
everything needed lazily so it didn't have this limitation.
#### Before
```
- event compiled client and server successfully in 1079 ms (306 modules)
- event compiled client and server successfully in 155 ms (306 modules)
```
With opening `/`:
```
- event compiled client and server successfully in 1118 ms (306 modules)
- event compiled client and server successfully in 157 ms (306 modules)
- event compiled client and server successfully in 599 ms (486 modules)
```
Total: 1.874ms (Note: This number is much higher when `pages/_app`
imports many modules).
#### After
```
- event compiled client and server successfully in 118 ms (20 modules)
- event compiled client and server successfully in 65 ms (20 modules)
```
📔 Note: opening the page then causes the Next.js / React runtime to be
compiled ofcourse
```
- event compiled client and server successfully in 115 ms (20 modules)
- event compiled client and server successfully in 57 ms (20 modules)
- event compiled client and server successfully in 1137 ms (361 modules)
```
Total: 1.309ms (Note: This number is not affected by`pages/_app`
importing many modules).
## How?
We can only apply this optimization after we've looped over the list of
on-demand entries, as that has the required metadata. Hence why I went
with deleting the keys for each respective type of entrypoint (`pages`,
`app`, `amp`).
<!-- 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 or adding/fixing 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 #
-->
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
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)
