Журнал
Bun + Nuxt 4

Bun и Nuxt 4 в продакшене

Bun ускоряет установку пакетов, умеет запускать TypeScript без лишних шагов и хорошо подходит для локальной сборки Nuxt-проектов. Но в продакшене важнее не обещанная скорость, а предсказуемость.

Где Bun уже полезен

  1. Установка зависимостей — обычно заметно быстрее npm и yarn.
  2. Скрипты проекта — bun run хорошо работает для typecheck, build и generate.
  3. Единый инструмент — пакетный менеджер, рантайм и запускатор команд в одном бинарнике.
  4. CI и деплой — меньше накладных расходов, если вся команда использует один набор команд.

Где нужна осторожность

Nuxt 4 поддерживает Bun, но поддержка не равна полной совместимости со всеми модулями. Особенно внимательно проверяем:

  • серверные зависимости с нативными бинарниками;
  • SQLite и пакеты вокруг Nuxt Content;
  • WebSocket/HMR в dev-режиме;
  • интеграции, которые ожидают Node.js API.

Если проект зависит от спорной нативной библиотеки, сначала собираем минимальный прототип и прогоняем production build.

Базовая схема для Nuxt

bun install
bun run typecheck
bun run build

Для разработки чаще достаточно обычного режима:

bun run dev

Флаг --bun стоит включать только осознанно, когда вы действительно хотите запускать Nuxt CLI через Bun runtime:

bun --bun run dev

Продакшен-рантайм

Если приложение использует Bun-специфичные API, например bun:sqlite, нужно явно собирать Nitro под Bun:

export default defineNuxtConfig({
  nitro: {
    preset: "bun",
  },
})

Если Bun нужен только как пакетный менеджер и runner для сборки, node-server остаётся более универсальным вариантом для хостингов, где окружение заранее настроено под Node.js.

Практическое правило

Мы используем Bun там, где он снижает трение: установка, локальные команды, CI-сборка. Для серверного рантайма выбираем Bun только после проверки конкретных модулей, логов и деплой-платформы.

Такой подход даёт скорость без лишнего риска: проект быстрее собирается, но не становится зависимым от экспериментального поведения в критичном месте.