Bun ускоряет старт проекта, но ломается там, где экосистему считают “как в Node”

За Bun чаще всего заходят ради трёх вещей: быстрый запуск, единый инструмент для package manager + runtime + тестов, и меньше glue-кода между шагами. Для прототипа и небольшого сервиса это реально экономит время. Но экономия исчезает, если проект завязан на нативные модули, нестандартные loaders или на поведение Node API без проверки.

Перед миграцией проверьте базовый набор:
— импорт CJS/ESM и алиасы;
— работу fs, path, fetch, streams;
— тесты и мокинг;
— сборку зависимостей с postinstall и native add-ons;
— скрипты, которые вызывают shell и env-переменные.

Самая частая ошибка — включить Bun как замену Node “везде и сразу”. Правильнее вынести его в один контур: dev-скрипты, тесты, локальный рантайм, отдельный сервис. Если код должен жить в монорепо, держите совместимость с Node через tsconfig, явные exports и минимум магии в резолве.

Если Bun даёт выигрыш только на старте, а в проде появляется список исключений — это не провал. Значит, его место найдено: там, где скорость важнее полного совпадения с Node.