В системе трансформации JavaScript/TypeScript кода в SWC параметр
assumptions используется для задания набора логических
предположений о поведении исходной среды выполнения. Эти предположения
позволяют компилятору выполнять более агрессивные оптимизации, уменьшая
объём генерируемого кода и повышая его производительность.
SWC работает как статический преобразователь AST, и многие
преобразования в нём зависят от того, насколько строго он должен
сохранять семантику JavaScript. Без дополнительных предположений
трансформации вынуждены учитывать максимально широкий спектр крайних
случаев. При включённых assumptions часть этих проверок
исключается, если заранее известно, что среда ведёт себя более
предсказуемо.
Оптимизации на основе assumptions строятся вокруг идеи
ослабления гарантий JavaScript-спецификации в обмен на
производительность. В стандартном режиме SWC обязан сохранять поведение
даже в редких и исторически специфичных сценариях (например,
document.all, динамические геттеры, нестандартные
итераторы).
При включении предположений компилятор получает возможность:
В SWC assumptions задаются внутри секции jsc:
module.exports = {
jsc: {
assumptions: {
// набор логических флагов
}
}
};
Каждый флаг описывает отдельное поведение JavaScript, которое считается истинным в целевой среде выполнения.
pureGetters
pureGetters предполагает, что обращения к геттерам объектов
не имеют побочных эффектов.
При включённом предположении SWC может:
Без этого предположения каждое обращение к getter должно рассматриваться как потенциально изменяющее состояние программы.
setPublicClassFields
setPublicClassFields управляет тем, как интерпретируются
публичные поля классов.
При активном предположении:
constructor и
прототипов минимизируется
Пример влияния:
class A {
x = 1;
}
Без оптимизации поле может быть перенесено в конструктор с дополнительной логикой проверки. С предположением — становится прямым присваиванием.
setSpreadProperties
setSpreadProperties позволяет компилятору предполагать
упрощённое поведение оператора spread при работе с объектами.
В обычном режиме SWC обязан учитывать:
При включённом предположении:
noDocumentAll
noDocumentAll предполагает отсутствие поведения
document.all в целевой среде.
document.all является историческим артефактом браузеров и
ведёт себя нестандартно:
object
null возвращает true
При включении предположения SWC может:
arrayLikeIsIterable
arrayLikeIsIterable предполагает, что все array-like
структуры в среде поддерживают стандартный итератор.
Это позволяет SWC:
for..of для array-like объектов
arguments и NodeList-подобных
структур
При отсутствии предположения компилятор обязан генерировать более
сложный код с проверками наличия Symbol.iterator.
ignoreFunctionLength
ignoreFunctionLength влияет на поведение свойства
Function.length.
В JavaScript это свойство отражает количество параметров функции, но может быть изменено трансформациями (например, добавлением параметров при транспиляции async/await или rest-аргументов).
При включении предположения:
.length
Это особенно важно при агрессивных преобразованиях ESNext → ES5.
В ряде конфигураций SWC учитывает предположения о работе rest-операторов с объектами, включая исключение символов.
Хотя точное имя флага может различаться, логика сводится к следующему:
Symbol-ключей при
деструктуризации
Каждое активированное предположение уменьшает необходимость в защитных конструкциях. Это проявляется в нескольких уровнях трансформации:
На практике это приводит к:
assumptions всегда связаны с риском нарушения
совместимости. Чем больше предположений включено, тем сильнее отклонение
от спецификации ECMAScript в сторону конкретной среды.
Типичные последствия:
По этой причине предположения обычно используются только при строгом контроле целевой среды (например, modern evergreen browsers или Node.js определённой версии).
assumptions не работают изолированно и взаимодействуют с
другими уровнями конфигурации:
loose-режим усиливает эффект предположений
target определяет допустимый уровень агрессивности
оптимизаций
minify может дополнительно упрощать уже преобразованный код
Комбинация assumptions + loose + modern target приводит к
наиболее компактному результату, но снижает универсальность выходного
кода.
Использование предположений изменяет баланс между корректностью и производительностью. Основные риски:
В реальных сборках assumptions обычно включаются выборочно,
ориентируясь на профиль приложения. В высоконагруженных
frontend-приложениях допустим более агрессивный набор флагов, тогда как
библиотечный код требует минимальных предположений для сохранения
универсальности.
Типичная стратегия — разделение конфигураций: