Знакомьтесь, Vinext: альтернатива Next.js на базе Vite

Vinext — это open-source-плагин для Vite от Cloudflare, который заново реализует API Next.js. Благодаря ему существующую кодовую базу на App Router или Pages Router можно собирать и обслуживать с помощью Vite вместо тулчейна Next.js. Cloudflare анонсировала версию 1.0 28 сентября 2026 года.

Многим командам нравится Next.js, но не нравится хостинг, к которому он их подталкивает. При этом переносить крупное приложение на другой фреймворк только ради смены хостинга трудно обосновать. Vinext предлагает иной путь. В этой статье мы разберём, что поддерживает Vinext, куда его можно развернуть, какие команды нужны, чтобы протестировать его на собственном приложении, и какие пробелы документирует сама Cloudflare.

Что такое Vinext и чем он отличается от других альтернатив Next.js?

Vinext — это Next.js, реализованный командой Cloudflare заново поверх Vite. Проект появился в феврале 2026 года как недельный эксперимент с активным использованием ИИ и спустя семь месяцев достиг версии 1.0. В README прямо сказано, что это не форк: ядро написано с нуля так, чтобы соответствовать публичному API Next.js.

Таким образом, Vinext — вариант иного рода, чем привычные альтернативы Next.js. Переход на React Router, Astro или SvelteKit означает переписывание маршрутов, логики загрузки данных и компонентов. Vinext этот код не трогает и меняет только то, что его собирает и обслуживает. Ваш проект по-прежнему выглядит как проект на Next.js, а вся работа под капотом выполняется Vite.

Что поддерживает Vinext?

Vinext поддерживает оба роутера и основные серверные возможности современного Next.js. В анонсе версии 1.0 и README указана поддержка следующего:

• App Router, Pages Router и гибридные приложения, использующие оба роутера
• React Server Components и Server Actions
• Middleware, API-маршруты и обработчики маршрутов (route handlers)
• Ревалидация ISR
• Пререндеринг на этапе сборки через generateStaticParams() и getStaticPaths()
• Статический экспорт с output: "export"

README ориентирован на Next.js 16.x, а в качестве peer-зависимости указан vite ^8.0.0.

Cloudflare описывает совместимость Vinext с Next.js двумя разными способами, и эти цифры измеряют не одно и то же. В посте о версии 1.0 заявлена совместимость более 99% по тестам, но только для функций, которые чаще всего запрашивали клиенты, и без учёта Cache Components. В README же говорится: «~94% API-поверхности Next.js 16 поддерживается полностью или частично». Обе цифры исходят от Cloudflare, и ни одна из них не заменит проверку на вашем собственном приложении.

Куда можно развернуть Vinext?

Vinext нативно разворачивается в Cloudflare Workers, и, согласно посту о версии 1.0, работает даже на бесплатном тарифе Workers. В том же посте среди целевых платформ названы Netlify и AWS Lambda. Механизм объясняется в README: Workers обслуживается напрямую пакетом @vinext/cloudflare, а Vercel, Netlify, AWS и Deno Deploy становятся доступны после добавления Vite-плагина Nitro. Нативных адаптеров для Netlify или Lambda здесь нет.

Минимальная конфигурация добавляет всего один плагин:

// vite.config.ts
import { defineConfig } from "vite";
import vinext from "vinext";

export default defineConfig({
  plugins: [vinext()],
});

Чтобы развернуть приложение не в Cloudflare, установите nitro и добавьте его плагин:

// vite.config.ts
import { defineConfig } from "vite";
import vinext from "vinext";
import { nitro } from "nitro/vite";

export default defineConfig({
  plugins: [vinext(), nitro()],
});

npm install nitro
NITRO_PRESET=netlify npx vite build

Как попробовать Vinext на существующем приложении Next.js

Чтобы протестировать Vinext на существующем приложении, достаточно двух команд, и ни одна из них не нарушает ваш текущий рабочий процесс с Next.js. Запускайте их в отдельной ветке:

npx vinext check
npx vinext init

vinext check сканирует проект и сообщает об известных несовместимостях ещё до того, как вы что-либо измените. vinext init работает неразрушающе: next dev продолжает функционировать параллельно с новой конфигурацией. Команда запрашивает целевую платформу для деплоя и по умолчанию предлагает Cloudflare. Начиная с релиза 1.0, конфигурации для Cloudflare по умолчанию используют cf CLI с типизированным cloudflare.config.ts. Чтобы сохранить прежнюю конфигурацию на базе Wrangler, передайте флаг --legacy-wrangler-cloudflare-init.

Создание нового приложения на Vinext

Для проекта с нуля сгенерируйте каркас приложения, запустите его, соберите и разверните:

npm create vinext-app@latest my-app
npx vite dev
npx vite build
npx @vinext/cloudflare deploy

В релизе 1.0 у команды деплоя появился флаг --warm-cache. Он загружает новую версию с 0% трафика, запрашивает через неё кэшируемые страницы, чтобы заполнить кэши, и только после этого переводит на неё трафик.

Каковы ограничения и известные пробелы Vinext?

В разделе Known gaps в README перечислены четыре области, в которых Vinext пока не соответствует Next.js: Cache Components, оптимизация изображений и шрифтов на этапе сборки, нативные модули в режиме разработки App Router и часть платформенно-специфичных настроек маршрутов. Cloudflare сообщает, что работа над всеми четырьмя пунктами продолжается, так что ни одно из этих ограничений не является окончательным.

