Vite 8 вышел в стабильный релиз 12 марта 2026 года, и это обновление важно не из-за самого номера версии. Главная новость здесь не в косметике API, а в том, что Vite переводит основной стек сборки на Rolldown и Oxc, убирая старую раздвоенность между esbuild и Rollup.

Для React-команды смысл апгрейда появляется там, где сборка уже стала источником шума: production build тянется слишком долго, локальная разработка и итоговая сборка ведут себя по-разному, а vite.config давно оброс rollupOptions, esbuild-настройками и плагинами, которые никто не пересматривал.

Ниже разбор без рекламной оптики: что в Vite 8 действительно меняется, что React-проекту стоит проверить до апгрейда и где официальное руководство по миграции уже сейчас предупреждает о реальных рисках.

Что в Vite 8 реально изменилось

Rolldown и Oxc стали новым базовым стеком

Главное изменение релиза лучше формулировать точно: Vite 8 использует Rolldown и инструменты на базе Oxc вместо прежней связки esbuild и Rollup. То есть речь не просто про новый сборщик ради замеров скорости, а про более цельный стек сборки с меньшим количеством служебной обвязки между локальной разработкой и production.

Здесь важно сразу пояснить термины. Rolldown в контексте Vite 8 это новый сборщик модулей: он отвечает за то, как проект собирается в итоговые чанки и бандлы. Oxc это не отдельный режим Vite, а набор быстрых инструментов для разбора и преобразования JavaScript и TypeScript. Проще говоря, Rolldown собирает проект, а Oxc помогает Vite быстрее разбирать и преобразовывать код.

Официальный анонс Vite 8 делает акцент не только на скорости production builds, но и на более согласованном поведении от парсинга и резолва до трансформации и минификации. Для большого React-проекта это важнее рекламных цифр: конфиг проще объяснять, регрессии легче локализовать, а поведение инструментов меньше зависит от исторических различий между двумя разными пайплайнами.

Это и есть главный инженерный смысл релиза. Vite 8 пытается быть не набором удачно склеенных частей, а более последовательной цепочкой от исходников до production bundle.

Появился нормальный постепенный путь миграции

Команда Vite оставила два понятных маршрута:

  • прямой апгрейд на vite@8;
  • промежуточный шаг через rolldown-vite, если сначала нужно вынести на поверхность именно несовместимости вокруг Rolldown, не смешивая их с остальными изменениями Vite 8.

Если проект живет на Storybook, имеет нестандартные build.rollupOptions, ручное разбиение на чанки, тяжелые плагины или нетривиальные интеграции вокруг тестов и preview, сценарий “сначала rolldown-vite, потом vite@8” обычно безопаснее, чем массовый апгрейд за один PR.

Встроенные улучшения, которые стоит знать

Кроме самого перехода на Rolldown, в Vite 8 есть еще несколько практичных вещей:

  • встроенная поддержка tsconfig paths через resolve.tsconfigPaths: true, но с небольшой просадкой по скорости и не по умолчанию;
  • встроенная поддержка emitDecoratorMetadata, но только частичная: полная поддержка упирается в ограничения типовой информации на стороне Oxc;
  • обновленная базовая планка браузеров для build.target и baseline-widely-available;
  • server.forwardConsole, который может пробрасывать ошибки и console из браузера в терминал dev-сервера.

По отдельности это не выглядит сенсацией. Но вместе эти изменения делают базовый стек заметно современнее и полезнее именно как рабочий инструмент, а не как набор точечных фич.

Что React-проекту проверить перед апгрейдом

1. Версии Node.js локально и в CI

Vite 8 требует Node.js 20.19+ или 22.12+. Это те же требования, что и у Vite 7, но на практике проблема все равно всплывает часто: локально одна версия Node, в CI другая, а редактор и devcontainer живут вообще отдельно.

