Типичные проблемы при миграции

## Несовместимость конфигураций Babel и SWC Одной из первых проблем при переходе на SWC становится прямое перенесение конфигурации из Babel. Несмотря на схожесть задач, подход к настройке у этих инструментов принципиально различается. Babel опирается на систему плагинов и пресетов, где каждое преобразование подключается декларативно. SWC использует компактную JSON-конфигурацию и ограниченный набор встроенных трансформаций, что делает невозможным прямое копирование `.babelrc`. Типичные несоответствия: * отсутствие эквивалента некоторых Babel-плагинов * различия в именах опций (`presets` vs `jsc.transform`) * другая структура конфигурационного файла (`.swcrc` вместо `.babelrc`) * ограниченная кастомизация AST-трансформаций Особенно часто ломается логика проектов, где Babel был расширен множеством кастомных плагинов. --- ## Потеря или отсутствие Babel-плагинов Экосистема Babel значительно старше и богаче. SWC не предоставляет полного набора аналогов. Проблемные категории: * трансформации экспериментального синтаксиса * кастомные макросы * специализированные оптимизации кода * плагины для i18n, inline-замен и статического анализа SWC поддерживает плагины, но они реализованы через Rust/WASM и имеют другие ограничения: * меньшее количество готовых решений * более сложная разработка собственных плагинов * ограниченный доступ к экосистеме npm-плагинов Babel В результате часть логики приходится переносить на этап сборки или полностью переписывать. --- ## Различия в обработке TypeScript SWC заявляет нативную поддержку TypeScript, но она ограничена трансляцией, а не полноценной типизацией. Типичные проблемы: * игнорирование некоторых проверок типов (проверка должна выполняться отдельно через `tsc --noEmit`) * различия в поведении `const enum` * нюансы работы с декораторами * несовпадение вывода при `isolatedModules` Особенно заметны расхождения в больших кодовых базах, где TypeScript использовался не только как типизация, но и как часть сборочного пайплайна. --- ## Декораторы и их несовместимость Поддержка декораторов — один из наиболее проблемных участков миграции. Babel и SWC реализуют разные версии спецификации: * legacy decorators (Babel) * stage-3 decorators (частично поддерживаются SWC) Проблемы проявляются в: * порядке вызова декораторов * поведении metadata (`reflect-metadata`) * совместимости с ORM (TypeORM, Sequelize и др.) * работе с Angular-подобными паттернами Код, который полагается на legacy-поведение, часто требует переписывания. --- ## JSX трансформация и различия runtime SWC и Babel по-разному обрабатывают JSX. Основные отличия: * разные runtime (`automatic` vs `classic`) * отличия в импортах функций JSX * несовпадение генерации ключей и оптимизаций * различия в обработке фрагментов и spread-атрибутов В проектах React это приводит к: * неожиданным изменениям в итоговом bundle * проблемам с библиотеками, зависящими от старого JSX runtime * расхождениям между dev и production сборками --- ## Различия в source maps SWC генерирует source maps быстрее, но их структура может отличаться от Babel. Типичные проблемы: * смещение строк в отладчике * некорректные stack traces в production * несовместимость с некоторыми инструментами мониторинга ошибок Особенно заметно при использовании Webpack или Vite с кастомными настройками sourcemap chaining. --- ## Интеграция с сборщиками Переход на SWC часто затрагивает не только трансформер, но и сборочную систему. ### Webpack При использовании `swc-loader` возникают: * различия в порядке loaders * несовместимость с некоторыми Babel-only плагинами webpack * проблемы с HMR в нестандартных конфигурациях ### Rollup Интеграция через плагины SWC может приводить к: * отличиям в tree-shaking * изменению порядка модулей * некорректной обработке ESM/CJS гибридов ### Next.js Хотя SWC интегрирован по умолчанию, миграция с Babel-конфигурации приводит к: * игнорированию кастомных Babel-плагинов * необходимости переноса логики в next.config.js * различиям в оптимизации production build --- ## Потеря кастомных трансформаций Одной из ключевых проблем становится отказ от сложных Babel-плагинов. Типичные кейсы: * автоматическая инъекция кода (logging, tracing) * модификация импортов * inline-генерация кода на основе AST * feature flags на уровне компиляции SWC не всегда способен воспроизвести подобное поведение без написания Rust-плагина, что существенно повышает стоимость миграции. --- ## Различия в minification SWC имеет встроенный minifier, который отличается от terser. Проблемы: * иное переименование переменных * различия в inline-оптимизациях * нестабильность output при одинаковом input * различия в dead code elimination Это может влиять на: * размер bundle * кэширование в CDN * воспроизводимость сборок --- ## Особенности работы с monorepo В монорепозиториях SWC может вести себя иначе, чем Babel. Проблемные зоны: * резолвинг зависимостей между пакетами * различия в обработке symlinks * несовместимость с кастомными alias-резолверами * проблемы с caching между workspace-пакетами Особенно часто проявляется при использовании pnpm или yarn workspaces. --- ## Несовместимость с макросами и codegen Babel активно используется как среда для макросов (например, styled-components, emotion, custom macros). SWC не предоставляет эквивалентной универсальной системы. Последствия: * макросы не выполняются на этапе трансформации * требуется перенос логики в отдельные плагины сборщика * усложнение архитектуры build pipeline --- ## Различия в обработке современных ECMAScript фич Несмотря на поддержку современных стандартов, SWC и Babel могут расходиться в деталях реализации: * optional chaining в сложных выражениях * nullish coalescing в комбинации с логическими операторами * private class fields * top-level await в смешанных модулях Эти различия чаще всего проявляются в старых target-окружениях (ES5/ES2017). --- ## Проблемы совместимости с тестовыми средами При использовании Jest и аналогичных инструментов возникают расхождения: * `babel-jest` vs `@swc/jest` различия в трансформации * несовпадение snapshot-выхода * проблемы с ESM модулями * различия в hoisting mock-ов Это приводит к нестабильным тестам при частичной миграции. --- ## Различия в производительности и побочные эффекты SWC значительно быстрее Babel, но это влияет на поведение пайплайна: * изменяется порядок кеширования * сокращается время, в котором проявляются race conditions в сборке * некоторые ошибки Babel «маскировались» медленной сборкой Быстрая компиляция иногда делает проблемы конфигурации более заметными. --- ## Несовместимость с инструментами анализа кода Инструменты, завязанные на Babel AST, могут работать некорректно: * eslint-плагины с Babel parser * кастомные codemod-утилиты * инструменты статического анализа, зависящие от Babel AST SWC использует собственное представление AST, что требует адаптации tooling-цепочки.