Почему Vite

По мере того как веб-приложения росли в размерах и сложности, инструменты, используемые для их сборки, начали с трудом поспевать за этим ростом. Разработчики, работающие над крупными проектами, столкнулись с мучительно медленным запуском сервера разработки, вялыми «горячими» обновлениями и долгим временем сборки для продакшена. Каждое новое поколение инструментов сборки улучшало предыдущее, но эти проблемы сохранялись.

Vite был создан, чтобы решить их. Вместо того чтобы постепенно улучшать существующие подходы, он переосмыслил то, как код должен доставляться во время разработки. С тех пор Vite прошел через несколько мажорных версий, каждый раз адаптируясь к новым возможностям экосистемы: от использования нативных ES-модулей в браузере до перехода на цепочку инструментов, полностью работающую на Rust.

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

Истоки

Когда Vite только создавался, браузеры как раз получили широкую поддержку ES-модулей (ESM) — способа загрузки JavaScript-файлов напрямую, без необходимости предварительной сборки их в один файл. Традиционные инструменты сборки (часто называемые бандлерами) обрабатывали всё ваше приложение целиком, прежде чем что-либо могло быть отображено в браузере. Чем больше было приложение, тем дольше приходилось ждать.

Vite применил другой подход. Он разделил работу на две части:

• Зависимости (библиотеки, которые редко меняются) предварительно собираются один раз с использованием быстрых нативных инструментов, поэтому они готовы мгновенно.
• Исходный код (код вашего приложения, который часто меняется) доставляется по требованию через нативные ESM. Браузер загружает только то, что необходимо для текущей страницы, а Vite трансформирует каждый файл по мере его запроса.

Это означало, что запуск сервера разработки стал почти мгновенным, независимо от размера приложения. Когда вы редактировали файл, Vite использовал горячую замену модулей (HMR) поверх нативных ESM, чтобы обновить только этот модуль в браузере, без полной перезагрузки страницы или ожидания пересборки.

В сервере разработки на основе бандлера всё приложение собирается в пакет перед тем, как оно может быть отдано клиенту.

В сервере разработки на основе ESM модули предоставляются по требованию, когда браузер запрашивает их.

Vite не был первым инструментом, исследовавшим этот подход. Snowpack стал пионером разработки без бандлинга (unbundled development) и вдохновил Vite на создание предварительной сборки зависимостей. WMR от команды Preact вдохновил на создание универсального API плагинов, который работает как в разработке, так и при сборке. @web/dev-server повлиял на архитектуру сервера Vite 1.0. Vite опирался на эти идеи и развивал их.

Несмотря на то, что ESM без бандлинга отлично работает во время разработки, отправка его в продакшен всё ещё неэффективна из-за дополнительных сетевых запросов при вложенных импортах. Вот почему бандлинг всё ещё необходим для оптимизированных продакшен-сборок.

Рост вместе с экосистемой

По мере созревания Vite, фреймворки начали внедрять его в качестве своего слоя сборки. Его API плагинов, основанный на конвенциях Rollup, сделал интеграцию естественной, не требуя от фреймворков обходных путей для работы с внутренностями Vite. Nuxt, SvelteKit, Astro, React Router, Analog, SolidStart и другие выбрали Vite в качестве основы. Такие инструменты, как Vitest и Storybook, также построены на нём, расширяя сферу применения Vite за пределы сборки приложений. Бэкенд-фреймворки, такие как Laravel и Ruby on Rails, интегрировали Vite для своих конвейеров фронтенд-ресурсов.

Этот рост не был односторонним. Экосистема формировала Vite так же сильно, как Vite формировал экосистему. Команда Vite запускает vite-ecosystem-ci, который тестирует основные проекты экосистемы при каждом изменении в Vite. Здоровье экосистемы — это не второстепенная задача, а часть процесса выпуска релизов.

Единая цепочка инструментов

Изначально Vite опирался на два отдельных инструмента «под капотом»: esbuild для быстрой компиляции во время разработки и Rollup для тщательной оптимизации в продакшен-сборках. Это работало, но поддержка двух конвейеров привносила несоответствия: разное поведение трансформаций, раздельные системы плагинов и растущее количество связующего кода для их согласования.

Был создан Rolldown, чтобы объединить оба инструмента в единый бандлер: написанный на Rust для нативной скорости и совместимый с тем же API плагинов, на который уже полагается экосистема. Он использует Oxc для парсинга, трансформации и минимизации кода. Это дает Vite сквозную цепочку инструментов, где инструмент сборки, бандлер и компилятор поддерживаются вместе и развиваются как единое целое.

Результатом является один согласованный конвейер от разработки до продакшена. Миграция проводилась осторожно: сначала была выпущена техническая превью-версия, чтобы ранние последователи могли подтвердить изменения, CI экосистемы выявил проблемы совместимости на раннем этапе, а слой совместимости сохранил существующие конфигурации.

Куда движется Vite

Архитектура Vite продолжает развиваться. Несколько инициатив формируют его будущее:

• Режим полной сборки: ESM без бандлинга был правильным компромиссом при создании Vite, потому что ни один инструмент не был одновременно достаточно быстрым и обладал необходимыми возможностями HMR и плагинов для сборки во время разработки. Rolldown меняет это. Поскольку исключительно большие кодовые базы могут испытывать медленную загрузку страниц из-за большого количества сетевых запросов, команда исследует режим, в котором сервер разработки собирает код аналогично продакшену, снижая сетевые накладные расходы.

• Environment API: Вместо того чтобы рассматривать «клиент» и «SSR» как единственные цели сборки, Environment API позволяет фреймворкам определять кастомные среды (edge-рантаймы, сервис-воркеры и другие цели развёртывания), каждая со своими правилами разрешения модулей и выполнения. Поскольку места и способы запуска кода продолжают диверсифицироваться, модель Vite расширяется вместе с ними.

• Развитие вместе с JavaScript: Благодаря тесному сотрудничеству Oxc и Rolldown с Vite, новые функции языка и стандарты могут внедряться быстро во всей цепочке инструментов, не дожидаясь обновлений от сторонних зависимостей.

Цель Vite — не быть окончательным, застывшим инструментом, а развиваться вместе с веб-платформой и разработчиками, которые на ней строят свои проекты.