New
Codemod Registry
Explore community-led codemods to migrate, optimize, and transform your codebase.
+600 codemods published
Ready to contribute?
Build your own codemod and share it with the community.
Explore community-led codemods to migrate, optimize, and transform your codebase.
Build your own codemod and share it with the community.
Explore community-led codemods to migrate, optimize, and transform your codebase.
Transform Next.js app router page components to use typed routes
This is a [codemod](https://codemod.com) created with [```codemod init```](https://docs.codemod.com/deploying-codemods/cli#codemod-init). ## Using this codemod You can run this codemod with the following command: ```bash npx codemod use-client-added ``` ### Before ```ts const toReplace = "hello"; ``` ### After ```ts const replacement = "hello"; ```
Configure staleTimes in next.config.js This guide refactors the next.config.js file to introduce staleTimes configuration options for controlling cache durations of page segments, enhancing caching behavior and performance. - Find Configuration Object: Identifies the nextConfig object in the code. - Add staleTimes Property: Adds the staleTimes property to the experimental object, specifying cache durations for dynamic and static pages. - Specify Cache Durations: Defines the cache duration for dynamic and static pages in seconds. - Clean Up: Removes the experimental object if it becomes empty after the migration. ### Before ```js /** @type {import('next').NextConfig} */ const nextConfig = { experimental: { // Existing experimental properties }, }; module.exports = nextConfig; ``` ### After ```js /** @type {import('next').NextConfig} */ const nextConfig = { experimental: { staleTimes: { dynamic: 30, // Cache dynamic pages for 30 seconds static: 180, // Cache static pages for 180 seconds }, }, }; module.exports = nextConfig; ```
Update Fetch Requests to Handle Caching This codemod refactors fetch requests to handle caching according to new default behaviors. By default, fetch requests are no longer cached. Use the cache option to cache specific requests, or set fetchCache in a layout or page to control caching behavior globally. - Find Fetch Requests: Identifies fetch requests in the code that need caching adjustments. - Property Check: Ensures that fetch requests are updated with the cache option where needed and adds the fetchCache option to control global caching. - Add Caching Configuration: Adds export const fetchCache = 'default-cache' to layouts or pages to cache all requests by default unless overridden. ### Before ```js // app/layout.js export default async function RootLayout() { const a = await fetch("https://example.com/data"); // Not Cached const b = await fetch("https://example.com/another-data", { cache: "force-cache", }); // Cached // ... } ``` ### After ```js // app/layout.js // Since this is the root layout, all fetch requests in the app // that don't set their own cache option will be cached by default. export const fetchCache = "default-cache"; export default async function RootLayout() { const a = await fetch("https://example.com/data"); // Cached const b = await fetch("https://example.com/another-data", { cache: "no-store", }); // Not Cached // ... } ``` ### Explanation - Default Behavior Change: fetch requests are no longer cached by default. - Opt-in Caching: Use the cache: 'force-cache' option to cache individual fetch requests. - Global Caching Control: Use export const fetchCache = 'default-cache' in a layout or page to apply caching to all fetch requests that don't specify their own cache options.
Update Route Handlers to Handle Caching This codemod refactors Route Handlers to manage caching behavior for GET functions. By default, GET methods are no longer cached. This codemod updates your Route Handler files to use the dynamic configuration option to opt specific routes into caching. - Find Route Handlers: Identifies GET functions in the Route Handler files. - Property Check: Ensures the presence of GET functions and adds the dynamic configuration option if necessary. - Add Caching Configuration: Adds export const dynamic = 'force-static' to enable caching for GET methods. - Clean Up: Removes the experimental object if it becomes empty after the migration. ### Before ```js // app/api/route.js export async function GET() { // Handler logic } ``` ### After ```js // app/api/route.js // Use this option to cache the GET method response export const dynamic = "force-static"; export async function GET() { // Handler logic } ```
This recipe is a set of codemods that will help migrate to next 15. The recipe includes the following codemods: - next/15/update-route-handlers - next/15/update-fetch-requests-to-handle-caching - next/15/add-experimental-stale-times - next/15/refactor-imports-from-@next/font-to-next/font
Refactor Imports from @next/font to next/font This codemod refactors import statements in your code to replace @next/font with next/font, aligning with the latest Next.js module structure. - Find Import Declarations: Identifies all ImportDeclaration nodes in the code. - Check Import Path: Ensures that the import path starts with @next/font. - Replace Import Path: Updates the import path to use next/font instead of @next/font. ### Before ```js // Before import { Inter } from "@next/font/google"; ``` ### After ```js // After import { Inter } from "next/font/google"; ```
The App Router Recipe is a set of codemods that assist you with the pages-to-app migration process. The recipe includes the following codemods: - next/13/replace-next-router - next/13/replace-next-head - next/13/remove-get-static-props - next/13/app-directory-boilerplate
This codemod moves transforms imports from `next/server` to `next/og` for usage of [Dynamic OG Image Generation](https://nextjs.org/docs/app/building-your-application/optimizing/metadata#dynamic-image-generation). ## Example ### Before ```jsx import { ImageResponse } from "next/server"; ``` ### After ```jsx import { ImageResponse } from "next/og"; ```
This codemod migrates certain viewport metadata to `viewport` export. ## Example ### Before ```jsx export const metadata = { title: "My App", themeColor: "dark", viewport: { width: 1, }, }; ``` ### After ```jsx export const metadata = { title: "My App", }; export const viewport = { width: 1, themeColor: "dark", }; ```
Since Next.js 13.4, you can mark the files that contain only client-side code with the `use client` directive at the top. The codemod will look for identifiers and string literals common for files that contain client-side code, such as React hooks or event handlers. On the other hand, it will not upsert any directive should it spot elements indicating server-side code. The codemod will not remove the existing `use client` directive even if it would suggest otherwise due to the code in question. ## Example ### Before ```jsx import { useState } from "react"; export default function Page() { const [x, setX] = useState(""); return x; } ``` ### After ```jsx "use client"; import { useState } from "react"; export default function Page() { const [x, setX] = useState(""); return x; } ```
A recent update in Next.js brought a breaking change: the `useSearchParams` hook no longer includes `params`. To ease the migration, the new `useCompatSearchParams` hook can be used. This hook mimics the behavior of the old `useSearchParams` in two ways: - it includes both `params` and `searchParams` - `params` overwrite any conflicting values in `searchParams` ## Example ### Before ```jsx import { useSearchParams } from "next/navigation"; export async function Component() { const params = useSearchParams(); return <div>My Component</div>; } ``` ### After ```jsx import { useCompatSearchParams } from "hooks/utils"; export async function Component() { const params = useCompatSearchParams(); return <div>My Component</div>; } ```
Build your own codemod and share it with the community.