Миграция Next.js 15 → 16: что сломалось и как чинили

Зачем мигрировать

Next 16 принёс несколько вещей, ради которых стоит обновляться: переработанный кеш, более предсказуемый Turbopack, нативная поддержка React 19 без feature flags, обновлённый <Image> и улучшенный dev-server.

Но миграция — не «обнови и поехали». Несколько API изменились ломающе.

Что сломалось у нас

Кеш стал явным

Раньше fetch кешировался по умолчанию. Теперь — нет. Это полезное изменение, но молча превращает кучу запросов в SSR на каждый запрос.

// Было: кешировалось автоматически
const data = await fetch("https://api.example.com/posts");
 
// Стало: нужно явно указать поведение
const data = await fetch("https://api.example.com/posts", {
  cache: "force-cache",
});

params теперь Promise

В page и layout params и searchParams стали асинхронными. Без await — ругань в рантайме.

export default async function Page({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  const { slug } = await params;
  return <Post slug={slug} />;
}

next/font строже

Если шрифт не находит вес или начертание — ошибка билда вместо тихого фолбэка. Хорошо для качества, плохо для тех, кто не следил за конфигами.

Что стало лучше

• Turbopack стабильнее — у нас dev-сервер стартует за 2.1 секунды против 6
• Меньше повторных рендеров на серверной стороне за счёт нового resolver
• Bundle Analyzer встроенный — больше не нужен сторонний плагин

План миграции, который сработал

1. Обновили next и react на отдельной ветке
2. Прогнали npx @next/codemod@latest next-async-request-api .
3. Прошли по dev-серверу и поправили все warnings
4. Проверили продовый билд и Lighthouse
5. Только после этого открывали PR

Это заняло у нас около двух дней на проекте среднего размера (60+ страниц).

Что не делайте

Не мигрируйте «прицепом» к фиче. Это отдельная задача с отдельным PR. Иначе ревью превратится в ад, а откат станет невозможным.

Итог

Next 16 — стоящий апдейт, но требует часов внимания, а не минут. Заложите их заранее и не делайте миграцию в пятницу вечером.