Moonrepo releases Moon v2.0 – a plugin‑first monorepo engine

Moonrepo, the open‑source monorepo manager written in Rust, announced the general availability of Moon v2.0 (code‑named Phobos). After a three‑stage pre‑release cycle, the new version ships with a WebAssembly (WASM) plugin architecture, support for five additional configuration syntaxes, and a re‑engineered CLI that unifies execution paths. For organisations that already rely on Moon for reproducible toolchains, the upgrade represents both an opportunity to extend language coverage and a set of migration tasks that must be planned.

---

What changed?

Area	v1.x	v2.0
Toolchain model	Built‑in, hard‑coded per‑platform binaries	WASM plugins loaded at runtime, community‑maintained extensions
Config formats	YAML only	YAML, JSON, JSONC, HCL, Pkl, TOML
CLI	Separate commands (moon ci, moon run, …) with duplicated logic	Single moon exec core, thin wrappers (moon ci, moon check, moon run)
Task inheritance	File‑name conventions (*.inherit)	inheritedBy field in configuration, filterable by toolchain, stack, tags
Docker support	Global Dockerfile, limited overrides	Per‑project Docker settings, Tera‑based Dockerfile templates
VCS layer	Simple Git wrapper, writes to .git/hooks	Full Git implementation, worktree/submodule awareness, hook abstraction
Installation	Single binary distribution, upgrade command	Separate installer scripts, moon migrate v2 helper, no in‑place upgrade

The most visible shift is the WASM plugin system. Instead of compiling language support directly into Moon, developers can now drop a .wasm file that implements the Toolchain interface. The plugin can:

• Extend the project graph with custom node types.
• Replace the command line used to run a task.
• Hook into Docker image preparation steps.
• Declare external tool versions that proto (Moon’s companion version manager) will fetch automatically.

Because the runtime is sandboxed, the core binary stays small (≈ 7 MB) and security boundaries are clearer. Community contributors have already published plugins for Rust (cargo), Go (go‑toolchain), Python (pipenv) and Java (Maven/Gradle), demonstrating the model’s flexibility.

---

Provider comparison – Moon vs. Turborepo, Nx and Bazel

Feature	Moon v2.0	Turborepo (v2)	Nx (v18)	Bazel (6.x)
Primary language	Rust (binary)	JavaScript/TypeScript (Node)	TypeScript (Node)	Starlark (Python‑like)
Plugin extensibility	WASM plugins, any language	Limited to JS/TS scripts	Plugins via @nrwl/* packages, TS only	Skylark rules, requires repo‑wide rewrite
Configuration formats	YAML, JSON, JSONC, HCL, Pkl, TOML	JSON/YAML (Turbo.json)	JSON/YAML (workspace.json)	Starlark BUILD files
Task inheritance	Config‑driven inheritedBy	Implicit via dependsOn arrays	Implicit via target inheritance	Explicit via rule dependencies
Docker integration	Per‑project overrides, Tera templates	External scripts only	External scripts only	Built‑in container rules, heavy setup
CI parallelism	Built‑in affected‑filter + parallel exec	Remote caching, parallel workers	Distributed task execution via Nx Cloud	Remote execution via Remote Build Execution
Community size (weekly downloads)	~50 K	~2 M	~5 M	~300 K (via Bazelisk)
Pricing	Open source, free	Free tier, paid Cloud for caching	Free tier, paid Cloud for distributed exec	Open source, enterprise support optional

Strategic takeaways

• Flexibility vs. ecosystem lock‑in – Moon’s WASM model removes the JavaScript‑only barrier that Turborepo and Nx have. Teams that need Rust, Go or Python toolchains can write a plugin without pulling a full Node runtime.
• Complexity overhead – Bazel still offers the most powerful caching and remote execution, but its learning curve and repository migration cost remain high. Moon sits between Bazel and make‑style tools, providing reproducible toolchains without a massive upfront investment.
• Cost considerations – All four projects are open source, but Turborepo and Nx charge for cloud‑based caching and distributed execution. Moon’s only cost is the developer time needed to maintain plugins and migration scripts.

---

Migration considerations for existing Moon users

1. Run the migration helper – moon migrate v2 scans the old moon.yml files, converts option names to kebab‑case, and generates a skeleton moon.toolchain.toml for each project. Review the generated files before committing.
2. Replace the upgrade command – The legacy moon upgrade no longer works because the binary format changed. Use the official installer script (curl -sSf https://moonrepo.dev/install.sh | sh) to install the new version.
3. Update environment handling – .env loading now occurs at task execution time. If you rely on values during graph construction (e.g., for conditional task inclusion), move those checks into the task command itself.
4. Re‑evaluate task inheritance – The old *.inherit files are ignored. Define an inheritedBy block in moon.yml or the new moon.toolchain.* files, specifying criteria such as toolchain: rust, tags: backend.
5. Test Docker overrides – Per‑project Docker settings are now stored under docker: in each project’s config. Verify that custom Dockerfile templates resolve correctly in CI pipelines.
6. Validate VCS hooks – The new Git implementation no longer writes directly to .git/hooks. If you have custom pre‑commit scripts, add them to the moon.hooks section.

A typical migration timeline for a medium‑size monorepo (≈ 150 projects) might look like this:

Week	Activity
1	Run moon migrate v2 on a feature branch, review generated configs
2	Implement missing WASM plugins for any language not covered by the official set
3	Adjust CI pipelines to use moon exec and enable affected filtering
4	Perform a full build in a staging environment, compare artifact hashes with v1 outputs
5	Cut over production, monitor task latency and Docker image builds

---

Business impact

• Reduced vendor lock‑in – By allowing any language to be expressed as a WASM plugin, Moon eliminates the need to adopt a separate build orchestrator when a new runtime appears. This flexibility can shorten time‑to‑market for micro‑services written in emerging languages.
• Predictable CI costs – Moon’s built‑in parallel execution and affected‑filtering reduce the number of containers spun up in CI. For a team that spends $3 K per month on CI minutes, a 15 % reduction translates into a $450 saving.
• Operational risk – The new Git implementation improves handling of worktrees and submodules, which are common in large enterprises that share internal libraries via separate repositories. Fewer manual hook edits also lower the chance of accidental breakage during onboarding.
• Talent acquisition – The shift to WASM aligns with the growing interest in Rust‑based tooling. Recruiters can now advertise “Rust‑first monorepo experience,” appealing to developers who prefer compiled languages over JavaScript‑centric ecosystems.
• Competitive positioning – While Turborepo and Nx dominate the JavaScript‑heavy segment, Moon’s polyglot focus gives it a niche in organisations that run mixed stacks (e.g., Node + Go + Python). Companies evaluating a move away from Bazel’s complexity may find Moon a cost‑effective alternative that still delivers reproducible toolchains.

---

Looking ahead

Moonrepo’s roadmap mentions a cloud‑hosted plugin registry and tighter integration with the proto version manager. If those services materialise, the barrier to adopting new language toolchains will shrink further, and the ecosystem could start to resemble a marketplace similar to npm but for build plugins. Enterprises should monitor the upcoming releases, especially the Moon v2.1 preview that promises incremental caching improvements.

---

Daniel Curtis is a UI Development Manager at Griffiths Waite and contributes to several open‑source front‑end projects. Follow his work on GitHub and read more about Moonrepo at the official documentation site.