Ограничения и несовместимости

## Общая природа ограничений SWC SWC (Speedy Web Compiler) проектировался как высокопроизводительная альтернатива Babel и TSC-трансформации, реализованная на Rust. Архитектура, ориентированная на скорость, накладывает ряд принципиальных ограничений: упрощённую модель трансформаций, сокращённый слой абстракций над AST и сознательный отказ от части гибкости, характерной для JavaScript-экосистемы трансформаций. Ключевая особенность заключается в том, что SWC не стремится быть универсальной платформой плагинов уровня Babel, а скорее реализует фиксированный набор трансформаций с ограниченными точками расширения. --- ## Несовместимость с Babel-экосистемой Одним из наиболее заметных ограничений является неполная совместимость с Babel-плагинами и экосистемой трансформаций. ### Различия AST и модели трансформаций Babel использует собственный AST на базе ESTree с глубокой поддержкой плагинов, позволяющих модифицировать практически любой узел дерева. SWC использует свой внутренний формат AST, оптимизированный под производительность, что приводит к следующим последствиям: * Babel-плагины нельзя использовать напрямую * Большинство кастомных трансформаций требуют переписывания под SWC API * Поведение отдельных узлов может отличаться на уровне мелких синтаксических деталей ### Отсутствие полной эквивалентности трансформаций Некоторые Babel-трансформации: * @babel/plugin-proposal-* * @babel/plugin-transform-* не имеют прямых аналогов или реализованы частично. --- ## Ограничения трансформаций JavaScript SWC поддерживает широкий набор трансформаций ECMAScript, однако ряд edge-case сценариев остаётся вне покрытия. ### Поддержка новых стандартов Поддержка современных фич JavaScript зависит от версии SWC и может включать: * частичную реализацию stage-пропозалов * отсутствие поведения для нестабильных спецификаций * расхождения в обработке редких синтаксических конструкций ### Ограничения в сложных преобразованиях Некоторые типы трансформаций либо упрощены, либо реализованы без глубокого анализа контекста: * сложная рефакторизация scope-aware логики * трансформации с побочными эффектами анализа типов * продвинутые оптимизации кода на уровне Babel-плагинов --- ## TypeScript: различия и неполная совместимость SWC поддерживает трансформацию TypeScript, но не является полноценной заменой `tsc`. ### Отсутствие type-checking SWC выполняет только транспиляцию, не осуществляя проверку типов. Это приводит к необходимости параллельного использования TypeScript Compiler для валидации кода. ### Частичная поддержка синтаксиса Поддержка TypeScript включает: * интерфейсы * generics * enums * namespaces (с ограничениями) Однако существуют несовместимости: * некоторые advanced mapped types не учитываются в трансформации * специфические edge-case конструкции декораторов в TS могут вести к расхождениям * различия в emit-стратегии по сравнению с tsc --- ## Декораторы и экспериментальные стандарты Поддержка декораторов остаётся одной из наиболее сложных областей. ### Историческая неоднозначность стандарта Существуют несколько несовместимых спецификаций декораторов: * legacy decorators (Babel/TypeScript старого режима) * TC39 stage-3/4 варианты SWC поддерживает их частично, но: * поведение может отличаться от TypeScript emit * порядок применения декораторов может не совпадать в edge-case сценариях * ограничена поддержка metadata reflection ### Экспериментальные предложения Некоторые stage proposals реализованы неполно или отключены по умолчанию, что создаёт расхождения между сборками Babel и SWC. --- ## JSX/React особенности SWC широко используется в React-экосистеме, однако JSX-трансформация имеет свои ограничения. ### Отличия в JSX runtime SWC поддерживает: * classic runtime * automatic runtime (React 17+) Ограничения проявляются в: * различиях генерации import-стратегий * несовпадении с Babel transform runtime helpers * ограниченной кастомизации JSX factory на уровне сложных конфигураций ### Edge-case поведение В редких случаях наблюдаются различия: * при вложенных JSX-фрагментах * при условных JSX-выражениях с нестандартной типизацией * при смешении runtime моделей --- ## Плагины SWC: зрелость и ограничения Экосистема плагинов SWC значительно менее развита по сравнению с Babel. ### Ограниченная API модель SWC-плагины: * написаны на Rust или WebAssembly * имеют ограниченный доступ к AST API * не поддерживают динамическую композицию трансформаций уровня Babel ### Практические последствия * отсутствие богатой экосистемы готовых плагинов * необходимость реализации кастомной логики вручную * ограниченная совместимость между версиями SWC --- ## Source maps и отладка Генерация source maps в SWC функциональна, но не всегда идентична Babel. ### Основные ограничения: * возможные расхождения в точности mapping-а в сложных трансформациях * несовпадение stack trace в development режиме * ограниченная детализация при агрессивных оптимизациях Это особенно заметно при использовании minify + transform pipeline одновременно. --- ## Минификация и различия с Terser SWC включает встроенный minifier, однако он не является полной заменой Terser. ### Ограничения minify-движка: * менее зрелая система компрессии * ограниченный набор оптимизаций dead code elimination * менее точная работа с side effects анализа ### Различия в результатах: * различный output для одинакового входного кода * вариативность именования идентификаторов * отличия в tree-shaking поведении при комплексных зависимостях --- ## Сборка модулей и ESM/CJS SWC поддерживает трансформацию модульных систем, но с рядом ограничений. ### ESM ↔ CJS трансформации: * возможны расхождения в интерпретации default export * частичная поддержка dynamic import * ограниченная точность при interop-обёртках ### Edge cases: * смешанные модули могут давать неоднозначный output * различия в поведении re-export конструкций --- ## Интеграции (Webpack, Vite, Next.js) и ограничения SWC активно используется в современных сборщиках, но интеграции не всегда полностью эквивалентны Babel-стеку. ### Webpack (swc-loader) * ограниченная совместимость с Babel-only loader pipeline * невозможность использования Babel-плагинов внутри SWC этапа * различия в caching strategy ### Vite * SWC может конфликтовать с esbuild pipeline при смешанных конфигурациях * различия в HMR поведении при трансформациях JSX ### Next.js * SWC встроен как основной компилятор * некоторые Babel overrides недоступны или игнорируются * ограниченная кастомизация трансформационного пайплайна --- ## Polyfills и runtime-зависимости SWC не включает polyfills по умолчанию. ### Последствия: * необходимость ручного подключения core-js или аналогов * отсутствие автоматической подстановки runtime для старых окружений * различия между Babel preset-env и SWC target-based трансформацией --- ## Ошибки и диагностические ограничения Сообщения об ошибках SWC ориентированы на скорость компиляции, а не на расширенную диагностику. ### Ограничения: * менее детализированные сообщения по сравнению с TypeScript Compiler * ограниченный контекст ошибок в сложных AST трансформациях * отсутствие расширенных suggestions для исправления --- ## Производственные ограничения и поведенческие расхождения При использовании SWC в production окружениях проявляются системные ограничения, связанные с философией «fast-first». ### Основные аспекты: * приоритет скорости над глубиной анализа * упрощённая модель совместимости с legacy кодом * потенциальные расхождения с Babel/TS output в крайних случаях * необходимость строгого контроля конфигураций для предотвращения subtle bugs Эти особенности делают SWC инструментом, требующим предсказуемой и стандартизированной кодовой базы, особенно в больших проектах с историческим legacy-кодом и сложной системой трансформаций.