Какие билдеры и инструменты для сборки использовали кроме Webpack?

Что проверяют

Понимаете ли вы, чем сборщики отличаются по устройству, а не только по скорости в бенчмарке. Следом часто спрашивают, почему в Vite разработка быстрая и какие проблемы вылезали при переезде с Webpack.

Как отвечать

Назовите то, с чем работали сами, и для каждого инструмента скажите, где он уместен:

• Vite: в разработке отдаёт исходники как нативные ES-модули и один раз заранее собирает зависимости, поэтому старт почти не зависит от размера проекта. Продакшен-сборку исторически делал Rollup, новые версии переходят на Rolldown, сборщик на Rust с API Rollup. Переменные окружения доступны через import.meta.env и только с префиксом VITE_;
• Rollup: стандарт для библиотек, выпускает ESM и CommonJS из одного кода, хороший tree shaking;
• esbuild: сборщик на Go, очень быстрый, но типы TypeScript просто вырезает, без проверки;
• Rspack: сборщик на Rust с API, совместимым с Webpack. Ускоряет сборку без переписывания конфигурации и большинства лоадеров;
• Turbopack: сборщик Next.js, в актуальных версиях включён по умолчанию;
• Parcel: сборка без конфигурации для небольших проектов;
• SWC и Babel: транспиляторы, а не сборщики, их встраивают внутрь цепочки;
• Gulp: исполнитель задач, а не бандлер. Встречается в старых проектах для SCSS и картинок.

Сильный ответ содержит историю миграции: что было, почему переехали, что получили. Например, время холодного старта dev-сервера и продакшен-сборки до и после. Цифры приводите свои, из реального проекта.

Где спотыкаются

Не учитывают, что в Vite dev-сервер и продакшен-сборка работают разными механизмами. Ошибка с CommonJS-зависимостью или порядком CSS может проявиться только в сборке.

Убирают tsc из процесса. esbuild и SWC типы не проверяют, поэтому в CI нужен отдельный tsc --noEmit, иначе ошибки типов уезжают в прод.

Ставят Gulp в один ряд с Vite. Так видно, что разницу между исполнителем задач и бандлером с графом модулей кандидат не чувствует.