Claude Code for Moon Build System — Guide

Written by Michael Lip · Solo founder of Zovo · $400K+ on Upwork · 100% JSS Join 50+ builders · More at zovo.one

The Setup

You are managing a monorepo with Moon, a build system and repository management tool written in Rust. Moon provides project dependency graphs, intelligent task running, caching, and CI integration with a focus on developer experience. Unlike Turborepo or Nx, Moon uses YAML configuration and has built-in toolchain management. Claude Code can configure monorepo tools, but it generates Turborepo or Nx configuration instead of Moon’s YAML-based approach.

What Claude Code Gets Wrong By Default

  1. Creates turbo.json for task pipelines. Claude writes Turborepo’s turbo.json with pipeline configuration. Moon uses .moon/tasks.yml and per-project moon.yml files — the configuration format and semantics differ entirely.

  2. Installs Node.js toolchain manually. Claude adds nvm use or installs Node globally. Moon has a built-in toolchain manager in .moon/toolchain.yml that automatically installs and manages Node.js, npm/yarn/pnpm, and other tools.

  3. Defines tasks in package.json scripts. Claude puts all commands in package.json scripts. Moon defines tasks in moon.yml per project with inputs, outputs, dependencies, and caching configuration — package.json scripts are optional.

  4. Ignores the workspace configuration. Claude creates a flat monorepo without workspace config. Moon needs .moon/workspace.yml to define project locations, VCS integration, and workspace-level settings.

The CLAUDE.md Configuration

# Moon Monorepo

## Build System
- Tool: Moon (Rust-based build system)
- Config: .moon/ directory for workspace config
- Projects: moon.yml per project
- Tasks: defined in moon.yml with deps, inputs, outputs

## Moon Rules
- Workspace: .moon/workspace.yml for project globs
- Toolchain: .moon/toolchain.yml for Node/tool versions
- Tasks: .moon/tasks.yml for inherited tasks
- Project: moon.yml in each project directory
- Run: moon run project:task
- CI: moon ci for affected task detection
- Cache: automatic with inputs/outputs hashing

## Conventions
- .moon/ at repo root for global config
- moon.yml in each project for project-specific config
- Tasks: command, inputs, outputs, deps for caching
- Use moon ci in CI pipelines for affected-only builds
- Toolchain manages Node.js version — no nvm needed
- Project dependencies in moon.yml dependsOn
- Tags for project categorization and filtering

Workflow Example

You want to set up a Moon monorepo with a Next.js app and a shared library. Prompt Claude Code:

“Configure a Moon monorepo with an apps/web Next.js project and a packages/shared TypeScript library. Set up the toolchain for Node.js 20 with pnpm, define build and test tasks with proper caching, and configure the dependency between web and shared.”

Claude Code should create .moon/workspace.yml with project globs, .moon/toolchain.yml with Node 20 and pnpm, apps/web/moon.yml with build/test tasks and dependsOn: ['shared'], packages/shared/moon.yml with build/test tasks, and .moon/tasks.yml for inherited task defaults.

Common Pitfalls

  1. Missing inputs/outputs for caching. Claude defines tasks without inputs and outputs. Moon’s caching depends on these declarations — without them, tasks either never cache or always cache incorrectly. Specify source files as inputs and build artifacts as outputs.

  2. Not using moon ci in CI pipelines. Claude runs all tasks with moon run :build in CI. Moon’s moon ci command automatically detects affected projects based on Git changes — running all tasks wastes CI time.

  3. Circular project dependencies. Claude creates mutual dependencies between projects. Moon validates the project dependency graph and rejects cycles. Organize shared code into a separate package that both projects depend on.