swc ускоряет сборку, но ломается там, где ждут поведение Babel

swc ускоряет сборку, но ломается там, где ждут поведение Babel

swc часто ставят как «быстрый заменитель трансформации», но ошибка обычно одна: от него ждут полной совместимости без проверки краевых случаев. Он хорошо режет время на compile/transpile, но не отменяет аудит того, что именно попадает в output.

За неделю в репах чаще всего всплывают три места:
— decorators и metadata: поведение зависит от настроек и легко расходится с ожиданиями;
— JSX runtime: проверь, кто реально подставляется в import source;
— ESM/CJS: тесты и Node-среда могут по-разному переживать один и тот же output.

Если проект живёт на TypeScript, swc лучше встраивать точечно: transpile-only, а типы оставить tsc. Это не «дублирование работы», а разделение задач: один инструмент быстро превращает код в JS, другой ловит ошибки типов и контрактов.

Ещё один частый промах — мерить только speed of build и игнорировать bundle behavior. Быстрый compile не спасает, если в рантайме вылезли лишние polyfill'ы, неверные helper'ы или сломанный interop.

Проверяйте swc на своих синтаксических фичах, а не на синтетическом hello world: тогда ускорение останется ускорением, а не источником тихих регрессий.