Stage 3 и stage 4: поддержка в SWC
## Понимание стадий TC39 в контексте SWC
В процессе стандартизации ECMAScript предложения проходят через формальный цикл TC39, который определяет зрелость синтаксических и семантических изменений языка JavaScript.
**Stage 3 (Candidate)** — предложение практически завершено, спецификация близка к финальной версии, но возможны незначительные изменения.
**Stage 4 (Finished)** — предложение официально включено в стандарт ECMAScript и считается стабильным.
Для инструментов трансляции, таких как SWC, различие между этими стадиями определяет уровень поддержки: от экспериментальных преобразований до полностью стабильного поведения без флагов.
---
## Архитектурная модель SWC и место stage-предложений
SWC построен вокруг конвейера компиляции:
* **Парсинг (Parser)** — преобразование исходного кода в AST
* **Трансформации (Transform)** — модификации AST, включая поддержку новых синтаксических конструкций
* **Генерация кода (Codegen)** — вывод JavaScript в целевую версию
Поддержка Stage 3 и Stage 4 интегрируется преимущественно на уровне парсера и трансформаций, поскольку именно здесь определяется, как новый синтаксис интерпретируется и во что он компилируется.
---
## Stage 4 в SWC: стабильные возможности ECMAScript
Stage 4-стандарты уже являются частью языка JavaScript, поэтому в SWC они:
* включены по умолчанию;
* не требуют экспериментальных флагов;
* не изменяют семантику при обновлениях компилятора (за исключением багфиксов).
### Типичные Stage 4 возможности в SWC
#### Optional Chaining
```js
const value = obj?.user?.profile?.name;
```
В SWC этот синтаксис обрабатывается как базовая часть AST и транслируется в совместимый ES5/ES2015 код при необходимости.
#### Nullish Coalescing
```js
const port = config.port ?? 3000;
```
Трансформация выполняется без дополнительных плагинов, так как конструкция закреплена в стандарте.
#### BigInt
```js
const n = 9007199254740991n;
```
Поддержка зависит от целевой среды, но парсинг и генерация AST реализованы как стабильная часть ядра.
---
## Stage 3 в SWC: экспериментальные возможности
Stage 3 включает предложения, которые почти готовы к стандартизации, но ещё могут изменяться. В SWC они реализуются через опциональные трансформации и конфигурацию компилятора.
Поддержка Stage 3 в SWC обычно активируется через:
* `jsc.parser`
* `jsc.transform`
* экспериментальные плагины
* feature flags в конфигурации `.swcrc`
---
## Модель включения Stage 3 в SWC
SWC не рассматривает Stage 3 как единый набор функций. Вместо этого каждая фича включается отдельно.
### Пример конфигурационного подхода
* включение экспериментальных синтаксисов в parser
* подключение transform-плагинов
* указание целевых окружений (target)
Это позволяет контролировать стабильность сборки, избегая попадания нестабильного синтаксиса в production-код.
---
## Decorators: классический пример Stage 3 в SWC
Decorators долго находились на Stage 3 и стали одной из наиболее сложных зон поддержки.
### Особенности реализации в SWC
* поддержка legacy decorators (TypeScript-совместимые)
* поддержка новой спецификации decorators (proposal)
* различие в семантике применения к классам и методам
```js
function readonly(target, key, descriptor) {
descriptor.writable = false;
return descriptor;
}
class Example {
@readonly
method() {}
}
```
SWC должен учитывать тип decorators при трансформации AST, поскольку разные версии proposal несовместимы.
---
## Class Fields и Private Fields
Хотя часть функционала уже достигла Stage 4, эволюция происходила через Stage 3.
### Public class fields
```js
class User {
name = "default";
}
```
### Private fields
```js
class User {
#id = 1;
getId() {
return this.#id;
}
}
```
SWC реализует преобразование с учётом инкапсуляции, сохраняя семантику доступа через private brand checks.
---
## Pipeline Operator и другие Stage 2–3 предложения
Некоторые Stage 3 предложения в SWC доступны как экспериментальные трансформации:
### Pipeline operator
```js
value
|> double
|> square;
```
Такие конструкции требуют трансформации в цепочки вызовов функций. SWC реализует это через AST-rewrite правила, но поведение может зависеть от выбранного proposal-режима.
---
## Конфигурация поддержки Stage 3/4 в SWC
В SWC ключевую роль играет файл конфигурации `.swcrc`.
### Основные параметры
* `jsc.parser` — включает синтаксис Stage 3
* `jsc.transform` — активирует преобразования
* `env` — определяет целевую среду (ES5, ES2015+)
* `minify` — влияет на финальную форму кода, но не на stage-поддержку
### Логика включения
* Stage 4: активен всегда
* Stage 3: активен при явном включении
* нестабильные proposals: требуют дополнительной настройки или плагинов
---
## Совместимость и риски Stage 3
Stage 3 в SWC связан с несколькими архитектурными рисками:
* изменение спецификации TC39 может привести к несовместимости AST
* трансформации могут устареть быстрее релизного цикла SWC
* разные реализации proposals могут конфликтовать между собой
Поэтому SWC разделяет:
* **syntax support** (парсинг)
* **transform support** (трансформация)
* **runtime expectations** (поведение в браузере/Node.js)
---
## Влияние Stage 4 на стабильность компилятора
Stage 4 снижает сложность трансляции, поскольку:
* отсутствует необходимость в альтернативных режимах трансформации
* AST стабилизируется
* уменьшается количество edge cases
В SWC Stage 4-функции становятся частью базового набора возможностей и редко изменяются между версиями компилятора.
---
## Разделение ответственности между SWC и рантаймом
Stage 3 и Stage 4 влияют не только на компилятор, но и на конечную среду выполнения:
* SWC обеспечивает синтаксическую совместимость
* трансформации обеспечивают обратную совместимость
* рантайм (браузер/Node.js) определяет фактическое поведение
Особенно критично это для Stage 3, где спецификация может измениться до финального Stage 4.
---
## Практическая модель эволюции features
Типичный путь предложения:
1. Stage 3 → экспериментальная поддержка в SWC
2. стабилизация → обновление transform-логики
3. Stage 4 → переход в core-поддержку без флагов
4. депрецированние старых трансформаций
Эта модель позволяет SWC оставаться совместимым с быстро развивающимся ECMAScript, не теряя производительности компиляции.