[GH-ISSUE #648] Next.js Route Segment Config (revalidate) is not mapped to Nitro routeRules (SWR) #135

New issue

Closed

opened 2026-05-06 12:37:30 +02:00 by BreizhHardware · 0 comments

BreizhHardware commented

2026-05-06 12:37:30 +02:00

Owner

Originally created by @AhmedElBanna80 on GitHub (Mar 22, 2026).
Original GitHub issue: https://github.com/cloudflare/vinext/issues/648

Describe the bug

In standard Next.js, using Route Segment Configs like export const revalidate = 10 enforces a specific cache lifetime for a page or layout.

When building an application with vinext build, this config is currently ignored and not forwarded to the generated Nitro output. As a result, pages configured with revalidate fall back to fully dynamic execution on every request because Nitro's .output/nitro.json is missing the corresponding routeRules.

Expected behavior

When vinext encounters export const revalidate = X in a page.tsx or layout.tsx, it should automatically extract this and map it to the corresponding Nitro SWR route rule in the final Nitro configuration, allowing the Nitro server/edge runtime to accurately cache the responses natively.

For example, export const revalidate = 10; in /cache-tests/time-based/page.tsx should generate the following in Nitro:

"routeRules": {
  "/cache-tests/time-based": {
    "swr": 10
  }
}

Reproduction

Create a page with export const revalidate = 10; and a Date.now() output.
Build with vinext build.
Start the .output/server/index.mjs Nitro server.
Load the page multiple times.
Observe: The timestamp changes on every single reload, bypassing the 10-second cache configuration entirely.

Workaround

Currently, developers must manually wrap logic inside unstable_cache(..., { revalidate: 10 }) down at the component level to correctly trigger the underlying CacheHandler in vinext, completely bypassing the top-level Route Segment Config paradigm.

Originally created by @AhmedElBanna80 on GitHub (Mar 22, 2026). Original GitHub issue: https://github.com/cloudflare/vinext/issues/648 ### Describe the bug In standard Next.js, using Route Segment Configs like `export const revalidate = 10` enforces a specific cache lifetime for a page or layout. When building an application with `vinext build`, this config is currently ignored and not forwarded to the generated Nitro output. As a result, pages configured with `revalidate` fall back to fully dynamic execution on every request because Nitro's `.output/nitro.json` is missing the corresponding `routeRules`. ### Expected behavior When `vinext` encounters `export const revalidate = X` in a `page.tsx` or `layout.tsx`, it should automatically extract this and map it to the corresponding Nitro SWR route rule in the final Nitro configuration, allowing the Nitro server/edge runtime to accurately cache the responses natively. For example, `export const revalidate = 10;` in `/cache-tests/time-based/page.tsx` should generate the following in Nitro: ```json "routeRules": { "/cache-tests/time-based": { "swr": 10 } } ``` ### Reproduction 1. Create a page with `export const revalidate = 10;` and a `Date.now()` output. 2. Build with `vinext build`. 3. Start the `.output/server/index.mjs` Nitro server. 4. Load the page multiple times. 5. **Observe**: The timestamp changes on every single reload, bypassing the 10-second cache configuration entirely. ### Workaround Currently, developers must manually wrap logic inside `unstable_cache(..., { revalidate: 10 })` down at the component level to correctly trigger the underlying CacheHandler in `vinext`, completely bypassing the top-level Route Segment Config paradigm.