[pull] canary from vercel:canary#886
Merged
pull[bot] merged 8 commits intocode:canaryfrom Mar 17, 2026
Merged
Conversation
## Background Next.js has an existing global config, `experimental.staleTimes.dynamic`, that controls how long the client-side router cache retains data from dynamic navigation responses. By default this is 0 — meaning dynamic data is always refetched on every navigation. Some users set this to a higher value (e.g. 30 seconds) so that navigating back to a recently visited page reuses the cached response instead of making a new request. The limitation of the global config is that it applies uniformly to every page in the app. Users have asked for the ability to set different stale times for different pages — for example, a dashboard page that should always show fresh data vs. a product listing page where it's acceptable to show slightly stale data for a smoother navigation experience. ## What this PR adds `export const unstable_dynamicStaleTime` is a per-page version of `staleTimes.dynamic`. It accepts a number in seconds with the same unit and semantics, but scoped to a single page. When present, it overrides the global config for that page — whether the per-page value is larger or smaller than the global default. Static and cached responses are unaffected. When parallel routes render multiple pages in a single response, the minimum value across all parallel slots wins, consistent with how stale times compose generally. Exporting this from a layout is a build error (pages only). ## Relationship to Cache Components The recommended way to control data freshness in Next.js is to use Cache Components (`"use cache"`) with `cacheLife`. This API exists as a simpler migration path for apps that are already using `staleTimes.dynamic` and haven't yet adopted Cache Components. It's prefixed with `unstable_` not because the implementation is unstable, but because it's not the recommended long-term idiom — apps should migrate to Cache Components for more granular and composable control over data freshness. Based on the design from #88609. Co-authored-by: Jimmy Lai <laijimmy0@gmail.com> Co-authored-by: Sam Selikoff <sam.selikoff@gmail.com>
…ting lock (#91250) Co-authored-by: Cursor Agent <cursoragent@cursor.com>
This PR adds `unstable_catchError()` API for a granular custom error boundary. The error component generated by this API is not a true component format, as the wrapper provides additional args. Therefore, the API is a function call by design rather than a boundary component to avoid merging the `errorInfo` with the user-provided props from the wrapper. This API works for both the App/Pages Router. However, `retry()` is not allowed in Pages Router as it depends on `router.refresh()`, and will throw. Also, it's exported from `next/error` as there was already an `Error` component for the [Pages Router](https://nextjs.org/docs/pages/building-your-application/routing/custom-error#reusing-the-built-in-error-page). ### DevTools <img width="508" height="90" alt="CleanShot 2026-03-13 at 03 02 46@2x" src="https://github.com/user-attachments/assets/8b79b1f6-877d-4901-99f7-6a2b4d3e34fe" /> Docs to follow up: #89847 Closes NAR-768 --------- Co-authored-by: Josh Story <story@hey.com>
This enables server HMR (formally, this is called server fast refresh) by default for app router pages. For now, it's still disabled for routes and middleware even with app router. - Replaces `--experimental-server-fast-refresh` with `--no-server-fast-refresh` to opt out - Updates telemetry to record `feature.serverFastRefreshDisabled` when the disable flag is passed - [x] Verify `next dev` enables server HMR by default (Turbopack, app dir, non-edge routes) - [x] Verify `next dev --no-server-fast-refresh` disables it - CI
…`, and run rustdoc as part of our CI checks (#91339) This gets `cargo doc` clean, and enables it in CI so that we won't regress it (I'm open to removing this if it proves to be annoying). I also cleaned up some documentation and even found some dead code (deleted `turbopack/crates/turbopack-dev-server/src/source/conditional.rs`).
… sensitive origins (#91479) See: GHSA-jcc7-9wpm-mj36 and [16.1.7](https://github.com/vercel/next.js/releases/tag/v16.1.7) Co-authored-by: Sebastian "Sebbie" Silbermann <sebastian.silbermann@vercel.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
8 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )