<b>swc ускоряет сборку, но легко проигрывает на нюансах конфигурации</b>

<b>swc ускоряет сборку, но легко проигрывает на нюансах конфигурации</b>

SWC берут ради скорости: трансформация TS/JS, JSX и часть плагинов обычно проходят заметно быстрее, чем в классических цепочках. Но выигрыш появляется только там, где пайплайн не перегружен лишней логикой.

За неделю в репах чаще всего всплывают одни и те же ошибки:
— ждут, что SWC заменит весь бандлер и всё вокруг;
— смешивают его с Babel-плагинами без проверки совместимости;
— не фиксируют target, module и helpers, а потом ловят странный runtime;
— забывают, что трансформация и bundling — это разные задачи.

Если нужен быстрый compile step для TypeScript/JSX, SWC обычно хорошо закрывает базу. Если у вас сложная экосистема макросов, нестандартные плагины или тонкая полифил-логика, сначала проверьте поведение на реальных файлах, а не на одном демо-компоненте.

Есть наблюдение которое стоит проверить: ускорение сборки часто ломают не исходники, а конфиг. Один лишний слой обёрток, лишний preset, лишний пересчёт sourcemap — и разница по времени тает.

Хорошая стратегия простая: сначала минимальный пайплайн, потом точечные расширения. SWC любит ясные правила и плохо переносит «магический» проект.