Что используешь для сборки проекта

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

Хорошая короткая формула:

В текущем проекте я использую Vite с TypeScript. В разработке он дает быстрый dev server и HMR. Перед релизом я проверяю build, code splitting, размер чанков, env vars и работу собранной версии через preview или CI. Если проект legacy или с тяжелой кастомной конфигурацией, я бы оставил Webpack и сначала оптимизировал его, а не мигрировал ради названия.

Замените Vite, Webpack, Next.js или другой инструмент на ваш реальный стек. Если вы не настраивали сборку с нуля, скажите честно. Например, вы работали с готовой конфигурацией, но понимаете важные части и знаете, что проверять при изменениях.

Самый сильный ответ привязан к ограничениям проекта. Для нового SPA часто уместен Vite. Для приложения на Next.js или Nuxt лучше говорить про сборку фреймворка, потому что там уже есть routing, SSR или SSG, обработка изображений и серверные части. Для старого enterprise-проекта Webpack может быть разумным выбором, если на нем держатся alias, loaders, Module Federation или кастомная обработка assets.

Не говорите, что один инструмент всегда лучше. На практике вы выбираете не только скорость. Важны совместимость, знания команды, стоимость миграции, интеграция с тестами, CI, monorepo и требования к браузерам.

Bundler это только часть процесса. В реальном frontend-проекте рядом обычно есть TypeScript, ESLint, formatter, тесты, обработка CSS, изображений и шрифтов, переменные окружения, source maps, анализ размера бандла и CI.

Пример нормальной структуры scripts для Vite-проекта:

{
  "scripts": {
    "dev": "vite",
    "lint": "eslint .",
    "typecheck": "tsc --noEmit",
    "build": "vite build",
    "preview": "vite preview"
  }
}

Это не единственно правильный вариант. Главное, чтобы проверки были явными. Если vite build транспилирует TypeScript, это еще не значит, что он сделал полноценный typecheck. Поэтому в CI часто запускают lint, typecheck, тесты и build отдельными шагами.

В dev-режиме сборщик помогает быстро писать код. В production-режиме он меняет код. Минифицирует, делит на чанки, подставляет env vars, добавляет hash к файлам, обрабатывает CSS и assets. Поэтому фраза про то, что локально все работает, не закрывает риск релиза.

На интервью хорошо звучат конкретные проверки. Собранная версия открывается через preview. Ленивые маршруты загружаются. При ошибке загрузки chunk есть понятный fallback. Картинки и шрифты не теряются. Source maps настроены осознанно. Размер initial bundle не вырос случайно. Переменные окружения не содержат секретов.

Code splitting нужен не ради галочки. Он помогает загрузить меньше кода при первом открытии, если разделение совпадает с реальным поведением пользователя. Частый безопасный старт, делить большие маршруты и тяжелые фичи.

Пример для React:

import { lazy, Suspense } from "react";

const AdminPage = lazy(() => import("./pages/AdminPage"));

function HomePage() {
  return <main>Главная</main>;
}

export function App({ section }: { section: "home" | "admin" }) {
  if (section === "admin") {
    return (
      <Suspense fallback={<div role="status">Загружаем раздел...</div>}>
        <AdminPage />
      </Suspense>
    );
  }

  return <HomePage />;
}

Это полезно, если admin-раздел нужен не всем пользователям. Fallback нужен не только для красоты. Без него пользователь увидит пустое место, пока браузер скачивает chunk. Для реального маршрута добавьте error boundary или понятный reload-сценарий, потому что после деплоя старый клиент может запросить уже удаленный файл.

Если разделить каждый маленький компонент, можно получить много запросов и плохой UX. После настройки смотрите analyzer и network waterfall, а не только размер одного файла.

CI/CD не заменяет сборщик, но делает сборку повторяемой. Хороший ответ звучит так. Вы не полагаетесь на локальную машину, а собираете проект в одинаковом окружении, по lockfile и с нужными env vars. Это снижает риск, что у вас в node_modules одна версия пакета, а на сервере другая.

Если у вас нет большого опыта с CI, не выдумывайте. Можно сказать честно. Вы не писали pipeline с нуля, но работали с ним как пользователь. Вы понимаете шаги install, lint, typecheck, test, build, deploy и знаете, какие ошибки frontend-сборки там чаще возникают.

Не изображайте человека, который писал сложный Webpack config с нуля, если это не ваш опыт. Лучше покажите осознанность в своей зоне ответственности.

Если вы работали с готовым Vite или Next.js проектом, можно ответить так:

С нуля сборщик я не писал, но регулярно работал с его настройками. Это scripts, env vars, alias, preview, source maps и production build. Когда менял зависимости или добавлял lazy loading, проверял размер бандла и поведение собранной версии.

Такой ответ звучит честнее, чем попытка перечислить loaders и plugins, которые вы не трогали. На интервью вас могут попросить объяснить конкретный config. Лучше заранее отделить личный опыт от теории.