Bun 1.2: Полное управление монорепозиторием через workspaces:* вместо Turborepo (2026)

Bun 1.2 позволяет выстроить монорепозиторий с меньшим числом промежуточных слоёв. Этот план описывает, как команда может перейти с Turborepo на workspaces:* постепенно, сохраняя стабильность релизов.

Зачем делать этот переход

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

Шаг 1. Диагностика

1. 1Соберите карту пакетов: приложения, библиотеки, инструменты.
2. 2Проверьте зависимости между пакетами и точки API.
3. 3Замерьте текущие метрики: время build, время тестов, размер кеша, частоту падений CI.
4. 4Определите окна развертывания и критерии отката.

Шаг 2. Архитектура workspaces:*

• pps/* для приложений
• packages/* для общих модулей
• ools/* для внутренних утилит
• configs/* для централизованных правил

json { "workspaces": ["apps/", "packages/"] }

Шаг 3. Поэтапный запуск

Сначала дублируйте ключевые пайплайны: Bun install / Bun lint / Bun test / Bun build. Затем вводите новый поток параллельно со старым до доказательства метрик.

Шаг 4. Надежный релиз

• Включите Feature Flagы для новых задач.
• Стандартизируйте версионирование lockfile и инструментов.
• Добавьте контрактные тесты между пакетами.
• Планируйте rollback на уровне пакета в первые 24 часа.

5. Практические метрики

• TTP (time to production)
• доля успешных пайплайнов
• среднее время восстановления после падения
• стабильность локальной разработки и CI

Turborepo migration checklist Bun workspaces:* reference Release-safe CI pattern Monorepo observability stack

Ошибки и решения

Частая ошибка — смешивание версий общих библиотек. Введите единый контракт публикации и проверку зависимостей. Вторая ошибка — слишком быстрая замена всего за один этап; используйте этапы.

FAQ

Q1. Нужно ли полностью удалять Turborepo в один день?

A1. Нет. Лучше поэтапный с контролируемым сравнением метрик.

Q2. Как понять, что миграция безопасна?

A2. Если ключевые метрики CI и релизов остаются в целевых пределах.

Q3. Сколько пакетов переносить за цикл?

A3. 2-4 пакета, затем расширение диапазона после стабилизации.

Q4. Что делать с уникальными нативными зависимостями?

A4. Оставить адаптерный слой на время и убрать после прохождения smoke tests.

Q5. Как ускорить onboarding команды?

A5. Подготовить playbook, шаблоны команд и примеры типовых ошибок.

Q6. Какое минимальное условие для cutover?

A6. 95% рабочих пайплайнов на новом потоке и проверенный rollback.

Q7. Почему этот путь выгоден?

A7. Меньше инструментарий, более простая отладка и прогнозируемые релизы.