next-cache-components-adoption

Migrates Next.js App Router projects to Cache Components and resolves blocking-route build errors.

Updated Aug 5, 2024
One-click install
npx skills add https://github.com/SethyRung/movie-next --skill next-cache-components-adoption-sethyrung
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: next-cache-components-adoption
Source: https://github.com/SethyRung/movie-next/tree/main/.agents/skills/next-cache-components-adoption
Command: npx skills add https://github.com/SethyRung/movie-next --skill next-cache-components-adoption-sethyrung

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Enabling Cache Components in a Next.js app floods the build with blocking-prerender and instant-validation errors, and fixing them route by route without a plan is slow and error-prone. This Skill sequences the entire adoption: flipping the cacheComponents flag, running the cache-components-instant-false codemod, and walking every route to a passing build with browser verification. ## Core Features & Use Cases - Strategy selection: Choose between an incremental path (codemod opts every route out with export const instant = false, ship a quiet PR, then adopt feature by feature) or a direct path (fix whatever the build flags first). - Guided error resolution: Diagnose the three blocker classes — request-time reads (cookies(), headers(), await params), sync-IO calls (Date.now(), Math.random()), and "use cache" files reading request data — using the docs page linked from each error. - Runtime verification: Verify each fix in a real browser via the next-dev-loop skill, confirming the static shell renders and <Suspense> fallbacks resolve, not just that the build passes. - Use Case: You upgrade a Next.js 16.3 app, set cacheComponents: true, and the build fails on dozens of routes. The Skill runs the codemod, fixes sync-IO blockers in shared layouts, then removes opt-outs one feature at a time until grep finds no remaining TODO: Cache Components adoption comments. ## Quick Start Ask the agent to enable Cache Components in your Next.js app and work through the blocking routes until the build passes.

Frequently Asked Questions about next-cache-components-adoption

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I enable Cache Components in a Next.js app?

Set cacheComponents: true in next.config, then run npx @next/codemod@latest cache-components-instant-false ./app to opt every page and layout out of validation. Fix remaining sync-IO blockers the codemod cannot handle, confirm the build passes, then remove opt-outs feature by feature.

How to fix blocking-prerender errors in Next.js?

Blocking-prerender errors come from request-time reads like cookies(), headers(), or awaited params outside a Suspense boundary. Push the read into a Suspense-wrapped child component, forwarding param promises instead of awaiting them at the page top, and follow the docs page linked in each error.

Does Cache Components work with the Next.js Pages Router?

No, Cache Components is an App Router feature and the cacheComponents flag does nothing for pages/ routes. A hybrid app works fine since the flag only affects app/ routes, but a pages-only project requires a full Pages-to-App migration first.

What Next.js version is required for Cache Components?

Next.js 16.3 or later is required, since that release adds top-level cacheComponents, export const instant, dev-overlay validation warnings, and the cache-components-instant-false codemod. Older versions should upgrade via npx @next/codemod@latest upgrade latest first.

Why does the build still fail after adding instant = false?

Sync-IO calls like new Date(), Date.now(), Math.random(), and crypto.randomUUID() fail the build even with instant = false, since the opt-out does not suppress them. Fix them with the await connection() plus Suspense pattern from the error's docs page, especially in shared layouts.

When should I keep instant = false instead of removing it?

Keep it when a route is genuinely per-request with no useful static shell, or when the refactor is too large to take on now. Confirm with the user and rewrite the TODO comment into a documented reason, since an undocumented leftover opt-out is not a valid end state.