<b>swc ускоряет сборку, но ломается там, где ждут от него «как у TypeScript»</b>

<b>swc ускоряет сборку, но ломается там, где ждут от него «как у TypeScript»</b>

swc часто берут ради одного: быстрый transpile. И это нормальная причина. Он хорошо снимает нагрузку с dev-сборки, особенно когда в проекте много файлов и JSX/TSX, а ждать хочется меньше.

Но у swc есть важная граница: это не полный заменитель всего, что делает TypeScript. Он быстро переписывает код, но не заменяет типовую проверку. Значит схема почти всегда такая: <code>swc для трансформации</code> + <code>tsc --noEmit</code> для типов.

На практике ошибки начинаются в трёх местах:
— рассчитывают на поведение, которое есть в tsc, но не совпадает в swc;
— включают плагины и трансформации без проверки итогового рантайм-кода;
— забывают, что часть экосистемы завязана на синтаксис и флаги TypeScript, а не на «просто TS-файлы».

Если нужен быстрый старт, проверьте минимум:
— JSX runtime и import source;
— decorators, emit metadata, legacy/standard поведение;
— path aliases и их совпадение с bundler/Node;
— target для старых браузеров и серверного окружения;
— sourcemap и корректность stack trace в dev.

Ещё один частый промах: ставят swc в build pipeline, но не проверяют, как он ведёт себя с ESM/CJS-гибридом. Тут обычно всплывают export default, synthetic imports и различия в модульном резолве.

swc полезен там, где нужен быстрый транспайл и предсказуемый пайплайн. Но если вокруг него не поставить tsc, линтер и тесты, скорость превращается в очень дорогую ошибку.