Какой сборщик используете

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

Понимаете ли вы, зачем сборщик нужен именно в вашем проекте, или называете Webpack по привычке с фронтенда. Для бэкенда на Node.js следом часто спрашивают: зачем вообще собирать серверный код, если Node выполняет модули как есть.

Как отвечать

Назовите свой инструмент и сразу причину. Для сервера на Node.js типичные варианты такие:

• без бандла: TypeScript компилируется tsc в dist, в прод едет он плюс node_modules. Самый прозрачный путь. Свежие версии Node умеют запускать .ts напрямую, вырезая типы, но проверки типов при этом нет, и tsc --noEmit в CI остаётся;
• esbuild и обёртки над ним: собирают сервис в один файл за доли секунды. Полезно для serverless-функций, где размер влияет на холодный старт, и для лёгких Docker-образов;
• SWC: быстрая транспиляция без проверки типов, в NestJS включается как builder в nest-cli.json;
• Rollup: выбор для библиотек, когда пакет публикуется в ESM и CommonJS с правильным полем exports в package.json;
• Vite: фронтенд и SSR-приложения, dev-сервер на нативных ES-модулях;
• Webpack: живёт в старых проектах, для нового серверного кода его выбирают редко.

Дальше подводные камни, которые выдают реальный опыт: нативные модули вроде bcrypt или sharp в бандл не вклеиваются, их помечают как external; динамические require сборщик не видит; в ESM нет __dirname, нужен import.meta.dirname или fileURLToPath; для читаемых стектрейсов нужны source maps и флаг --enable-source-maps.

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

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

Отвечают «Webpack» для серверного проекта и не могут объяснить, что он там даёт по сравнению с обычным tsc.

Путают сборщик, транспилятор и проверку типов: считают, что esbuild найдёт ошибку типов. Он типы только вырезает.

Бандлят всё подряд вместе с нативными зависимостями и получают падение на старте в контейнере с другой архитектурой процессора или другой libc.