Анализ существующей Babel-конфигурации
Анализ Babel-конфигурации начинается с определения структуры подключённых пресетов, плагинов и параметров транспиляции, поскольку именно они формируют фактическое поведение трансформации исходного кода JavaScript.
## Структура конфигурационных файлов Babel
В типичном проекте Babel-конфигурация может быть представлена несколькими вариантами:
* `.babelrc` / `.babelrc.json`
* `babel.config.js`
* поле `babel` в `package.json`
* набор окружений через `env` внутри конфигурации
Наиболее критичным для анализа является файл `babel.config.js`, так как он позволяет динамически формировать конфигурацию:
```js
module.exports = {
presets: [
['@babel/preset-env', {
targets: {
browsers: ['>0.25%', 'not dead']
},
useBuiltIns: 'usage',
corejs: 3
}]
],
plugins: [
'@babel/plugin-proposal-class-properties',
'@babel/plugin-transform-runtime'
]
};
```
## Разбор presets: базовая семантика трансформаций
### @babel/preset-env
Основной слой трансформации современного JavaScript в совместимый с целевыми окружениями код.
Ключевые параметры:
* **targets** — определяет список поддерживаемых окружений
* **useBuiltIns** — стратегия подключения полифиллов
* **corejs** — версия библиотеки полифиллов
Анализ данного пресета позволяет выявить:
* необходимость транспиляции синтаксиса ES202x
* уровень поддержки браузеров/Node.js
* наличие автоматической подстановки полифиллов
При миграции на SWC критично выделить:
* список целевых платформ
* требования к полифиллам (SWC не управляет ими так же гибко, как Babel)
## Анализ plugins: семантические трансформации AST
Плагины Babel изменяют AST на уровне конкретных языковых возможностей.
### Часто встречающиеся плагины
#### class properties
```js
'@babel/plugin-proposal-class-properties'
```
Отвечает за преобразование:
```js
class A {
value = 1;
}
```
в совместимую форму через конструктор.
В SWC эквивалент:
```json
{
"jsc": {
"transform": {
"legacyDecorator": false,
"decoratorMetadata": false
}
}
}
```
или:
```json
{
"jsc": {
"parser": {
"syntax": "ecmascript",
"decorators": true
},
"transform": {
"class": {
"properties": true
}
}
}
}
```
#### transform-runtime
```js
'@babel/plugin-transform-runtime'
```
Задаёт централизованное использование вспомогательных функций Babel и предотвращает дублирование хелперов.
При анализе важно фиксировать:
* использование regenerator-runtime
* импорт вспомогательных функций
* режим генерации helpers
В SWC аналогичное поведение задаётся через:
```json
{
"jsc": {
"externalHelpers": true
}
}
```
## Анализ режима модулей
Babel часто использует:
```js
modules: 'commonjs'
```
или:
```js
modules: false
```
Значение:
* `commonjs` — преобразование import/export в require/module.exports
* `false` — сохранение ESM
Для SWC критично выделить:
```json
{
"module": {
"type": "commonjs"
}
}
```
или
```json
{
"module": {
"type": "es6"
}
}
```
Ошибка при миграции часто возникает из-за несовпадения стратегий модульности между инструментами сборки.
## Анализ targets и среды выполнения
Babel определяет целевые среды через:
```js
targets: {
node: '16',
browsers: ['last 2 versions']
}
```
Это влияет на:
* необходимость трансформации optional chaining
* генерацию async/await
* включение полифиллов
При переходе на SWC эта информация переносится в:
```json
{
"env": {
"targets": {
"node": "16"
}
}
}
```
или через интеграцию с bundler (например, Next.js / Webpack).
## Разбор полифиллов
Babel управляет полифиллами через:
* `useBuiltIns: "usage"`
* `useBuiltIns: "entry"`
* `corejs`
Пример анализа:
```js
useBuiltIns: 'usage',
corejs: 3
```
Это означает:
* автоматическая вставка импортов `core-js`
* анализ используемых API на уровне AST
* точечная подстановка полифиллов
SWC не реализует полноценную стратегию `usage` самостоятельно, поэтому при миграции фиксируются:
* список используемых полифиллов
* внешнее управление через bundler (Vite, Webpack, Next.js)
## Анализ порядка трансформаций
Babel применяет плагины строго последовательно, что влияет на результат AST.
Типичные конфликты:
* class properties + decorators
* optional chaining + custom plugins
* transform-runtime + preset-env
При анализе конфигурации важно фиксировать:
* порядок `plugins`
* наличие `overrides`
* использование `env` блоков
Пример:
```js
env: {
production: {
plugins: ['transform-remove-console']
}
}
```
В SWC аналог достигается через:
```json
{
"env": {
"mode": "production"
}
}
```
в связке с инструментом сборки.
## Выявление избыточных трансформаций
Babel-конфигурации часто содержат устаревшие плагины:
* `@babel/plugin-transform-strict-mode`
* `@babel/plugin-transform-template-literals`
* `@babel/plugin-transform-arrow-functions`
Их наличие сигнализирует о:
* устаревшей цепочке сборки
* избыточной нагрузке на компиляцию
* возможности полной замены SWC
SWC выполняет эти трансформации на уровне ядра, без необходимости подключения отдельных модулей.
## Анализ TypeScript-слоя
При наличии:
```js
@babel/preset-typescript
```
фиксируются:
* удаление типов на этапе транспиляции
* отсутствие type-checking
* взаимодействие с Babel parser
SWC заменяет это через встроенный TypeScript-парсер:
```json
{
"jsc": {
"parser": {
"syntax": "typescript"
}
}
}
```
Критично учитывать:
* SWC не выполняет полноценную проверку типов
* требуется внешний `tsc --noEmit`
## Анализ JSX-трансформации
Babel:
```js
@babel/preset-react
```
Параметры:
* runtime: classic / automatic
* development mode
* import source
SWC:
```json
{
"jsc": {
"transform": {
"react": {
"runtime": "automatic"
}
}
}
}
```
При анализе фиксируется:
* необходимость импорта React
* использование нового JSX runtime
* наличие custom pragma
## Формирование карты миграции на SWC
Результатом анализа Babel-конфигурации становится структурированная карта:
* пресеты → `jsc.parser` + `jsc.transform`
* плагины → встроенные трансформации SWC или исключения
* modules → `module.type`
* targets → `env.targets`
* runtime helpers → `externalHelpers`
Типовая схема сопоставления:
| Babel | SWC |
| -------------------------------- | --------------------- |
| preset-env | jsc.env + bundler |
| preset-react | jsc.transform.react |
| preset-typescript | jsc.parser.typescript |
| plugin-proposal-class-properties | jsc.transform.class |
| transform-runtime | externalHelpers |
## Выявление несовместимостей
На этапе анализа фиксируются ограничения:
* отсутствие эквивалента для кастомных Babel-плагинов
* различия в обработке декораторов
* поведение polyfill strategy
* различия AST-уровня трансформаций
Особое внимание уделяется:
* legacy decorators vs stage 3 decorators
* experimental syntax
* нестандартные Babel plugins
## Итоговая структура конфигурационного профиля
После анализа формируется профиль:
* синтаксические возможности проекта
* набор трансформаций AST
* требования к целевым средам
* стратегия модулей
* система полифиллов
* React/JSX режим
* TypeScript режим
Этот профиль становится основой для пересборки конфигурации в формате SWC без потери поведения исходного Babel pipeline.