Moonrepo выпустила релиз Moon v2.0 под кодовым именем Phobos 14 мая 2026 года. Для команд, которые живут в монорепозиториях и устали выбирать между тяжеловесным Bazel и набором скриптов на честном слове, это не косметическое обновление: в релиз Moon v2.0 вошли WASM-плагины для toolchain, переработанный CLI и более гибкая модель конфигурации.
Главная новость, как пишет InfoQ, в смене архитектуры. Если в первой мажорной ветке toolchain были зашиты в ядро moon, то теперь платформа перешла на WASM-плагинную схему. Проще говоря, раньше список поддерживаемых языков и рантаймов определяли мейнтейнеры проекта, теперь сообщество может писать собственные плагины почти под что угодно. Эти расширения умеют не только подключать новые инструменты, но и вмешиваться в граф проектов, менять команды задач, встраиваться в Docker-сценарии и управлять установкой версий через proto, companion-менеджер от moonrepo.
Для polyglot-команд это, пожалуй, самая практичная часть релиза. В типичном монорепозитории давно уже не только Node.js: рядом живут Rust-сервисы, Go-утилиты, инфраструктурные скрипты и куски фронтенда с отдельными требованиями к окружению. Пока toolchain зашит в ядро, любое расширение зависит от темпа самой платформы. Переход на WASM-плагины делает moon ближе к модели, где экосистема развивается не по расписанию одного вендора, а по потребностям пользователей. Для инструмента, который продает идею воспроизводимой сборки и единых правил для CI, это шаг не ради красивой архитектуры, а ради выживания в реальных репозиториях.
Вторая крупная перемена касается конфигов. Moon v2.0 теперь поддерживает не только YAML, но и JSON, JSONC, HCL, Pkl и TOML. На бумаге это выглядит как вежливый кивок всем лагерям сразу, но на практике выбор формата часто упирается не во вкус, а в уже сложившийся стек команды. Если инфраструктура описана в HCL, внутренние тулзы тяготеют к TOML, а часть конфигов и так живет в JSON, еще один «обязательный YAML» обычно воспринимается без восторга. В этом смысле релиз Moon v2.0 убирает лишний источник трения при внедрении инструмента в существующую среду.
CLI разработчики тоже пересобрали основательно. Внутри появился низкоуровневый `moon exec`, на котором теперь базируются `moon ci`, `moon check` и `moon run`. Это не просто переименование ради ровных названий: у команд появляется общий слой исполнения с поддержкой параллельного запуска задач и фильтрации по affected-изменениям. Иными словами, платформа пытается сделать то, чего команды обычно ждут от зрелого монорепо-инструмента: не гонять весь граф по каждому коммиту и не плодить зоопарк похожих, но чуть разных entry point. Отдельно стабилизировали бинарник `moonx`, а для случаев, когда пользователь не указал проект или задачу, добавили интерактивный выбор. Мелочь, но она хорошо показывает сдвиг в сторону повседневного DX, а не только CI-пайплайнов.
Сильная сторона moon всегда была в наследовании задач, и здесь модель тоже поменяли. Если раньше многое завязывалось на соглашения об именах файлов, то теперь наследование стало конфигурационным. Новый параметр `inheritedBy` позволяет явно задавать, какие проекты получают ту или иную задачу, по критериям вроде toolchain, стека, языка или тегов. Плюс одна и та же задача теперь может быть связана сразу с несколькими toolchain. Для больших репозиториев это важнее, чем звучит в релиз-нотах: чем меньше магии в именовании и чем больше явных правил, тем легче объяснить поведение системы новой команде и тем меньше сюрпризов при масштабировании. Обновили и работу с `.env`: `moon` автоматически подхватывает `.env.local` и окружение-специфичные файлы, причем делает это не на этапе построения графа, а при фактическом запуске. Это уменьшает риск, что граф будет учитывать то, что нужно только в момент исполнения.
Для Docker-сценариев релиз тоже оказался не проходным. В Moon v2.0 появились project-level override для Docker-настроек и поддержка кастомных шаблонов Dockerfile на базе Tera. Это полезно для команд, у которых единая платформа сборки сочетается с разными требованиями отдельных сервисов: кому-то нужен свой базовый образ, кому-то дополнительные шаги, кому-то и вовсе особая схема сборки для CI. Еще один технически важный, хотя и менее заметный пункт, это переписанный VCS-слой. Новый Git-бэкенд лучше работает с worktree и submodule, а система хуков больше не пишет напрямую в `.git/hooks`. Для команд с нетривиальной структурой репозитория это может оказаться не менее ценным, чем вся история с CLI: проблемы с worktree и сабмодулями обычно всплывают не в демо, а в самый неудобный момент.
Без ломающих изменений, конечно, не обошлось. Для миграции с v1 команда добавила отдельную команду `moon migrate v2`, а в гайде перечислила, что именно придется поправить: CLI-опции теперь приведены к kebab-case, конфигурация toolchain перестроена, синтаксис подстановки переменных окружения обновлен, а legacy-настройку local task убрали в пользу preset-системы. Важная деталь: команда `moon upgrade` из первой ветки больше не сработает из-за изменения формата дистрибуции, поэтому обновление требует переустановки через новые install-скрипты. Для инфраструктурных команд это мелкий, но показательный момент: мажорные версии devtools почти всегда обещают порядок после короткой фазы контролируемого хаоса.
На фоне рынка moon по-прежнему выглядит нишевым, но интересным игроком. PkgPulse недавно называл его «спящим фаворитом» для polyglot-репозиториев с Node.js, Rust и Go, одновременно напоминая о скромных масштабах сообщества: около 50 тысяч скачиваний в неделю против 2 миллионов у Turborepo и 5 миллионов у Nx. Создатель mise Джефф Дики на Hacker News сформулировал разницу еще проще: mise сначала решал проблему инструментов, а moon изначально брался за проблему сборки. Это скорее соседние слои, чем прямое лобовое столкновение. Для бизнеса и техлидов отсюда простой вывод: moon пока не выглядит стандартом де-факто, но после выхода второй мажорной версии становится заметно серьезнее как вариант для команд, которым нужна воспроизводимость toolchain внутри монорепо, а не просто быстрый раннер задач.
Теперь главный вопрос не в том, насколько красивой получилась архитектура Phobos, а в том, сумеет ли moonrepo превратить технически сильный релиз в рост экосистемы. Плагинная модель, поддержка разных форматов конфигов и более зрелая интеграция с Docker и Git дают инструменту шанс выйти из статуса «умного выбора для своих». Но в сегменте монорепо побеждает не тот, у кого релиз-ноты интереснее, а тот, у кого быстрее растет набор рабочих интеграций и меньше причин открывать миграционный гайд в пятницу вечером.