Трансформации, которых нет в SWC
## Природа трансформаций в SWC
SWC представляет собой высокопроизводительный компилятор JavaScript и TypeScript, реализованный на Rust и ориентированный на замену Babel в задачах транспиляции и минификации. Его модель трансформаций базируется на работе с AST (Abstract Syntax Tree) и наборе встроенных посетителей узлов, реализующих конкретные преобразования кода.
В отличие от Babel, где трансформации формируются как обширная экосистема плагинов на JavaScript, SWC стремится к более ограниченному, но предсказуемому набору встроенных и нативных трансформаций. Это архитектурное решение напрямую влияет на спектр доступных преобразований и объясняет наличие функциональных пробелов.
---
## Классы трансформаций, отсутствующих в SWC
### Экспериментальные и Stage-преобразования ECMAScript
Babel традиционно поддерживает широкий спектр предложений TC39 на разных стадиях (Stage 0–3), предоставляя возможность использовать синтаксис задолго до его стандартизации.
В SWC поддержка таких предложений значительно уже и в основном ограничивается:
* уже стабилизированными фичами ECMAScript;
* наиболее распространёнными stage-3 предложениями.
Отсутствуют или частично реализованы трансформации для:
* устаревших proposal-синтаксисов, редко используемых в современных кодовых базах;
* нестабильных Stage 0–1 предложений;
* некоторых устаревших экспериментальных синтаксических расширений, поддерживаемых Babel через плагины.
Это создаёт разрыв при миграции проектов с глубокой зависимостью от Babel preset-env с расширенными proposal-настройками.
---
### Макросистемы и транспиляционные расширения
Экосистема Babel включает механизмы, выходящие за рамки обычной транспиляции:
* `babel-plugin-macros`
* compile-time eval расширения
* пользовательские DSL поверх JavaScript
SWC не имеет эквивалента подобного уровня интеграции макросов на уровне стандартного пайплайна трансформаций. Отсутствуют:
* декларативные макросы, интегрируемые в синтаксис сборки;
* автоматическая подстановка compile-time логики через аннотации;
* динамическая подмена кода на основе пользовательских макро-плагинов без явного Rust-кода.
---
### Фреймворк-специфичные трансформации
Babel-экосистема содержит множество специализированных трансформаций, разработанных под конкретные фреймворки и библиотеки:
* styled-components Babel plugin (оптимизация классов и имён);
* emotion plugin (улучшение SSR и имён классов);
* react-refresh integration через Babel;
* сложные JSX-runtime кастомизации.
В SWC часть React-трансформаций реализована нативно, однако многие расширенные сценарии отсутствуют:
* глубокая оптимизация CSS-in-JS библиотек на уровне AST;
* специфические трансформации для runtime-инъекций;
* сложные рефакторинговые плагины для JSX-экосистемы.
---
### Трансформации, зависящие от экосистемы Babel
Некоторые преобразования исторически не связаны с самим ECMAScript, а существуют как часть Babel-подхода к кодогенерации:
* автоматическая инъекция polyfill через `@babel/preset-env` + core-js;
* conditional import rewriting на уровне плагинов;
* сложные AST-модификации для legacy-браузерной поддержки.
SWC реализует часть этих задач через интеграции с bundler-уровнем (например, Next.js), но не предоставляет эквивалент гибкой плагинной системы.
---
### Codemod-ориентированные трансформации
Babel-экосистема широко используется для одноразовых миграционных преобразований кода:
* массовое переименование API;
* структурные изменения импортов;
* миграции версий React/Vue;
* автоматическая адаптация breaking changes.
SWC не предоставляет полноценной инфраструктуры codemod-плагинов. Подобные задачи обычно выносятся в отдельные инструменты:
* jscodeshift (Babel-based);
* recast;
* ts-morph (в TypeScript-экосистеме).
---
## Причины ограничений трансформационной модели SWC
### Ориентация на производительность
SWC оптимизирован под скорость компиляции. Любая расширяемость через динамические JavaScript-плагины увеличивает стоимость:
* интерпретации пользовательского кода;
* взаимодействия между JS и Rust-ядром;
* усложнения пайплайна AST.
Поэтому архитектура SWC смещена в сторону статически скомпилированных трансформаций.
---
### Rust-центричная архитектура
В SWC трансформации реализуются как Rust-visitor’ы, что формирует несколько ограничений:
* необходимость компиляции плагинов;
* более высокий порог входа;
* отсутствие runtime-плагинов уровня Babel.
Это резко уменьшает количество «длинного хвоста» экосистемных плагинов.
---
### Фокус на стандартизированном наборе задач
SWC стремится покрыть:
* JSX/TS трансформации;
* базовые ECMAScript преобразования;
* minification;
* bundler integration (Next.js и др.).
Все нестандартные сценарии сознательно выносятся за рамки ядра.
---
## Подходы к замене отсутствующих трансформаций
### Использование SWC plugin API (Rust)
Основной путь расширения SWC — написание нативных плагинов на Rust с использованием visitor-модели AST.
Типовая структура трансформации включает:
* обход узлов программы;
* сопоставление паттернов;
* построение нового AST;
* генерацию обновлённого кода.
Пример концептуального поведения трансформации:
* поиск `CallExpression`;
* проверка имени функции;
* замена аргументов или обёртка выражения.
Такой подход обеспечивает высокую производительность, но требует глубокого понимания AST-структуры SWC.
---
### Комбинирование SWC и Babel
Распространённый архитектурный паттерн — гибридный пайплайн:
* SWC используется для быстрых стандартных трансформаций;
* Babel подключается точечно для отсутствующих плагинов.
Такая схема применяется при наличии:
* legacy Babel macros;
* сложных CSS-in-JS плагинов;
* экспериментальных proposal transforms.
Недостатком становится увеличение времени сборки и усложнение конфигурации.
---
### Вынесение трансформаций на уровень сборщика
В современных пайплайнах часть логики переносится в bundler:
* Vite plugins;
* Next.js compiler pipeline;
* esbuild transforms (частично).
SWC при этом используется как низкоуровневый транспилятор, а не как единственный слой трансформаций.
---
### Использование codemod-инструментов
Для миграционных и структурных преобразований применяются отдельные инструменты:
* AST codemod-утилиты на базе Babel;
* TypeScript AST tools;
* специализированные миграционные скрипты.
SWC в таких сценариях обычно не используется напрямую из-за отсутствия развитой codemod-экосистемы.
---
## Практика реализации пользовательских трансформаций в SWC
### Visitor-модель AST
SWC использует модель посетителей, где каждый узел AST может быть обработан через соответствующий метод:
* выражения;
* объявления;
* импорты;
* JSX-узлы.
Трансформация строится как последовательность правил замены узлов.
---
### Манипуляции с узлами
Типовые операции включают:
* замена идентификаторов;
* изменение структуры вызовов;
* инлайнинг выражений;
* удаление узлов дерева;
* добавление новых конструкций.
Особое внимание требуется к сохранению корректности:
* scope binding;
* hoisting поведения;
* семантики this;
* порядка вычислений.
---
### Ограничения AST-модификаций SWC
В отличие от Babel, где часть абстракций скрыта, SWC предоставляет более «низкоуровневую» модель:
* меньше автоматических нормализаций;
* больше ответственности за корректность AST;
* отсутствие универсальных helper-утилит для всех сценариев.
Это делает сложные трансформации более хрупкими, но более быстрыми.
---
## Сравнительный контекст с экосистемой Babel
Экосистема Babel формировалась как модульная система плагинов, где трансформации являются основным продуктом. В результате:
* огромное количество community-плагинов;
* высокая гибкость;
* наличие нестандартных DSL и макросов.
SWC, напротив, развивает модель:
* фиксированного набора высокопроизводительных трансформаций;
* ограниченного, но расширяемого через Rust API ядра;
* интеграции на уровне фреймворков (Next.js и аналогов).
Разница проявляется особенно сильно в области:
* экспериментальных синтаксисов;
* compile-time метапрограммирования;
* кастомных кодогенераторов;
* сложных фреймворк-специфичных оптимизаций.