• Cache Components и PPR: "use cache" работает частично, но полная модель cacheComponents ещё не завершена. Профили кэша, теги, частичные оболочки (partial shells), возобновление (resuming), предзагрузка (prefetching), а также отдельные аспекты кэширования в режимах разработки и сборки могут по-прежнему вести себя иначе, чем в Next.js.
• Изображения и шрифты: в Cloudflare изображения могут оптимизироваться в момент запроса. Однако Vinext пока не воспроизводит полный конвейер обработки изображений, который Next.js выполняет на этапе сборки, а шрифты загружаются во время выполнения, а не обрабатываются при сборке.
• Нативные модули: такие пакеты, как sharp, resvg, satori, lightningcss и @napi-rs/canvas, могут не работать в RSC-окружении разработки Vite. Продакшен-сборки справляются с бо́льшей их частью, чем режим разработки.
• Настройки маршрутов: Vinext игнорирует параметры маршрутов runtime и preferredRegion.

Кроме того, в README отмечено, что Vinext пока не является полноценной заменой «один к одному» (drop-in replacement) для любого приложения.

Кому стоит переходить на Vinext, а кому лучше подождать

Vinext подойдёт командам, которые хотят продолжать писать на Next.js, не будучи привязанными к одному хостингу. Однако источники расходятся в оценке готовности к продакшену. В анонсе Cloudflare версия 1.0 названа готовой к продакшену, тогда как README отвечает: «Можно, но с осторожностью» — и указывает, что у Vinext всё ещё есть пробелы в совместимости и он пока не проверен на всех типах продакшен-приложений на Next.js.

• Переходите, если ваше приложение использует оба роутера, RSC, Server Actions и ISR и вы хотите развернуть его в Workers или через Nitro.
• Подождите, если вы активно полагаетесь на Cache Components, PPR или семантику "use cache", например на теги и профили.
• Рассмотрите OpenNext, если вам нужна проверенная зрелость в продакшене. Как поясняется в README Vinext, OpenNext работает с результатом next build, поэтому покрывает бо́льшую часть API Next.js и имеет значительно более длительную историю использования.

Заключение

Vinext позволяет уйти с Vercel, не переписывая приложение на Next.js. Взамен придётся мириться с задокументированными пробелами, в первую очередь в области Cache Components. Чтобы понять, подходит ли он вам, создайте ветку, запустите npx vinext check, сопоставьте найденные проблемы с известными пробелами, затем выполните npx vinext init и сравните поведение с next dev. Если вы также хотите перевести на новые инструменты остальной тулчейн, прочитайте статью «Начало работы с Vite+» (для проектов на Vite+ в README указана команда vp exec vinext-cloudflare deploy). О рабочем процессе с cloudflare.config.ts, который настраивает init, читайте в статье «Практическое руководство по новому cf CLI от Cloudflare».

Часто задаваемые вопросы

Можно ли сохранить собственную конфигурацию webpack или настройку next/jest при переходе на Vinext?

Нет. Vinext работает на Vite, поэтому конфигурации Turbopack и webpack не применяются, а пользовательские загрузчики и плагины webpack необходимо заменить плагинами Vite. В README Vinext next/jest указан как неподдерживаемый, а вместо него рекомендуется Vitest. AMP также не поддерживается — useAmp() всегда возвращает false, а устаревшая команда next export заменена параметром output: 'export' в конфигурации Next.js.

Какие версии React и Vite требуются для Vinext?

Vinext объявляет peer-зависимости react ^19.3.1, react-dom ^19.3.1, react-server-dom-webpack ^19.3.1 и vite ^8.0.0 и ориентирован на Next.js 16.x. В проектах на App Router также должен быть установлен @vitejs/plugin-rsc. Vinext регистрирует этот плагин автоматически, если обнаруживает директорию app, поэтому собственный вызов rsc() приведёт к ошибке сборки из-за дублирования плагина, если только вы не передадите rsc: false в vinext().

Что меняет vinext init в существующем проекте на Next.js?

vinext init добавляет 'type': 'module' в package.json и переименовывает конфигурационные файлы в формате CommonJS, например postcss.config.js в postcss.config.cjs, чтобы избежать конфликтов с ESM. Команда также устанавливает пакеты Vite и Vinext и добавляет скрипты dev:vinext, build:vinext и start:vinext наряду с существующими скриптами Next.js. Поскольку исходные скрипты остаются на месте, next dev и dev-сервер Vinext можно запускать из одной кодовой базы для параллельного сравнения.

Отдаёт ли revalidateTag устаревшие страницы во время их перегенерации в Vinext на Cloudflare?

Да, начиная с релизов 1.1 в октябре 2026 года, если передать профиль кэша, например revalidateTag(tag, 'max'). В более ранних релизах соответствующие страницы удалялись из Workers Cache, и следующему запросу приходилось ждать полного рендеринга. Теперь Workers Cache и Response Store помечают такие записи как устаревшие и продолжают отдавать закэшированную версию, пока она перегенерируется в фоне, как это происходит в Next.js. Вызов revalidateTag только с тегом или с expire: 0 по-прежнему немедленно инвалидирует записи. Устаревшие записи 'use cache' также отдаются во время их перегенерации.