Если этот слой не выровнен, апгрейд начинает выглядеть как “сломался Vite”, хотя реальная причина банальнее: среда не совпадает с требованиями релиза.

2. Кастомные build.rollupOptions, esbuild и manualChunks

Если проект долго жил на Vite 6 или 7, у него часто уже накопились точечные правки:

  • build.rollupOptions;
  • ручной manualChunks;
  • тонкие esbuild-опции;
  • нестандартные оптимизации для зависимостей;
  • плагины, которые трогают сборочный пайплайн глубже обычного.

Здесь важно различать два факта одновременно. С одной стороны, официальный анонс Vite 8 обещает слой совместимости, который автоматически конвертирует часть старых esbuild- и rollupOptions-настроек в эквиваленты для Rolldown и Oxc. С другой стороны, руководство по миграции отдельно предупреждает, что часть старой поверхности уже устарела или вообще больше не поддерживается.

Практические маркеры риска здесь такие:

  • esbuild как основная точка настройки уже deprecated в пользу oxc;
  • optimizeDeps.esbuildOptions deprecated в пользу optimizeDeps.rolldownOptions;
  • объектная форма build.rollupOptions.output.manualChunks больше не поддерживается;
  • функция manualChunks тоже помечена как устаревающая.

Если проект сознательно опирается на такие опции, миграция требует ревизии конфига, а не только быстрой локальной проверки.

3. alias, tsconfig paths, env и импорт ассетов

Для React-проектов проблемным местом часто оказывается не сам JSX, а обвязка:

  • alias и резолв путей;
  • .env-схема;
  • SVG, Markdown, JSON и другие импортируемые ресурсы;
  • собственные плагины вокруг генерации или локальной разработки.

Встроенная поддержка tsconfig paths полезна, но не автоматически выгодна. Официальная документация Vite отмечает и просадку по скорости, и то, что TypeScript-команда в целом не рекомендует использовать paths как способ менять поведение внешних инструментов.

Если текущая схема с alias уже прозрачная и предсказуемая, миграция должна упростить конфиг, а не добавить еще один уровень резолва поверх старого.

4. Пакеты React-экосистемы вокруг сборки

Обычный React-проект редко живет на одном vite.

Что проверить вместе:

  • основной vite.config.*;
  • @vitejs/plugin-react и соседние плагины;
  • Storybook, если он привязан к Vite;
  • Vitest и dev/test-утилиты;
  • CI-сценарии сборки и preview.

Здесь есть важная деталь именно для React-команд. Вместе с Vite 8 вышел @vitejs/plugin-react v6: React Refresh теперь проходит через Oxc, а Babel больше не нужен по умолчанию. При этом официальный анонс отдельно уточняет, что v5 тоже совместим с Vite 8, поэтому обновление vite и plugin-react не обязательно делать в одном шаге.

Для проектов с React Compiler или Babel-зависимыми трансформациями это особенно важно. Поведение по умолчанию стало легче, но нестандартный React-стек все равно нужно проверять целиком, а не по одному пакету.

Где миграция ломается чаще всего

Старое разбиение на чанки и неоднозначная совместимость с CJS

Чем дольше проект живет, тем выше шанс, что в нем уже накопилась сборочная логика, которая держится на исторических компромиссах:

  • почему именно так режутся чанки;
  • откуда взялась конкретная optimizeDeps-настройка;
  • почему один пакет импортируется как default, а другой только через namespace;
  • зачем вообще осталась кастомная схема vendor split.

В Vite 8 это особенно заметно по двум местам. Во-первых, руководство по миграции прямо говорит, что объектная форма manualChunks больше не поддерживается. Во-вторых, default-импорт из CommonJS теперь обрабатывается более последовательно, и это может вскрыть старые зависимости, которые раньше “случайно работали”.

Иными словами, Vite 8 не создает эту проблему, а поднимает ее на поверхность. Это полезно, но только если команда готова признать: часть “несовместимостей релиза” на самом деле оказывается старым техническим долгом конфига.

