Follow-up to https://github.com/vercel/next.js/pull/72631 this ensures
we properly update the `requestStore` when we detect pure IO case and no
dynamic methods are used like `cookies()` or `headers()` e.g. just a
fetch with no caching opts enabled.
---------
Co-authored-by: Zack Tanner <[email protected]>
## Why?
The example `app-dir-i18n-routing` needs to be updated to v15.
## How?
Run the `next-async-request-api` codemod:
```
pnpm dlx @next/codemod@latest next-async-request-api .
```
- Fixes https://github.com/vercel/next.js/issues/72630
Local builds of Node.js will be considered prereleases e.g. a local build of Node.js will have `24.0.0-pre` as their version. Now these versions are accepted as long as their base version still matches.
### Improving Documentation
- Since the params prop is now a promise, the type of params in the
generateMetadata and Page components has been changed from `{ id: string
}` to `Promise<{ id: string }>`.
---------
Co-authored-by: JJ Kasper <[email protected]>
This ensures we don't incorrectly update the static indicator status
during the dev warmup render which was causing it to show unexpectedly
with dynamicIO enabled.
Adds a `compiler.define` option to next.config.js to statically replace
any variables during build-time for Turbopack. This is similar to
Webpack's `DefinePlugin`.
Relates to: https://github.com/vercel/next.js/discussions/71476
---------
Co-authored-by: Tim Neutkens <[email protected]>
This will be used to gate a rewrite of the client cache that we've just
started. Eventually it should merge with the PPR rollout, but that's
already in active experimentation and we don't want to harm the PPR
rollout. This will also let us incrementally get to parity with the
existing implementation, instead of trying to reach parity in one big
step.
When enabled (and when a route is using PPR), prefetches will use a new
per-segment cache instead of the existing per-page cache.
Using the information byte in a server reference ID, as introduced in
#71463, we can omit unused arguments when calling a `"use cache"`
function. This enables us, for example, to use a cached function in
conjunction with `useActionState` when the function does not need the
previous state, as shown below:
```ts
'use cache'
export async function getCachedRandomValue() {
return Math.random()
}
```
```tsx
'use client'
import { useActionState } from 'react'
import { getCachedRandomValue } from './cached'
export default function Page() {
const [result, formAction] = useActionState(getCachedRandomValue, null)
return (
<form action={formAction}>
<p>{result}</p>
<button>Submit</button>
</form>
)
}
```
Previously, in this use case, a new value would have been rendered for
every click. This is because React passes the previous state and the
form data as arguments into the action function. These two arguments are
then included in the cache key, resulting in a new cache key being
generated for every invocation.
_Note: This optimization is currently based purely on the function
signature. It does not yet detect when a param is declared, but not used
in the function body. It's also not yet applied for server actions._
### What?
Add options for the new backend to disable certain features.
* Storage can be disabled to avoid capturing change log data.
* Dependency tracking can be disabled when no changes are expected and no persistence is used
* Children tracking can be disabled for testing purposes.
Closes PACK-3405
Considering the bound args param in the server reference information byte is required for a client-side optimization of omitting unused arguments to work properly when a server action or `"use cache"` function uses closed-over variables.
The server reference information byte is not used yet, so this PR should not change any observable behavior.
This is a pure refactoring without any behavioral changes. It will allow us to more easily incorporate the presence of the bound args param into the server reference information byte.
### Why?
To customize Image Optimation, the user can use a custom loader, but
that information was out from the related lint error message.
Closes NDX-181
A multi-zone Next.js app might have complex rewrites for its client
assets. For these apps, resolving a source map through the
`/__nextjs_source-map` dev middleware might fail because the asset might
belong to a different app.
Instead of trying to resolve those rewrites (i.e. using `fetch` instead
of `fs`), we can just bypass the source map dev middleware for client
chunks. Because we control how those source maps are generated, we can
safely assume that the `sourceMappingURL` is relative to the filename,
with an added `.map` extension. The browser can just request this file,
and it gets served through the normal dev server, without the need to
route this through the source map dev middleware.
reverts #72258
When performing RSC requests, if the incoming data has a different build
ID than the client, we perform an MPA navigation/refresh to load the
updated build and ensure that the client and server in sync.
Currently we store the build ID in the router state, but becauase it's
always in lockstep with the app instance, it's not actually stateful. We
can store it in a global.
The ID gets assigned as a side-effect during app initialization. It
should never change after being set the first time. In practice, because
setAppBuildId is called before hydration starts, it will always get
assigned to the actual build ID before it's ever needed by a navigation.
(If for some reasons it didn't, due to a bug or race condition, then on
navigation the build comparision would fail and trigger an MPA
navigation.)
The logical flow of how the global is assigned is more convoluted than
it should be because we currently decode the Flight stream inside the
React render phase (via a hook), because that's required to propagate
resource hints correctly. Conceptually it would make more sense to
decode the stream before starting hydration and pass the decoded data to
the root component as props; this would also allow us to block hydration
until the id is set. But we'll need to address the hints problem first.
As a follow up, we should probably do the same thing for the App Router
reducer, which is already a global store in practice but is referenced
and passed everywhere as if it were owned by the React tree.
### What?
Under certain circumstances, the Storage APIs, such as local storage,
are not available.
For example, the Brave browser allows users to block `all cookies`,
which forbids access to local storage.
-
https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage#securityerror
### Why?
When access to local storage fails, the development mode page crashes,
leading to the `Application Error` view.
### How?
Wrap on a try/catch the local storage access done within a use-effect,
under `__NEXT_APP_ISR_INDICATOR`.
There is another local storage access point, but that one is done as
part of `processMessage`, which is called within a `try/catch` block
already.
Fixes#72046
Co-authored-by: JJ Kasper <[email protected]>
This adds `expireTag()` and `expirePath` APIs which are replacing
`revalidateTag` and `revalidatePath`. As such this also marks
`revalidatePath` and `revalidateTag` as deprecated and marked for
removal.
The arguments passed to these methods match `revalidateTag` and
`revalidatePath` with the exception that `expireTag` can receive
multiple tags now as separate arguments which matches our new
`unstable_cacheTag()` API.
We are wanting to update these APIs as `revalidateTag` naming has caused
some confusion as to when the affected items will be updated. The
underlying behavior of `expireTag` is to mark an entry as out of date
and for it to no longer be used so we are expiring it.
If you call `expirePath('/blog/first'`) the next time that item is
requested it is considered expired so the cache will not be used for it
and a fresh entry will be generated. Similarly for `expireTag('posts',
'blog')` the next time any cache with that tag is requested it's
respective cache will not be leveraged and new cache will be populated.
---------
Co-authored-by: Zack Tanner <[email protected]>
Co-authored-by: Delba de Oliveira <[email protected]>
### What?
Make the graph acyclic while condensation graphs so that the self-references do not exist.
We are using `condensation` from `petgraph` and it has `make_acyclic: bool` option. I enabled it to make tree shaking a bit faster.
### Why?
Self-reference in the module graph means slower build and needless runtime operations.
### How?
Closes PACK-3439
This pull request includes several changes to improve cache control
handling and add new test cases for verifying cache headers in the
standalone mode of the application.
Improvements to cache control handling:
*
[`packages/next/src/server/base-server.ts`](diffhunk://#diff-6f4291cc2bfc5073fdca12a014011769e840ee68583db1468acef075f037015aL3295-R3298):
Updated cache control conditions to check for `undefined` explicitly
before setting cache headers.
[[1]](diffhunk://#diff-6f4291cc2bfc5073fdca12a014011769e840ee68583db1468acef075f037015aL3295-R3298)
[[2]](diffhunk://#diff-6f4291cc2bfc5073fdca12a014011769e840ee68583db1468acef075f037015aL3318-R3324)
[[3]](diffhunk://#diff-6f4291cc2bfc5073fdca12a014011769e840ee68583db1468acef075f037015aR3354-R3365)
New test cases:
*
[`test/production/standalone-mode/required-server-files/required-server-files-app.test.ts`](diffhunk://#diff-0d083b6c7bd3a8a3e9c5ee854123ada3b72db58220d8b65912b047b082f834a2R104-R129):
Added test cases to verify that the correct cache headers are sent for
app routes and app pages.
New static and dynamic route handlers:
*
`test/production/standalone-mode/required-server-files/app/api/test/[slug]/route.js`:
Added a new dynamic route handler with forced static generation.
([test/production/standalone-mode/required-server-files/app/api/test/[slug]/route.jsR1-R7](diffhunk://#diff-1cf8a2cfdbb6473656b2456af0267556270fbbaa7ee2c37e2f3e6c6fed1e4d21R1-R7))
*
`test/production/standalone-mode/required-server-files/app/test/[slug]/page.jsx`:
Added a new static page with a revalidation interval and a function to
generate static parameters.
([test/production/standalone-mode/required-server-files/app/test/[slug]/page.jsxR1-R9](diffhunk://#diff-32038443ca3e4f28db37a6543966397682c64cf6f34e6dd03fd8096414d23022R1-R9))
- Fixes https://github.com/vercel/next.js/issues/65814
Co-authored-by: Janka Uryga <[email protected]>
Co-authored-by: Sam Ko <[email protected]>
Early returns should use `anyhow::bail!()`.
Ran ast-grep with
```bash
sg run --lang rust --pattern 'return Err(anyhow!($$$ARGS));' --rewrite 'anyhow::bail!($$$ARGS)' --update-all && sg run --lang rust --pattern 'return Err(anyhow::anyhow!($$$ARGS));' --rewrite 'anyhow::bail!($$$ARGS)' --update-all && cargo fmt
```
Manually cleaned up unused import warnings (second commit) because `cargo fix` hangs (idle, no CPU usage) about halfway through our build, and I'm not sure why. I tested the latest nightly, and it hangs too.
Hi, Team.
I'd like to contribute as removing unnecessary fragments.
I believe that the fragment will create one more grouping node on
virtual dom, which is not necessary on this example.
If it is essential, please kindly let me know why.
Thank you so much for your support.
### Improving Documentation
- remove unnecessary fragment tags
Co-authored-by: Delba de Oliveira <[email protected]>
## Description
Follow up #72391.
I missed some error pages.
### Improving Documentation
- [x] Run `pnpm prettier-fix` to fix formatting issues before opening
the PR.
- [x] Read the Docs Contribution Guide to ensure your contribution
follows the docs guidelines:
https://nextjs.org/docs/community/contribution-guide
Co-authored-by: Delba de Oliveira <[email protected]>
