<b>Bun не ускоряет плохой проект: 5 проверок перед миграцией</b>

<b>Bun не ускоряет плохой проект: 5 проверок перед миграцией</b>

Bun часто берут ради скорости запуска и удобного DX, но миграция ломается не на «тулинге», а на несовпадении ожиданий.

• Проверь, чем собираешь проект: если у тебя сложный ESM/CJS микс, нестандартные алиасы и кастомный loader, сначала прогоняй отдельно входы, а не весь репозиторий.
• Сравни поведение тестов и скриптов: часть команд в package.json может опираться на bash-семантику, а не на чистый Node-рантайм.
• Посмотри на зависимости с native-модулями и postinstall-логикой. Если пакет ожидает привычный npm/pnpm lifecycle, это всплывёт сразу.
• Не тащи в Bun сразу весь monorepo. Начни с одного сервиса или утилиты, чтобы понять, где ломаются path aliases, env-переменные и file watchers.
• Отдельно проверь lockfile и install-поведение: повторяемая установка важнее, чем «быстро поставилось один раз».

Есть наблюдение которое стоит проверить: Bun хорошо заходит там, где проект уже дисциплинирован по ESM, скриптам и структуре пакетов.

Если у тебя в репе хаос, Bun его не исправит. Если порядок уже есть — он может дать более приятный цикл разработки и меньше трения на старте.