[GH-ISSUE #860] Track `experimental.prefetchInlining` default flipped to `true` in Next.js #189

New issue

Closed

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

BreizhHardware commented

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

Owner

Originally created by @github-actions[bot] on GitHub (Apr 17, 2026).
Original GitHub issue: https://github.com/cloudflare/vinext/issues/860

Next.js Change

Commit: b301d3c
PR: #92863 — Enable prefetchInlining by default

Next.js flipped experimental.prefetchInlining from false to true in config-shared.ts. This is the first step toward removing the flag entirely.

What changed

The prefetchInlining feature (part of the segment cache work) changes how the App Router client prefetches and caches route segments. Instead of fetching full RSC payloads on navigation, the router inlines prefetched segment data into the initial response, reducing round-trips during client-side navigation.

The config change is a single line:

-    prefetchInlining: false,
+    prefetchInlining: true,

Several tests that were explicitly setting prefetchInlining: true had that line removed (now matches default). Tests not yet compatible were opted out with prefetchInlining: false.

Impact on vinext

vinext should:

Match the new default — ensure prefetchInlining defaults to true (or equivalent) in vinext's config layer, if this config option is surfaced.
Understand the feature — prefetch inlining changes the shape of RSC responses during navigation. If vinext's App Router server generates RSC payloads for navigation, it may need to support the inlined prefetch data format.
Client-side implications — the Next.js router client behavior changes with this flag. Since vinext shims next/navigation and handles client-side routing, any prefetch inlining protocol changes need to be reflected in vinext's client runtime.

This is a default-change, not a new API, so existing vinext apps won't break immediately. But as Next.js moves toward removing the flag entirely, vinext should plan to support this behavior.

Originally created by @github-actions[bot] on GitHub (Apr 17, 2026). Original GitHub issue: https://github.com/cloudflare/vinext/issues/860 ## Next.js Change **Commit:** [`b301d3c`](https://github.com/vercel/next.js/commit/b301d3cfab76fadf3369a40a846cf5a87522194a) **PR:** [#92863 — Enable prefetchInlining by default](https://github.com/vercel/next.js/pull/92863) Next.js flipped `experimental.prefetchInlining` from `false` to `true` in `config-shared.ts`. This is the first step toward removing the flag entirely. ## What changed The `prefetchInlining` feature (part of the segment cache work) changes how the App Router client prefetches and caches route segments. Instead of fetching full RSC payloads on navigation, the router inlines prefetched segment data into the initial response, reducing round-trips during client-side navigation. The config change is a single line: ```diff - prefetchInlining: false, + prefetchInlining: true, ``` Several tests that were explicitly setting `prefetchInlining: true` had that line removed (now matches default). Tests not yet compatible were opted out with `prefetchInlining: false`. ## Impact on vinext vinext should: 1. **Match the new default** — ensure `prefetchInlining` defaults to `true` (or equivalent) in vinext's config layer, if this config option is surfaced. 2. **Understand the feature** — prefetch inlining changes the shape of RSC responses during navigation. If vinext's App Router server generates RSC payloads for navigation, it may need to support the inlined prefetch data format. 3. **Client-side implications** — the Next.js router client behavior changes with this flag. Since vinext shims `next/navigation` and handles client-side routing, any prefetch inlining protocol changes need to be reflected in vinext's client runtime. This is a default-change, not a new API, so existing vinext apps won't break immediately. But as Next.js moves toward removing the flag entirely, vinext should plan to support this behavior.