Новая базовая планка браузеров

В руководстве по миграции для Vite 8 обновлена базовая планка браузеров по умолчанию:

  • Chrome 107 -> 111
  • Edge 107 -> 111
  • Firefox 104 -> 114
  • Safari 16.0 -> 16.4

Это не звучит драматично, но для некоторых проектов это реальная граница. Если приложение до сих пор опирается на старые браузерные компромиссы, их лучше увидеть сразу. Особенно если команда живет на дефолтах и давно не пересматривала build.target.

Рядом с этим стоит и тема декораторов. Встроенная поддержка emitDecoratorMetadata упрощает конфиг, но Vite отдельно пишет, что эта поддержка частичная. Если проект или дизайн-система действительно сильно завязаны на декораторы, это не тот случай, где апгрейд стоит считать полностью безболезненным.

Оптимизация зависимостей теперь тоже едет через Rolldown

Еще одно место, где может всплыть разница: оптимизация зависимостей.

В Vite 8 для этого теперь тоже используется Rolldown, а optimizeDeps.esbuildOptions считается переходным слоем совместимости и устаревающим путем на будущее. Для простого проекта это может пройти почти незаметно. Для сложного монорепо, SSR-обвязки или сильно кастомизированного React-приложения это уже повод смотреть не только на HMR, но и на build, preview и CI.

Самая опасная ошибка здесь простая: принять поднявшийся dev-сервер за доказательство полной совместимости. Слой совместимости помогает стартовать, но не гарантирует, что поведение бандла, совместимость с CommonJS и оптимизация зависимостей останутся прежними.

Когда апгрейд уже стоит делать

Апгрейд Vite 8 обычно оправдан, если у проекта уже есть хотя бы несколько из этих симптомов:

  • production build стал слишком медленным;
  • конфиг тяжело объяснить новому инженеру;
  • dev- и build-поведение расходятся слишком часто;
  • в команде уже есть запрос на более понятную базовую схему сборки;
  • локальная среда и CI уже готовы к требованиям Node.js;
  • текущая Vite-версия все равно скоро станет тормозом для соседних инструментов.

В таком сценарии релиз дает не просто “новый номер версии”, а шанс сделать сборочный слой чище и предсказуемее.

Когда можно не спешить

Не каждый React-проект должен мигрировать в ту же неделю, когда выходит стабильный релиз.

Лучше не спешить, если:

  • текущий стек работает стабильно и почти не требует внимания;
  • продуктовая нагрузка сейчас важнее инфраструктурных улучшений;
  • проект сильно зависит от редко используемых плагинов;
  • в проекте много декораторов или старый CJS-слой с неоднозначными импортами;
  • у команды нет ресурса проверить не только dev, но и CI, preview и production bundle.

Если миграция сейчас отнимет много внимания, а реального pain point нет, это плохой кандидат на “обязательное немедленное обновление”.

Где читать первоисточник

  • Vite 8.0 is out! — стабильный релиз от 12 марта 2026 и основные практические изменения.
  • Migration from v7 — точные breaking changes, deprecated-опции и ограничения по Rolldown/Oxc.
  • Features — детали по resolve.tsconfigPaths, emitDecoratorMetadata и другим TypeScript-особенностям.

Итог

Vite 8 важен не потому, что это просто очередной релиз с новым номером. Это релиз, в котором Vite становится более цельным стеком вокруг Rolldown и Oxc, с более современной базовой схемой и понятным маршрутом миграции.

Самый практичный следующий шаг тоже довольно приземленный: инвентаризировать Node.js, @vitejs/plugin-react, build.rollupOptions, manualChunks, esbuild- и optimizeDeps-настройки, а затем решить, нужен прямой апгрейд или сначала безопасный прогон через rolldown-vite. Именно такой список показывает цену перехода честнее любого демо-замера.