Bun v1.4.3: встроенная проверка типов bun check и ускорение TypeScript

Каждый, кто работал с крупными проектами на TypeScript, знает это мучительное ожидание: запускаешь проверку типов перед коммитом или в CI-пайплайне, и процессор на несколько минут уходит в глухую задумчивость, раскручивая кулеры ноутбука. Рантайм Bun долгое время решал только половину проблемы: он молниеносно скомпилировал и запускал TypeScript-файлы, но делал это «вслепую» — просто вырезая синтаксис типов (type stripping) без какой-либо их верификации. Чтобы убедиться, что в коде нет логических ошибок и нестыковок интерфейсов, разработчикам все равно приходилось параллельно держать медленный официальный компилятор tsc от Microsoft.

Релиз Bun v1.4.3 кардинально меняет расстановку сил. В рантайм добавили команду bun check — полноценный независимый статический анализатор типов, встроенный прямо в исполняемый файл. Новинка работает в разы быстрее оригинального компилятора и не требует установки тяжеловесного пакета typescript в проектные зависимости.

Почему классический компилятор заставлял систему страдать

Чтобы понять масштаб прорыва, стоит взглянуть на то, как устроена классическая проверка типов. Если удаление типов можно сравнить с быстрым снятием строительных лесов со здания, то проверка типов — это детальная инженерная инспекция каждого узла, балки и болта на соответствие чертежам. Компилятор tsc написан на самом JavaScript и выполняется внутри виртуальной машины Node.js. Из-за природы рантайма он преимущественно работает в один поток и тратит колоссальное количество оперативной памяти на хранение деревьев синтаксического анализа (AST).

Создатели Bun пошли радикальным путем: они интегрировали в бинарник наработки проекта typescript-go — инициативы по переписыванию компилятора TypeScript на системные языки. Анализатор в Bun написан на нативном языке Zig. Он умеет эффективно распараллеливать синтаксический разбор файлов и сопоставление типов по всем доступным физическим ядрам процессора, не неся накладных расходов сборщика мусора JavaScript.

При этом разработчики не пошли на компромиссы в точности: bun check проходит 100% официального набора тестов спецификации TypeScript 7.0.2 (conformance test suite), гарантируя идентичное поведение при разборе сложных дженериков, условных типов и перегрузок функций.

Секунды вместо минут: реальные бенчмарки

Прирост скорости впечатляет даже скептиков. На гигантской кодовой базе исходного кода VS Code, насчитывающей почти 10 тысяч файлов TypeScript (9 795 исходников), нативный чекер справляется за 1,24 секунды против 5,98 секунды у tsc — это чистое ускорение в 4,8 раза. При этом потребление оперативной памяти упало почти в четыре раза: 2,14 ГБ у Bun против непомерных 7,97 ГБ у tsc.

На других популярных библиотеках отрыв оказался еще более заметным:

Репозиторий Next.js (packages/next, 2 881 файл): 0,28 секунды у Bun против 1,82 секунды у tsc (ускорение в 6,4 раза);
ORM-фреймворк mikro-orm (2 883 файла): 1,20 секунды против 5,97 секунды (ускорение в 5 раз);
Фреймворк Nuxt (839 файлов): 0,27 секунды против 0,80 секунды (ускорение в 3 раза).

Для разработчика это означает исчезновение микропауз в цикле обратной связи: проверка всего репозитория превращается в моментальное действие.

Как запустить проверку и настроить пайплайн

Интеграция новой утилиты в рабочий процесс не требует переписывания проекта. Команда bun check автоматически находит и считывает стандартный конфигурационный файл tsconfig.json, анализирует пути include и применяет строгие правила типизации.

# Автономная валидация всех типов проекта по tsconfig.json
bun check

# Запуск скрипта с принудительной проверкой типов перед выполнением
bun run --check src/index.ts

Если в проекте используется стандартная строгая конфигурация, bun check подхватывает ее без дополнительных флагов.

{
  "compilerOptions": {
    "target": "ESNext",
    "module": "ESNext",
    "moduleResolution": "bundler",
    "strict": true,
    "skipLibCheck": true,
    "noEmit": true
  },
  "include": ["src/**/*"]
}

Флаг --check также добавили в команды bun run, bun test и bun build. Если в коде обнаруживается ошибка типизации, процесс мгновенно завершается с кодом ошибки 1 и подробной диагностикой, предотвращая запуск некорректного приложения.

type UserProfile = {
  id: number;
  displayName: string;
};

export function renderBadge(user: UserProfile): string {
  return `Пользователь: ${user.displayName} (ID: ${user.id})`;
}

// Ошибка: id передан в виде строки вместо числа
const result = renderBadge({ id: "1042", displayName: "Алексей" });
// bun check: error: TS2322: Type 'string' is not assignable to type 'number'.

Диагностические сообщения выводят привычные коды ошибок семейства TSxxxx, поэтому вывод легко парсится существующими плагинами для CI и аннотациями в GitHub Actions.

Ограничения и вердикт для продакшна

Несмотря на впечатляющую скорость, bun check пока не является стопроцентной заменой компилятора от Microsoft во всех возможных сценариях. Важно понимать функциональное разграничение:

bun check занимается исключительно проверкой типов и валидацией кода.
Он не генерирует файлы деклараций .d.ts (type definitions) и карты кода (source maps).
Инструмент не заменяет языковой сервер LSP в редакторах: VS Code и Cursor по-прежнему используют фоновый процесс tsserver для автодополнения и подсветки в реальном времени.

Если вы разрабатываете открытую библиотеку для реестра npm и вам необходимо упаковывать готовые .d.ts-файлы для внешних потребителей, вам все еще понадобится вызов tsc --emitDeclarationOnly. Однако для продуктовых бэкендов, монорепозиториев и CI-пайплайнов bun check уже сейчас предлагает идеальный компромисс: существенную экономию серверных мощностей в облаке и мгновенный отклик при локальной разработке.