Коротко: Vite 8 — це не просто «ще один мажор». Якщо у вас фронтенд на React, Vue чи Svelte, цей реліз зачіпає саму механіку збірки: всередині більше ролі отримують Rolldown і Oxc, а дефолтний browser target зміщується вперед. Хороша новина — це не схоже на міграцію з палаючим продом. Погана — якщо у вас кастомний vite.config, нетипові плагіни або SSR, апгрейд краще робити як нормальний інженерний rollout, а не під гаслом «оновимо й подивимось».

Що реально змінилося у Vite 8

Офіційно головний сигнал простий: Vite 8 рухається в бік нового ядра збірки. Якщо раніше команди звикли думати у зв’язці «Vite + esbuild + Rollup», то тепер треба звикати до нової реальності:

Це означає просту річ: частина старих конфігів і плагінів буде не «зламана вщент», а поводитиметься трохи інакше. А такі зміни — найпідступніші, бо CI може бути зеленим, а dev- або SSR-сценарій почне дивно сипатися вже після релізу.

Чому це важливо не тільки для build-команди

У багатьох проєктах Vite давно став не «інструментом збірки десь там під капотом», а частиною щоденного флоу команди:

Тому Vite 8 впливає не лише на платформену команду. Якщо у вас кілька frontend-репозиторіїв, monorepo або складний набір плагінів, цей апгрейд легко торкнеться розробників, QA і DevOps одночасно.

Людською мовою: ризик тут не в тому, що «сайт не збереться взагалі». Частіше ризик у тому, що:

Найважливіші місця ризику

1) optimizeDeps.esbuildOptions — час перестати жити вчорашнім днем

У Vite 8 optimizeDeps.esbuildOptions ще підтримується для сумісності, але це вже місток, а не довгостроковий дім. Офіційний напрямок — optimizeDeps.rolldownOptions.

Якщо у вас у конфігу є кастомні esbuild-опції для dependency optimization, не сприймайте їх як «ну, поки ж працює». Саме такі місця зазвичай першими стають технічним боргом після мажорного апгрейду.

Що робити:

2) esbuild у shared config — вже не центр всесвіту

Подібна історія з полем esbuild у конфігу. Vite 8 ще дає backward compatibility, але напрямок зрозумілий: oxc.

Це важливо для команд, які робили тонкі оптимізації JSX/TS-трансформацій або мали нетривіальні include/exclude правила. Тут не треба панікувати, але треба перевірити, чи ваш конфіг не живе на припущенні «Vite всередині поводиться рівно так, як у попередньому поколінні».

3) Browser target став новішим

Vite 8 підсунув дефолтний baseline вперед:

Для більшості сучасних продуктів це нормально. Але якщо у вас B2B-аудиторія, старі корпоративні ноутбуки, kiosk-сценарії або просто життя з браузерами «які застрягли в часі», треба не тішити себе словом baseline, а перевірити фактичну математику сумісності.

Інакше можна випадково зекономити на трансформаціях, але отримати злий сюрприз у production на невеликому, зате дуже болючому сегменті користувачів.

4) SSR і кастомні плагіни — як завжди, найцікавіше тут

Саме тут мажорні апдейти люблять показувати характер. Якщо у вас є:

то апгрейд треба сприймати як маленький rollout-проєкт, а не як dependency bump на 5 хвилин.

Практичний план міграції з Vite 7 на Vite 8

Крок 1. Зробіть preflight-аудит до оновлення

Перед npm update чи pnpm up зафіксуйте:

Це та частина, яку всі хочуть пропустити. А потім виявляється, що проблема не в самому Vite 8, а в забутому плагіні, який ніхто не чіпав півтора року.

Крок 2. Оновлюйтеся окремою гілкою і з окремим diff

Не змішуйте цей апгрейд із «ще заодно підчистили eslint, tsconfig і пару legacy warning». Vite 8 краще виносити окремим PR.

Чому:

Крок 3. Спочатку проганяйте dev і build, потім SSR

Базова перевірка після оновлення:

  1. локальний dev-server стартує без нових warning/error;
  2. production build збирається чисто;
  3. preview/build артефакт працює;
  4. SSR-сценарії проходять окремо, якщо вони є.

SSR не варто змішувати з базовим «ну збірка ж пройшла». Це різні рівні ризику.

Крок 4. Перевірте browser target свідомо, а не за замовчуванням

Якщо у вас є вимоги до старіших браузерів, зафіксуйте target явно. Якщо таких вимог уже немає — теж добре, але краще прийняти це як рішення команди, а не як тиху побічку мажорного релізу.

Крок 5. Дивіться на staging, ніби це прод у мініатюрі

Після Vite 8 у staging варто перевірити:

Тут корисне старе правило: якщо щось «ламається тільки інколи», саме staging має це зловити до продакшну.

Що не варто робити

Антипатерн 1. «Оновимо Vite і плагіни всі разом, щоб двічі не вставати»

Ні. Це швидкий шлях до PR, у якому вже ніхто не розуміє, що викликало регресію.

Антипатерн 2. «Раз CI зелений, значить усе ок»

CI — це не телепат. Він не знає, що у вас вчора в Safari на staging зламався asset path лише в SSR-маршруті з авторизацією.

Антипатерн 3. «Backward compatibility є, значить міграція не термінова»

Так народжується борг. Якщо офіційний шлях іде від esbuild-конфігів до oxc/rolldown, краще почати адаптацію зараз, поки це контрольована міграція, а не панічний апдейт через два релізи.

Що робити команді вже сьогодні

Мінімально корисний план виглядає так:

  1. перевірити, чи ваш стек і плагіни готові до Vite 8;
  2. знайти всі залежності від esbuild-специфічної поведінки;
  3. окремо перевірити SSR та asset paths;
  4. узгодити browser support після нового baseline;
  5. робити rollout через staging і з готовим rollback.

Висновок

Vite 8 — хороший, дорослий реліз. Але цінність тут не в тому, щоб «якнайшвидше поставити нову цифру в package.json». Цінність у тому, щоб використати апгрейд для наведення порядку в build-конфігу: прибрати залежність від застарілих assumptions, чесно перевірити SSR і зафіксувати browser support без самообману.

Якщо коротко: оновлюватися варто, але як команда, а не як азартна людина о 17:55 у п’ятницю.

Офіційні джерела: