Vite переходит на Rolldown: что сейчас должны сделать команды полного стека

Официальная документация Vite теперь описывает интеграцию с Rolldown — сборщиком на основе Rust, разработанным как совместимый с Rollup, высокопроизводительный заменитель предыдущей сборочной цепочки Vite на основе esbuild и Rollup. Это преднамеренное изменение на уровне платформы, которое затрагивает производственные сборки, поведение dev-сервера, API плагинов и минимальные целевые версии Node/браузеров; команды должны рассматривать это как стратегическую миграцию инструментов, а не как незначительное обновление. (vite.dev)

Почему это важно (практическое воздействие)

• Время сборки в производственной среде: Rolldown разработан для значительно более быстрых полных сборок, чем старая комбинация Rollup/esbuild. Ожидайте сокращения времени сборки в CI (часто значительные) и уменьшения использования памяти для больших монорепозиториев.
• Определенность и меньше ошибок «работает в dev / ломается в prod»: использование единой цепочки инструментов на Rust для разбора/трансформации/минификации уменьшает различия между инструментами.
• Изменения в плагинах и трансформациях: некоторые хуки плагинов и поведение минификаторов изменяются (трансформации/минификация на основе Oxc заменяют предыдущее поведение). Тесты, которые полагались на трансформации esbuild или крайние случаи плагинов Rollup, могут не пройти.
• Новые базовые целевые версии и поддержка Node: документация Vite обновляет целевые браузеры по умолчанию и исключает Node 18; теперь Vite требует современный Node 20.19+ / 22.12+ (проверьте свои образы CI). (vite.dev)

Непосредственные приоритеты для команд полного стека

1. Инвентаризация и базовая линия
   • Запишите текущую версию Vite, список плагинов, пользовательские параметры Rollup и использование esbuild.
   • Измерьте базовую линию: время холодной сборки CI, холодный старт dev-сервера и размер представительной производственной сборки.
2. Обновите образы CI и разработчиков
   • Убедитесь, что образы CI/сборки используют поддерживаемую версию Node (20.19+ или 22.12+). Если вы фиксируете образы, обновите их перед обновлением Vite.
3. Создайте безопасную ветку миграции
   • Обновите Vite в ветке функций и запустите полное CI. Не обновляйте в основной ветке, пока не завершится проверка.
4. Запустите автоматизированные тестовые наборы и сквозные тесты
   • Приоритизируйте тесты, охватывающие SSR, разбиение кода, manualChunks и любые трансформации, управляемые плагинами.
5. Проверьте плагины и пользовательскую логику Rollup
   • Замените устаревшие хуки; протестируйте сторонние плагины. Если плагин зависит от внутренних механизмов esbuild, замените его или используйте другой.
6. Исходные карты, минификация и вывод активов
   • Сравните исходные карты и выводы минификаторов. Минификация на основе Oxc может отличаться — проверьте трассировки стека, точность исходных карт и окончательные сжатые размеры.
7. Проверка dev-сервера / HMR
   • Проверьте поведение HMR, предварительную сборку зависимостей и хуки промежуточного ПО dev-сервера. Некоторые ранее принятые шаблоны могут потребовать незначительных изменений.
8. Постепенный rollout
   • Используйте канареечный или поэтапный релиз для производственных сборок (например, создайте внутреннюю предварительную среду), прежде чем переключать все конвейеры.

Конкретный контрольный список (по шагам)

• Шаг 0: Резервное копирование файлов блокировок (package-lock.json / pnpm-lock.yaml / yarn.lock).
• Шаг 1: Зафиксируйте Vite на предполагаемой версии 8.x beta/stable в package.json, чтобы сохранить воспроизводимость CI.
• Шаг 2: Обновите Node в локальных и CI образах до как минимум Node 20.19 (или 22.12+ для долгосрочной совместимости).
• Шаг 3: Запустите npm ci / pnpm install и соберите локально; зафиксируйте время + память.
• Шаг 4: Запустите полные модульные + интеграционные тесты. Добавьте целевые тесты для точек входа SSR и конечных точек серверных функций.
• Шаг 5: Проверьте предупреждения плагинов или сообщения об устаревании во время сборки; устраните их (обновите или замените плагины).
• Шаг 6: Проверьте артефакты (хеши пакетов, исходные карты, имена активов) и выполните канаречный деплой.
• Шаг 7: Мониторьте производственные логи и метрики производительности на наличие регрессий в течение 24–72 часов, затем полностью разверните.

Области риска и меры по их снижению

• Сломанные плагины: поддерживайте форк или замену, если плагин не поддерживается. Начните с использования официального списка плагинов Vite и замен от сообщества.
• Различия в минификаторах: если трассировки стека или размеры байтов изменяются, протестируйте оба минификатора рядом, чтобы решить, следует ли корректировать генерацию исходных карт или оставить шаг совместимости.
• Лицензирование / коммерческие предложения: следите за дополнительными коммерческими слоями в связанных экосистемах (оцените закупки и соответствие, если планируете использовать инструменты поставщиков, упакованные с Rolldown). (Примечание: рассматривайте это как решение организационной политики.)
• Гигиена цепочки поставок: поскольку вводятся новые нативные бинарные файлы (связки, построенные на Rust), проверьте правила кэша CI и проверьте контрольные суммы бинарных файлов; поддерживайте белый список для необходимых нативных связок.

Почему стоит инвестировать время сейчас

• Более быстрые итерации CI и разработчиков напрямую приводят к меньшему количеству заблокированных PR и снижению затрат на облачные сборки.
• Сведение к единой поддерживаемой цепочке инструментов (парсер → трансформатор → минификатор → сборщик) уменьшает трудноотлаживаемые несоответствия между инструментами и долгосрочную поверхность обслуживания.
• Ранние последователи получают наибольшие выгоды в монорепозиториях и приложениях с высокой сложностью производственной сборки.

Рекомендуемая временная шкала для команд

• Малые приложения (1–2 поддерживающих): 1–2 недели для проверки и развертывания (после обновлений Node).
• Средние команды (несколько сервисов): 2–4 недели для поэтапной миграции (CI, плагины, проверки SSR).
• Большие организации/монорепозитории: рассматривайте это как миграцию платформы на квартал — координируйте работу между командами, запускайте параллельные канаречные конвейеры и выделяйте небольшую рабочую группу для совместимости плагинов и обновлений политики.

Итог Интеграция Vite с Rolldown является значительным изменением инструментов с реальным приростом производительности для команд полного стека — но она требует запланированной, основанной на тестах миграции: обновите Node, зафиксируйте версии, проверьте плагины и минификаторы и развертывайте постепенно. Рассматривайте это как миграцию платформы (образы CI, дополнительные нативные связки и производственные канарейки), и вы сможете превратить экономию времени сборки в продуктивность разработчиков и более надежные производственные сборки. (vite.dev)

Источник: Vite — Интеграция с Rolldown (официальная документация).

Источник

• Source