Dev-сервер vs Production-сборка: почему нельзя деплоить dev-версию
Dev-сервер Vite запускает проект в режиме разработки. Его задача - максимально быстрый старт и мгновенное отображение изменений через Hot Module Replacement (HMR). Внутри используется нативная поддержка ES-модулей браузером: каждый импорт компонента, стиля или библиотеки превращается в отдельный HTTP-запрос. Откройте вкладку Network в DevTools при запущенном dev-сервере - вы увидите 52 отдельных запроса. Это нормально для локальной разработки, но катастрофично для пользователей на production.
Production-сборка - результат команды npm run build. Vite передаёт код Rollup, который выполняет бандлинг, tree-shaking и минификацию. На выходе - папка dist с оптимизированными статическими файлами. Та же самая страница, открытая через npm run preview, делает 13 сетевых запросов. Разница в четыре раза. Каждый лишний запрос добавляет задержку на DNS-резолвинг, TCP-рукопожатие и HTTP-оверхед. На медленных соединениях 52 запроса превращают загрузку страницы в секунды ожидания. Core Web Vitals проваливаются, пользователи уходят.
Деплой dev-версии на продакшен - ошибка, которую совершают начинающие разработчики. Симптомы: гигантские бандлы, сотни сетевых запросов, отсутствие минификации. Результат: низкий показатель Largest Contentful Paint (LCP) и штрафы от поисковых систем. Production-сборка решает эти проблемы на уровне инструмента сборки.
Создание production-сборки: команда npm run build и что внутри
Для создания дистрибутива выполните три шага. Первый: проверьте, что в package.json определён скрипт build. Стандартный шаблон Vite для React содержит строку "build": "vite build". Второй: запустите npm run build в терминале. Третий: дождитесь завершения и проверьте содержимое папки dist.
Под капотом происходит многоэтапный процесс. Vite анализирует граф зависимостей, начиная с точки входа index.html. Rollup обходит все импорты и определяет, какой код используется. Tree-shaking удаляет неиспользуемые экспорты: если вы импортировали только один хук из библиотеки, остальные функции не попадут в бандл. Затем esbuild минифицирует JavaScript - удаляет пробелы, комментарии, сокращает имена переменных. PostCSS обрабатывает стили. HTML-файл минифицируется и связывается с хешированными именами ассетов.
Хеши в именах файлов - критический механизм для кеширования. Файл main.a3f8b2c1.js содержит хеш, вычисленный из содержимого. При изменении кода хеш меняется, браузер загружает новую версию. Без хешей пользователи получали бы устаревший код из кеша. Папка dist содержит index.html и директорию assets с JS- и CSS-файлами. Эту структуру можно загружать на любой статический хостинг.
Конфигурация сборки настраивается в vite.config.js. Можно изменить выходную директорию через build.outDir, настроить code splitting через build.rollupOptions.output.manualChunks, задать базовый путь через base. Для проектов, размещаемых в поддиректории, параметр base критичен - без него сломаются все пути к ассетам.
Бандлинг и минификация: как Vite сокращает 52 запроса до 13
В dev-режиме Vite обслуживает каждый модуль как отдельный ES-модуль. Импорт React создаёт запрос к react.js, импорт компонента Button - запрос к Button.jsx, импорт стилей - запрос к button.css. Приложение из 50 модулей генерирует 50+ запросов. Это плата за мгновенный HMR: браузер загружает только изменённый модуль, не пересобирая весь граф.
В production-режиме Rollup объединяет модули в чанки. Стандартная стратегия: vendor-чанк для node_modules, main-чанк для кода приложения, отдельные чанки для lazy-загружаемых компонентов. 52 модуля превращаются в 3-5 JavaScript-файлов и 1-2 CSS-файла. Плюс index.html и пара служебных запросов - итого 13.
Минификация добавляет второй слой оптимизации. esbuild удаляет незначащие пробелы, комментарии, точки с запятой, сокращает имена переменных до одной буквы. Функция function calculateUserScore(userData) { ... } становится function a(b){...}. Размер файла уменьшается на 40-70%. Для пользователя на мобильной сети это разница между загрузкой за 2 секунды и за 6 секунд.
Проверьте разницу самостоятельно. Запустите dev-сервер, откройте Network в DevTools, обновите страницу - увидите 52 запроса. Выполните npm run build и npm run preview, откройте новую вкладку - увидите 13 запросов. Конкретные числа зависят от размера проекта, но пропорция сохраняется.
Локальное тестирование production-сборки: npm run preview
Команда npm run preview запускает статический веб-сервер, который раздаёт содержимое папки dist. Это точная симуляция production-окружения без деплоя на внешний хостинг. Vite preview server не поддерживает HMR и не выполняет трансформацию модулей на лету - он просто отдаёт статические файлы.
Перед каждым деплоем проверяйте три вещи. Первое: корректность путей. Если приложение использует React Router с BrowserRouter, все маршруты должны возвращать index.html. Vite preview server делает это автоматически, но на production-сервере нужна настройка fallback. Второе: переменные окружения. Все переменные с префиксом VITE_ должны быть определены во время сборки. Они вшиваются в код статически. Проверьте, что VITE_API_URL указывает на правильный эндпоинт. Третье: отсутствие ошибок в консоли браузера. Лениво загружаемые компоненты должны подгружаться без 404-ошибок.
Сравните поведение с dev-сервером. В preview-режиме нет мгновенного обновления, все запросы идут к статическим файлам, нет source maps (если не включены в конфиге). Это максимально приближено к реальному продакшену. Если страница работает в preview, она будет работать и после деплоя.
Роль Claude Desktop в процессе сборки: автоматизация и помощь
Claude Desktop - AI-инструмент, который ускоряет рутинные операции при подготовке к деплою. Он анализирует конфигурацию Vite, находит узкие места и предлагает конкретные улучшения. Запрос «проанализируй мой vite.config.js и предложи оптимизации для production-сборки» возвращает список проблем: отсутствие ручного code splitting для тяжёлых библиотек, неоптимальные настройки chunkSizeWarningLimit, пропущенные переменные окружения.
Практический сценарий: вы собрали бандл и видите в логах предупреждение о большом размере чанка. Копируете лог в Claude Desktop, описываете структуру проекта. Инструмент предлагает разбить чанк через dynamic import или настроить manualChunks в rollupOptions. Генерирует готовый фрагмент конфига с пояснениями.
Claude Desktop помогает генерировать скрипты для CI/CD. Запрос «напиши GitHub Actions workflow для сборки React-приложения на Vite и деплоя на Netlify» выдаёт готовый YAML с шагами checkout, setup-node, npm ci, npm run build и деплоем. Разработчик проверяет и адаптирует под свой проект - экономия 15-20 минут на написание с нуля. Инструмент не заменяет инженера, но снимает с него типовые задачи. Подобный подход к автоматизации через AI-агентов детально разобран в статье про Pre2Prod - превращение вайбкод-прототипа в production-ready MVP, где AI-агенты выполняют 41 специализированное ревью за 9 стадий.
Типичные ошибки при подготовке к деплою и как их избежать
Неправильный base path. Симптом: после деплоя в поддиректорию /app/ все ассеты загружаются с корня, получаете 404. Решение: установите base: '/app/' в vite.config.js. Vite подставит этот префикс ко всем путям в index.html и сгенерированных ссылках.
Забытые переменные окружения. Симптом: API-запросы уходят на localhost вместо production-сервера. Решение: создайте файл .env.production с переменной VITE_API_URL=https://api.example.com. Vite автоматически подхватывает .env.production при запуске vite build. Проверьте, что все переменные начинаются с префикса VITE_ - остальные не попадут в клиентский код.
CORS-ошибки из-за абсолютных путей. Симптом: запросы к API блокируются браузером. Решение: используйте относительные пути или настройте прокси на production-сервере. В dev-режиме проблема маскируется встроенным прокси Vite, в production она проявляется сразу.
Клиентский роутинг без серверной настройки. Симптом: переход по /about или обновление страницы на вложенном маршруте возвращает 404. Решение: настройте сервер на отдачу index.html для всех маршрутов. Для Nginx это try_files $uri /index.html, для Apache - mod_rewrite с FallbackResource. Vite preview server делает это автоматически, маскируя проблему.
Большие чанки. Симптом: один JS-файл весит больше 500 КБ, пользователи на мобильных сетях ждут загрузки. Решение: используйте динамические импорты. Замените статический импорт тяжёлого компонента на const HeavyComponent = lazy(() => import('./HeavyComponent')). Vite автоматически выделит его в отдельный чанк, который загрузится только при необходимости.
Интеграция сборки в CI/CD: автоматический деплой
Production-сборка должна выполняться в CI-окружении, а не на локальной машине разработчика. Это гарантирует повторяемость: та же версия Node.js, те же зависимости из package-lock.json, чистый npm ci вместо npm install. Локальная машина может иметь глобально установленные пакеты, изменённые конфиги или несохранённые изменения - всё это ломает сборку.
Минимальный GitHub Actions workflow для Vite-проекта:
name: Deploy to Production
on:
push:
branches: [main]
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '20'
cache: 'npm'
- run: npm ci
- run: npm run build
- name: Deploy to Netlify
uses: nwtgck/actions-netlify@v3
with:
publish-dir: './dist'
production-branch: main
env:
NETLIFY_AUTH_TOKEN: ${{ secrets.NETLIFY_AUTH_TOKEN }}
NETLIFY_SITE_ID: ${{ secrets.NETLIFY_SITE_ID }}
Ключевые моменты: кеширование node_modules через параметр cache в setup-node, использование npm ci для строгого соответствия lock-файлу, отдельный шаг для сборки. Переменные окружения передаются через secrets GitHub - они не хранятся в репозитории. Для команд, которые хотят глубже автоматизировать процесс, включая проверку качества кода, статья про DevSecOps с семью сканерами в едином пайплайне показывает, как объединить сборку с кросс-валидацией уязвимостей.
После настройки CI/CD каждый пуш в main-ветку автоматически запускает сборку и деплой. Разработчик не тратит время на ручную выгрузку файлов. Ошибки сборки видны сразу в логах Actions. Для отката достаточно ревертнуть коммит - пайплайн пересоберёт предыдущую версию.
Процесс подготовки React-проекта к деплою сводится к трём шагам: понять разницу между dev и production окружением, выполнить npm run build, проверить результат через npm run preview. Остальное - настройка CI/CD и работа с ошибками - автоматизируется один раз и работает на каждом релизе. Claude Desktop ускоряет рутинные операции, но ключевые решения остаются за разработчиком. Результат: быстрая загрузка, минимальное количество запросов, стабильная работа на любых устройствах.