New debug-task AI agent skill​

We're shipping a new AI agent skill called debug-task that helps you systematically diagnose failing or misbehaving moon tasks. If you've ever spent time hunting down why a task is producing stale results, getting unexpected cache misses, or behaving differently in CI, this skill is for you.

To install this skill, run the following command:

$ npx skills add moonrepo/moon --skill debug-task

The skill walks you through a 5-step diagnostic workflow:

1. Inspect the resolved task configuration (after inheritance merging)
2. Run with maximum verbosity to see exactly what moon is doing
3. Inspect cache state and hash manifests
4. Match symptoms to root causes using a built-in decision tree
5. Validate that the fix actually resolves the issue

It covers 15+ specific problem types across cache issues, configuration mistakes, execution problems, and CI vs local discrepancies. Most issues resolve by step 3, with deeper reference material available on demand.

To use it, simply describe your task problem in Claude Code, Codex, OpenCode, or another compatible AI agent — mention the task target, what you expected, and what actually happened. The skill will take it from there.

/debug-task Help me debug why the `app:build` task is not being cached

Thanks to Yuzu02 for the amazing contribution!

Unstable daemon​

Continuing the theme of performance, this release introduces an unstable background daemon. The daemon is a long-lived server process that keeps the workspace graph hot in memory and watches for file system changes, rebuilding the graph asynchronously only when configuration files change. This means that after the first moon invocation, subsequent commands can skip graph building entirely and connect to the running daemon instead.

To try it out by enabling it in your workspace configuration:

unstable_daemon: true

Or test it with an environment variable first:

MOON_DAEMON=true moon run :build

When enabled, the daemon starts automatically on the first CLI command and stays running in the background. You can manage it with moon daemon start, stop, restart, status, and logs commands. If the daemon is unavailable for any reason, the CLI falls back to building graphs in-process — so there's no risk in enabling it.

Since this is unstable, behavior and configuration may change in future releases. Check out the daemon guide for full details on how it works, what files are watched, and troubleshooting tips.

Experimental async graph building​

Project and task building is a critical piece of moon. In previous versions, graph building was implemented synchronously, which could lead to performance issues in larger workspaces, but was unnoticeable in smaller workspaces. With this release, graph building is now available with an experimental async implementation, which must be enabled.

experiments:
  asyncGraphBuilding: true

To demonstrate the performance improvements, take the following benchmark results for example. For every benchmark, we had N projects with 4 tasks per project, iterated 100 times. The "average time" columns show the average time taken across all iterations, while the "total suite time" columns show the total time taken for all iterations. The "speedup" column shows the percentage improvement of the async builder compared to the sync builder.

As you can clearly see, as the number of projects and tasks increase, the performance improvement becomes more significant, with a speedup of 40-170%. Over time, and with the introducion of the daemon, this will only get better!

Caveats​

While the async graph builder is faster, there are some caveats to be aware of.

• Since this is experimental, it is not enabled by default. You must enable it in your workspace configuration to take advantage of the performance improvements.
• The async graph builder does not cache the built graph as this time, so it will be built from scratch every moon invocation. This is a temporary limitation that we plan to address in the future, as caching is a critical piece of the puzzle for performance. With that said, even without caching, the async builder is still significantly faster than the sync builder, especially for larger workspaces.
• The async graph builder does not support cycles, and will hard error if a cycle is detected. In the sync builder, we would attempt to cut edges between nodes when a cycle was detected, which could lead to incorrect results, but would not error.

Experimental async affected tracker​

The affected tracker is a core component of moon that determines which projects and tasks are affected by changes in the codebase. In previous versions, the tracker was implemented synchronously, which could lead to performance issues for larger projects with many tasks. With this release, the affected tracker is now available with an experimental async implementation. This new version is designed to be faster and more efficient (up to 150%), especially for large repositories with many tasks.

Since this is experimental, it is not enabled by default. To enable the async tracker, you can configure the following in .moon/workspace.yml.

experiments:
  asyncAffectedTracking: true

To demonstrate the performance improvements, take the following benchmark results for example. For every benchmark, we had N projects with 3 tasks per project, iterated 100 times. The "average time" columns show the average time taken across all iterations, while the "total suite time" columns show the total time taken for all iterations. The "speedup" column shows the percentage improvement of the async tracker compared to the sync tracker.

If you'll notice, the improvement for projects is negligible, which is expected as project tracking is very simple. However, for tasks, the async tracker shows significant improvements as the number of tasks increases, with a speedup of 50-150%. With that said, we believe that after 5,000 tasks, the increments diminish, as we're most likely hitting the upper limits of how much we can parallelize the work.

Other changes​

View the official release for a full list of changes.

• Temporarily brought back x86_64-apple-darwin (Apple Intel) as a supported operating system.
• Greatly reduced memory footprint of the action, project, and task graphs. Nodes in the graph are now integers instead of objects.
• Improved plugin registry performance and memory consumption when loading plugins.
• Improved performance of taskToolchains and taskType fields when querying the project graph.
• Improved performance of task output archiving, by no longer blocking the main thread pool.
• Updated the system toolchain to be built-in instead of an external WASM plugin that needs to be downloaded.

Execution plans​

The moon exec command is powerful, but complex invocations can mean long CLI commands that are hard to read and easy to get wrong. In v2.1, you can now define an execution plan — a JSON file that declaratively configures targets, affected filtering, graph traversal, and pipeline behavior — and pass it with a single flag:

{
  "pipeline": {
    "jobTotal": 3
  },
  "targets": {
    "jobs": [["app:build", "app:test"], ["lib:build", "lib:test"], ["docs:build"]]
  }
}

# Runs docs:build only!
$ moon exec --plan plan.json --job 2

This is especially useful for CI pipelines where you need partitioned jobs, affected-only runs, or specific failure handling. Instead of stitching together a dozen flags, drop a plan.json into your repo and version-control your execution strategy.

Check out the execution plan guide for the full structure and examples.

Target project dependencies by scope​

moon has always allowed you to reference dependencies of a project (external projects) within a task using ^ syntax, for both inputs and deps. However, it was quite restrictive in that it referenced all project dependencies, regardless of scope (production, development, etc).

We felt it was time to change this, and in v2.1 we're introducing a new syntax that allows you to target dependencies by scope. By default, the ^ syntax will still reference all dependencies, but you can now specify a scope by suffixing the ^ with one of the following:

• development / dev
• production / prod
• build
• peer

tasks:
  build:
    command: 'tsc'
    deps:
      # Depend on build tasks in production level project dependencies
      - '^production:build'
    inputs:
      # Source files of all production level project dependencies
      - 'project:^production'

New common toolchain settings​

Going forward, we want to provide more customization for toolchains, enabling you to curate the experience you want. The first step in this process is introducing 2 new settings that are common across all toolchains.

inheritAliases​

Aliases are a feature of projects that allow for alternate names to be used when referencing them. Aliases cannot be configured manually and instead are inferred from toolchains, typically by extracting the name field from a manifest file (package.json, Cargo.toml, pyproject.toml, etc).

This happens automatically, but what if you don't want to use aliases? Or there are conflicting aliases across projects? In v2.1, we're introducing a new common toolchain setting called inheritAliases that allows you to disable this feature. When set to false, no aliases will be inferred for any projects using that toolchain.

javascript:
  inheritAliases: false

We've also updated duplicate aliases to no longer be a hard error, and instead will apply to the first encountered project.

installDependencies​

When you run a task, all toolchains associated with the task will automatically install dependencies if they've determined that they need to (lockfile changes, dependency updates, etc). This is a great feature for ensuring that your environment is always up to date, especially when switching branches, but it can be a bit too much for some use cases.

In v2.1, we're introducing another common toolchain setting called installDependencies that allows you to disable this feature. When set to false, toolchains will not automatically install dependencies before running a task.

python:
  installDependencies: false

Not all toolchains support this tier 2 feature.

New task affectedFiles settings​

In v2 we introduced an object form for the the task option affectedFiles, allowing you to further customize this feature. Based on feedback from the community, we're introducing 3 new settings to this object:

• filter - A list of glob patterns to filter the affected files list before passing to the task.
• ignoreProjectBoundary - When matching affected files, ignore the project boundary and include workspace relative files. Otherwise, only files within the project are matched.
• passDotWhenNoResults - When there are no affected files after matching and filtering, use . instead of an empty value.

tasks:
  lint:
    command: 'eslint'
    inputs:
      - 'src/**/*.{ts,tsx}'
      - '**/*.json'
      - 'eslint.config.*'
    options:
      affectedFiles:
        filter: ['**/*.tsx?']
        ignoreProjectBoundary: true
        passDotWhenNoResults: false

Other changes​

View the official release for a full list of changes.

• Improved our local and remote detection logic. We now also check for common remote devboxes (GitHub Codespaces, Gitpod, etc) in addition to CI environments.
• Added a new task option, runInSyncPhase, that will run the task during moon sync commands.
• Go
  • Will now run go list --deps to determine project relationships while extending the project graph.
• Python
  • Normalized package/dependency names to PEP 503 during graph extending.
  • Fixed an issue where package manager toolchain settings were not being inherited correctly.
• TypeScript
  • Added a pruneProjectReferences setting that prunes non-moon managed project references when syncing.

We've been working on this release for years, and we're thrilled to finally share it with the world. We also want to thank everyone in the community who has contributed to this release, whether it's through code, documentation, testing, or just providing feedback and support. We couldn't have done this without you!

To start using moon v2, you can install it with one of the following commands!

# proto
proto install moon 2.0.0

# Unix
bash <(curl -fsSL https://moonrepo.dev/install/moon.sh)

# Windows
irm https://moonrepo.dev/install/moon.ps1 | iex

Breaking changes​

Since this is our first major release after v1, there are quite a few breaking changes, far too many to list here! Please refer to the official migration guide and changelog for a comprehensive list of breaking changes and how to address them.

CLI​

New and improved commands​

As part of this release, we went through every CLI command and made improvements to their usability, functionality, and rendered output. On top of this, we're also introducing a handful of new commands to fill some missing gaps. Here are some highlights:

• moon exec - Low-level command for running tasks. Read more below!
• moon extension - Top-level command to manage extensions in the workspace.
• moon hash - Inspect a hash, or diff two hashes.
• moon projects - Display a table of all projects.
• moon query affected - Query affected status for projects and tasks.
• moon tasks - Display a table of all tasks or for a specific project.
• moon template - Display information about a template.

New exec command​

To simplify running tasks and improve consistency across commands, we've introduced a new low-level moon exec command. This command is now used under the hood by moon check, moon ci, and moon run, with some arguments/options pre-filled. This allows us to have a single command that is responsible for executing tasks, while still providing higher-level commands for specific use cases.

This paves the way for future commands that can leverage moon exec, such as a potential moon deploy or moon watch command.

$ moon exec app:build --dependents direct

Additionally, it allows these other commands to inherit functionality they didn't support previously, like job parallelization, affected filtering, and more.

Updated ci, check, and run commands​

As mentioned previously, all of these commands have been reworked to use moon exec under the hood. This means that they now share the same core functionality and behavior, while still providing their own unique features and options.

$ moon ci
$ moon check app
$ moon run app:dev --affected

These commands will now pre-fill certain moon exec options for a curated experience. These options cannot be overridden, but the moon exec command can be used directly for more control.

Dynamic identifier & target selection​

For some commands that require a project, task, or template identifier/target, we've added an interactive selection prompt if no value is provided. This makes it easier to explore and use the CLI without needing to know specific identifiers ahead of time. The following commands now support this:

• moon check
• moon ci
• moon exec
• moon generate
• moon project
• moon run
• moon task
• moon template

To demonstrate this, here we are running moon project without an identifier:

$ moon project

│ Which project to view?
│
│ ❯ report
│   runtime
│   types
│   visualizer
│   website - A static website.
│
│ ⎵ select ⁃ ↕ cycle ⁃ ↵ submit

Stabilized moonx​

The moonx executable, sibling to moon, has been stabilized, and is no longer a shim, but a proper standalone binary. This executable is simply a shorthand for moon exec, and replaces the shorthand syntax that previously existed with moon <target>.

# Before
$ moon run app:build
$ moon exec app:build
$ moon app:build

# After
$ moonx app:build

Support for .config​

The .moon directory denotes the root of the workspace, but if you don't like clutter, this may feel overwhelming. To help with this, we've introduced support for the .config directory pattern, allowing you to define your workspace configuration in a more organized manner.

Simply use .config/moon instead of .moon! The workspace root will now be the directory that contains the .config directory.

Configuration​

New file formats​

We've been pretty strict about only supporting YAML based configuration for quite some time, but we understand that people have different preferences (many of you hate YAML, which is fair). We've experimented in the past a bit by adding support for Pkl, which is a programmable configuration, but it required a learning curve.

Over time, we've come to loosen our stance on YAML, and are now introducing support for not just one, but many additional formats! The following file formats are now supported for all moon configuration files:

• JSON (.json)
• JSON with comments (.jsonc)
• HCL (.hcl)
• Pkl (.pkl)
• TOML (.toml)
• YAML (.yml, .yaml)

Toolchains​

Plugin based system​

The new toolchain system replaces the legacy platform system and is the biggest change in moon v2. Toolchains are now powered by WASM plugins, instead of being hard-coded in core, allowing for more flexibility, extensibility, and the ability for the community to create their own toolchains!

Moving to a plugin based system enables us to support more languages, more features, deeper integration, as well as more complex workflows. For example, in the future we can now easily support release workflows (changelogs, versioning, publishing) as part of a toolchain.

Just to demonstrate how powerful the plugin system is, it currently supports all the following features:

• Extending the project graph with project dependencies and aliases
• Extending task commands and scripts before they're executed
• Integrates with our Docker flow for pruning and scaffolding
• Runs operations during the project/workspace sync processes
• Locates a root dependencies directory for package manager workspaces
• Parses manifest and lock files to extract dependencies and metadata
• Sets up the environment and auto-installs dependencies
• Hook into the task hashing process
• Manages downloading and installing tools (via proto)

Improved PATH handling​

Toolchain (and extension) plugins have the ability to modify the PATH environment variable for most child processes that occur during task execution, but the way we handled this has been improved significantly. Previously, there were some inconsistencies around when and how the PATH was modified, leading to unexpected behavior in certain scenarios. Going forward, we inherit paths using a strict order of operations:

• Inherit for all commands using extend_command extension and toolchain calls
• Inherit for task commands using extend_task_command or extend_task_script toolchain calls
• Inherit toolchain executable directories
• Inherit proto shims and bins directories
• Inherit proto and moon store directories

Extensions​

Stand-alone configuration​

Extensions are a WASM plugin based system that has existed for some time now, but they only supported a single functionality: custom execution through the moon ext command. With the introduction of toolchain plugins, we wanted to expand the extension system to allow for more flexibility and use cases.

To start, we're intoducing a new .moon/extensions.* configuration file, that will contain all extensions, similar to how toolchains are configured in .moon/toolchains.*. Because of this change, the extensions setting has been removed from the workspace configuration.

New plugin APIs​

With extensions now being first-class citizens in moon, we've expanded the PDK API to allow for more functionality. Extensions can now utilize the following API functions, similar to toolchains:

• define_extension_config - Define the configuration schema for the extension.
• initialize_extension - Initialize the extension with user prompts.
• extend_project_graph - Extend projects with aliases, dependencies, and tasks.
• extend_task_command - Extend the task command before it's executed.
• extend_task_script - Extend the task script before it's executed.
• sync_project - Run operations during the project sync process.
• sync_workspace - Run operations during the workspace sync process.

Management commands​

To easily manage extensions, we've added new commands under the moon extension namespace:

• moon extension add - Add a new extension to the workspace.
• moon extension info - Display information about an extension.

$ moon extension info migrate-nx

Extension ─────────────────────────────────────────────────────────────────

  Migrate an Nx repository to moon by converting all nx.json and
  project.json files into moon configuration files.

  ID: migrate-nx
  Title: Migrate Nx
  Version: 0.0.11

APIs ──────────────────────────────────────────────────────────────────────

  🟢 register_extension (required)
  ⚫️ define_extension_config
  ⚫️ initialize_extension
  🟢 execute_extension
  ⚫️ sync_project
  ⚫️ sync_workspace
  ⚫️ extend_project_graph
  ⚫️ extend_task_command
  ⚫️ extend_task_script

Projects​

Default project​

By request from the community, we've added a new defaultProject setting to the workspace configuration. This setting allows you to specify a default project that will be used when running tasks that require a project identifier, but none was provided. This is especially useful for workspaces with a single project, or when you have a primary project that you work on most of the time.

defaultProject: 'app'

# Before
$ moon run app:build

# After
$ moon run build
$ moonx build

Path based IDs​

When locating projects with globs via the projects workspace configuration, we would historically use the directory name as the project ID. While this works in most cases, it can lead to issues when the directory name collides with another project, or is not descriptive enough. For example, packages/server/utils would become utils. What if you also had packages/client/utils?

To solve this, we've introduced a new projects.globFormat setting, which can be configured as source-path and will use the full relative source path as the project ID.

projects:
  globFormat: 'source-path'
  globs:
    - 'packages/**/moon.yml'

Using the examples above, the resulting project IDs would now be packages/server/utils and packages/client/utils, respectively.

Multiple aliases​

In addition to identifiers, projects also support aliases, which are toolchain specific names derived from manifest files, for example, the name field in package.json or Cargo.toml. This allows you to refer to projects by their native names on the command line, in configuration, and more.

Previously, projects only supported a single alias, but now they support multiple aliases, one from each applicable toolchain. In addition, we have added a new $projectAliases token, which is a comma-separated list of all aliases. The existing $projectAlias token now returns the first alias, if it exists.

New data stack​

Our stack system represents all aspects of a development stack, except one, the database/data layer! To give you more control around categorization, we've added a new data stack type, which can be used to represent projects that are primarily focused on data storage. This includes databases, ETL pipelines, and other data-centric use cases.

stack: 'data'

Tasks​

Strict commands​

We've reworked the task command and args parser, when a string is provided, to be more strict and accurate. Previously, we used a simple shell-like parser that would split on spaces, but this led to issues with quoted strings, escaped characters, and other edge cases.

Related to this change, these fields will now only support simple commands and arguments, and will not support complex syntax like pipes, redirects, and conditionals. This is a breaking change, but you can use script instead for complex commands.

Inheritance via configuration​

Our task inheritance system is quite powerful, and one of moon's most compelling features. However, it can be rather restrictive as inheritance is based entirely on file naming conventions. To provide more flexibility, we've reworked task inheritance to be configuration based, by introducing a new inheritedBy setting for all .moon/tasks/**/* files.

For example, if you had a tasks file named .moon/tasks/node-frontend-library.yml, it would now be configured like so:

inheritedBy:
  toolchain: 'node'
  stack: 'frontend'
  layer: 'library'

This new system is very powerful, as you can now mix-and-match different criteria to control how tasks are inherited. The following conditions are supported out of the box, providing granular control:

• files (NEW) - Inherit for projects that contain specific files (no glob support).
• languages (NEW) - Inherit for projects that belong to specific languages.
• layers - Inherit for projects that belong to specific layers.
• stacks - Inherit for projects that belong to specific stacks.
• tags - Inherit for projects that have specific tags.
• toolchains - Inherit for projects that belong to specific toolchains.

inheritedBy:
  # Project belongs to either javascript or typescript toolchain, but not the ruby toolchain
  toolchains:
    or: ['javascript', 'typescript']
    not: ['ruby']
  # And project is either a frontend or backend stack
  stacks: ['frontend', 'backend']
  # And project is either a library or tool layer
  layers: ['library', 'tool']

Toolchain merging​

A task can now be associated with multiple toolchains (javascript, node, npm), unlike the previous platform system which only allowed for 1 platform (node). This change allows for more flexibility but also requires more granular control over how toolchains are inherited. To accommodate this, we've added a mergeToolchains task option:

tasks:
  build:
    # ...
    toolchains: ['javascript']
    options:
      mergeToolchains: 'replace'

Robust env files​

Tasks have supported .env files for a while now, but the implementation has been somewhat limited. We only supported the .env file with the ability for you to customize with an explicit list of files. This was cumbersome and didn't allow for much flexibility.

Going forward, when using envFile: true, moon will now automatically look for the following files in order, and load them if they exist:

• /.env
• /.env.local
• .env
• .env.local
• .env.<task_id>
• .env.<task_id>.local

Additionally, the following changes and improvements have been made.

• Added support for *.local files, which will only be loaded locally and not in CI environments.
• Deferred loading of env files until task execution time, instead of during task creation (breaking change).

New utility preset​

Task presets are helpful as the provide a set of default options and behaviors for common task types. However, we haven't fully utilized (pun intended) this feature yet, so are adding a new preset called utility. This preset is designed for simple one-off tasks that primarily run locally, like running a migration, or validating data.

This preset configures the following options:

• cache disabled
• interactive enabled
• persistent disabled
• outputStyle as stream
• runInCI as skip

tasks:
  validate-schema:
    # ...
    preset: 'utility'

Docker​

Defaults with overrides​

To improve customizability of Dockerfile generation, and to allow for more flexibility during the scaffolding process, we've updated the docker settings in .moon/workspace.* to act as defaults, and the docker settings in moon.* to act as overrides on a per-project basis. Because of this, we've also updated docker.file and docker.scaffold settings to be the same across both files.

# Inherited by all projects
docker:
  file:
    buildTask: 'build'

# Overridden per project
docker:
  file:
    buildTask: 'compile'

Dockerfile templates​

To further expand the customizability of Dockerfile generation, we've added support for custom templates to be used during the rendering process. The template can be provided with the --template option when running moon docker file, or configured with the new docker.file.template setting. Template rendering is powered by Tera.

$ moon docker file app --template ./Dockerfile.tera

VCS​

New implementation​

In moon v1 we were running an experiment that utilizes a new Git implementation, which we dubbed Git v2. We've made this the default implementation and removed the legacy implementation. This new implementation is faster, more reliable, and has better support for complex repositories (worktrees, submodules, etc). The experiments.gitV2 setting should now be removed.

Worktree compatible hooks​

We've rewritten our Git hooks system to be compatible with Git worktrees, and to better handle the core.hooksPath Git configuration. Previously hooks were written to .git/hooks at the repository root, but we now don't write to .git at all, and entirely rely on .moon/hooks in each tree.

You may need to enable the extensions.worktreeConfig Git setting for this to work properly.

Other changes​

View the official release for a full list of changes.

How to use​

You can install the beta with proto (>= 0.54.1), or download it directly from the GitHub release page.

$ proto install moon 2.0.0-rc.4

Alternatively, you can try using the new shell install scripts.

# Unix
curl --proto '=https' --tlsv1.2 -LsSf https://github.com/moonrepo/moon/releases/download/v2.0.0-rc.4/moon_cli-installer.sh | sh

# Windows
powershell -ExecutionPolicy Bypass -c "irm https://github.com/moonrepo/moon/releases/download/v2.0.0-rc.4/moon_cli-installer.ps1 | iex"

What's changed since beta?​

Besides a handful of bug fixes and performance improvements (thanks to all for testing), the biggest change this release is Python toolchain support.

Unlike other toolchains, the Python toolchain will be marked as unstable for a little while longer as we work through some final issues (as we are not Python experts). However, you can now use Python projects in moon v2!

unstable_python:
  packageManager: 'pip' # or 'uv'

unstable_pip: {}
# unstable_uv: {}

When using the Python toolchain, please note the following conventions (subject to change):

• A pyproject.toml is preferred, but not a requirement. However, we haven't tested without one.
• Use either pip or uv as the package manager.
• When using pip, a requirements.txt is considered a lockfile, while requirements.in is a manifest.
• Virtual environments are supported, but are created in the package root (uv workspace root, pip package) by default. We know this is not ideal for all workflows, and are looking into options to improve this.

As mentioned above, we are not Python experts, and don't have the requisite knowledge to implement Python developer workflows. We'd appreciate any help from the community to improve this toolchain!

What's next?​

Now that Python has landed, we are focused on wrapping up any remaining issues and PRs before the stable release, which we are aiming for next week, February 2nd! We don't plan to introduce any new breaking changes, only bug fixes, polish, and performance improvements.

We'd appreciate any help testing this release candidate before then!

How to use​

You can install the beta with proto (>= 0.54.1), or download it directly from the GitHub release page.

$ proto install moon 2.0.0-beta.1

Alternatively, you can try using the new experimental shell install scripts. Be warned that these haven't been tested thoroughly yet!

# Unix
curl --proto '=https' --tlsv1.2 -LsSf https://github.com/moonrepo/moon/releases/download/v2.0.0-beta.0/moon_cli-installer.sh | sh

# Windows
powershell -ExecutionPolicy Bypass -c "irm https://github.com/moonrepo/moon/releases/download/v2.0.0-beta.0/moon_cli-installer.ps1 | iex"

What's changed since alpha?​

We've been hard at work the past few weeks working on the following:

• The @moonrepo npm packages have been updated (and published) to support v2. Additionally, they are now published using OIDC tokens for improved security, and now support provenance.
• The official shell install scripts have been updated to support v2, but "latest" does not point to v2 yet. This means that the moonrepo/setup-toolchain GitHub Action can now point to v2.
• Updated the task command and args settings with a new parser that better handles shell syntax, preserves quoting, and much more. We've also made a breaking change where these settings now only allow simple commands, and script should be used for compound commands (pipes, redirects, etc).
• Updated the task envFile option to support token/var expansion.
• Handful of bug fixes and performance improvements.

What's still in progress?​

There are still some features and improvements that are not yet complete. Here are some of the things we are still working on:

• Rewriting the Python toolchain as a WASM plugin. Because this is incomplete, Python is currently not supported in the v2 alpha.
• Auditing open issues and PRs to see what else needs to be done before the stable release.

How to use​

You can install the alpha with proto (>= 0.54.1), or download it directly from the GitHub release page.

$ proto install moon 2.0.0-alpha.3

Alternatively, you can try using the new experimental shell install scripts. Be warned that these haven't been tested thoroughly yet!

# Unix
curl --proto '=https' --tlsv1.2 -LsSf https://github.com/moonrepo/moon/releases/download/v2.0.0-alpha.2/moon_cli-installer.sh | sh

# Windows
powershell -ExecutionPolicy Bypass -c "irm https://github.com/moonrepo/moon/releases/download/v2.0.0-alpha.2/moon_cli-installer.ps1 | iex"

The existing shell install script and npm packages have not been updated for v2 yet.

Breaking changes​

Since this is our first major release after v1, there are quite a few breaking changes, far too many to list here! Please refer to the official migration guide for a comprehensive list of breaking changes and how to address them.

New features​

This wouldn't be a major release without some exciting new features! Here are some of the highlights:

• New and improved CLI commands
• New configuration formats
• Toolchain and extension WASM plugins
• Default projects
• Config based task inheritance
• Reworked env var handling
• And much more!

For a in-depth look at all the new features and improvements, check out the official v2 blog post, which has not been published yet (still a work in progress).

Work in a progress​

Before we stabilize v2, there are still some features and improvements we want to make. Here are some of the things we are currently working on:

• Rewriting the Python toolchain as a WASM plugin. Because this is incomplete, Python is currently not supported in the v2 alpha.
• Updating the @moonrepo/cli npm package with the new distribution format. Because of this, the npm package is not yet published.
• Removing the auto-escaping/quoting from task arguments. This is a source of much confusion, and is only exacerbated by the differences between shells.
• Auditing open issues and PRs to see what else needs to be done before the stable release.

v2 in development!​

We've been talking about v2 for many years now, and with the near stabilization of toolchain WASM plugins, we're ready to pull the trigger! So what does this mean exactly?

We'd like to land v2 at the start of the new year, and to hit this milestone, we'll be focusing all our efforts on this initiative and will not be releasing any new features or improvements to the v1 line until v2 is released. This does not include bug fixes or security patches, which we will continue to provide as needed.

So what should you expect in v2?

• Toolchain WASM plugins stabilized, with the old platform system removed.
• Extension WASM plugins can extend the project graph and tasks.
• Remote cache powered by Bazel Remote Execution API stabilized.
• Task inheritance via inline configuration.
• Task inheritance deep merging/extending (is shallow right now).
• Default project when running tasks.
• Renamed and improved configuration settings.
• New binary release strategy.
• Improved CLI commands.
• And much more!

If you have any requests for v2, please leave a comment in the PR linked above! Additionally, if you'd like to help with v2, let us know!

New Deno toolchain powered by WASM​

In our last release we introduced an array of new JavaScript ecosystem toolchain plugins, but there was important plugin missing, Deno! Deno works quite differently than Node.js and Bun, so we wanted to spend some extra time and effort to get it right.

We're excited to announce Deno support, with full workspaces support and npm compatibility. This toolchain, unlike the previous implementation, only supports Deno >= v2, but also supports the following:

• Updated unstable_javascript.packageManager with deno.
• Will parse deno.json and deno.jsonc manifest files.
• Will parse deno.lock lock files.
• Will install dependencies with deno install.

unstable_deno:
  version: '2.5.0'

unstable_javascript:
  packageManager: 'deno'

New task inputs​

In v1.39 we introduced new formats for task inputs, a URI string format and an object format, based on this RFC. However, we only implemented support for files and globs. In this release, we have added support for more input types.

File groups​

Similar to the existing file group tokens (@files, @dirs, etc), we are introducing a new file group input type, with support for group:// URIs and group objects.

fileGroups:
  sources:
    - 'src/**/*'

tasks:
  build:
    # ...
    inputs:
      # Using group protocol
      - 'group://sources?format=dirs'
      # Using an object
      - group: 'sources'
        format: 'dirs'

External projects​

This feature has been highly requested, but we were unsure how to best implement it... until now. With the new external project input type, you can now rely on arbitrary files from other projects as inputs, instead of requiring no-op or intermediate task relationships. This is perfect for "I want any file change in a project dependency to trigger a rebuild" scenarios.

This input type supports both project:// URIs and project objects. Both of which require a project identifier, or ^ to inherit all project dependencies (similar to targets).

tasks:
  example:
    inputs:
      # Using project protocol
      - 'project://foo'
      # Using an object
      - project: 'foo'

By default this will include all files in the target project, using **/*, but this can be customized with explicit globs, or referencing a file group in the target project.

tasks:
  example:
    inputs:
      - 'project://foo?filter=src/**/*'
      - project: 'foo'
        group: 'sources'

Improved task outputs​

In the spirit of the new task inputs, we have also improved task outputs by applying the same formats treatment! All file and glob outputs now support the URI and object formats.

tasks:
  example:
    outputs:
      # Literal
      - 'dist/**/*'
      # Using glob protocol
      - 'glob://dist/**/*'
      # Using an object
      - glob: 'dist/**/*'

Additionally, file based outputs now support an optional parameter, which will avoid throwing an error if the output does not exist after a task has ran. This has also been a much requested feature!

tasks:
  example:
    outputs:
      - 'file://build/artifact?optional'
      - file: 'build/artifact'
        optional: true

Other changes​

View the official release for a full list of changes.

• Added new values to the runInCI task option:
  • only - Only run the task in CI, and not locally, when affected.
  • skip - Skip running in CI but run locally and allow task relationships to be valid.

New proto exec command​

Since proto's inception, we've had the proto run command for executing a specific tool with a list of arguments. While this works well for simple use-cases, like our shims layer, it has some limitations, such as:

• It only works with one tool at a time, not multiple.
• It cannot bootstrap the environment (vars and paths).
• It cannot execute arbitrary commands.
• It requires a tool to have a primary/main executable (not everything does).
• Executing a secondary executable is not straightforward.

To address these limitations, we're introducing a new command, proto exec! This command is designed to bootstrap the environment with any numbers of tools, and execute an arbitrary command within that environment.

For example, say we want to run a backend application that requires Node.js, pnpm, and Ruby, we can do the following:

$ proto exec node@24 pnpm@10 ruby@3.4 -- pnpm run app:start

This will load and activate these three tools, set environment variables, update PATH, and execute the command! Pretty nifty, right? It even supports executing the command within a shell! Head to the docs for more information.

Backend configuration support​

In our previous release, we updated backend plugins with user-driven support, instead of being hard-coded into proto core. To build upon this, we've improved the interoperability of backends by supporting configuration of the backend itself (not the tool that the backend represents), using the new [backends] setting.

For example, say you're using asdf:zig, which is the zig tool in the asdf backend. To configure the tool, you would use [tools."asdf:zig"], but to configure the asdf backend itself, you can now use [backends.asdf].

[backends.asdf]
backend-setting = "value"

[tools."asdf:zig"]
tool-setting = "value"

Backend configuration is useful where you want to control the behavior of the backend itself and apply it to all tools, while backend-managed tool configuration is useful when you want to control the behavior of a specific tool.

Other changes​

View the official release for a full list of changes.

• Added a mechanism for plugins to setup the environment during activation and execution workflows.
• Fixed an issue where shims that belong to a backend would fail to run.

Looking for contributors​

We have a lot of cool stuff planned for proto, like more official backends and tools, improved workflows, an official registry, and more! So if you're interested in Rust or WASM, we would love and appreciate your help. Feel free to ping us on Discord!

New JavaScript ecosystem toolchains powered by WASM​

Porting the legacy Bun and Node.js toolchains to WASM has been a non-trivial amount of work, as the JavaScript ecosystem is quite convoluted compared to other languages. The paradigms required by JavaScript simply don't exist in other languages, and as such, we've had to build custom functionality into our toolchain plugin system to support it properly.

On top of that, Bun and Node.js share a lot of functionality, and if you've been using both legacy toolchains in parallel, you may have noticed a handful of issues because of this, such as overlapping dependency installs, conflicting alias/task extraction, or over-reading of package.json files. Additionally, this doesn't even take Deno into account, which has its own set of problems to solve for interoperability.

To solve these problems, we've reimagined how JavaScript toolchains work in moon with the following goals in mind:

• Share as much functionality across Node, Bun, and Deno without duplication.
• Support any number of runtimes and package managers with clean interoperability.
• Allow each runtime and package manager to implement their own tier 1-3 features.
• Minimize the complexity of the toolchain configurations.
• Allow users to depend on these toolchains if necessary.

And the result of this rework is 6 new toolchains! Continue reading for more details.

Shared core: unstable_javascript​

A new JavaScript toolchain has been introduced, called unstable_javascript. This toolchain serves as the foundation for all other JavaScript-related toolchains, providing a shared core of functionality and settings. It implements tier 1 and tier 2 features, and is in charge of the following:

• Defines which package manager (and runtime) to use.
• Extends projects and tasks with package.json and node_modules information.
• Locates the dependencies root (package.json workspaces).
• Installs and dedupes dependencies for the defined package manager.
• Parses manifests and lockfiles for relevant information.
• Handles project and workspace syncing operations.
• And anything else that is shared across the JavaScript ecosystem.

unstable_javascript:
  packageManager: 'yarn'
  inferTasksFromScripts: false
  syncPackageManagerField: true
  syncProjectWorkspaceDependencies: true

If you're familar with the legacy Bun or Node.js toolchains, this should feel very familiar, as this is a combination of their functionality. Learn more about its settings:

• unstable_javascript

Runtimes: unstable_bun and unstable_node​

JavaScript is a unique language in that it has multiple runtimes, primarily Node.js, Bun, and Deno. We support Node.js through the new unstable_node toolchain, and Bun through the unstable_bun toolchain, with Deno support coming soon. These toolchains only implement tier 1 and tier 3 features, as tier 2 is handled by the core unstable_javascript toolchain.

Their primary role is to provide settings for runtime execution (task child processes), and for downloading and installing the runtime tool into the proto toolchain (when the version setting is defined).

The runtime that will be utilized in the action graph is defined by the new unstable_javascript.packageManager setting (bun = bun, npm/pnpm/yarn = node), but that doesn't stop you from using multiple runtimes in parallel.

unstable_node:
  version: '24.0.0'
  executeArgs: ['--preserve-symlinks']

Learn more about their settings:

• unstable_bun
• unstable_node

Package managers: unstable_npm, unstable_pnpm, and unstable_yarn​

All JavaScript package managers (including Bun) are now their own toolchain, with their own configuration, and are no longer nested within the Node.js toolchain. These toolchains only implement tier 1 and tier 3 features, as tier 2 is handled by the core unstable_javascript toolchain.

Their primary role is to provide settings for the unstable_javascript toolchain when installing and syncing dependencies, and for downloading and installing the package manager tool into the proto toolchain (when the version setting is defined).

Since there are multiple package managers, which do you need to configure? Only the one associated with the new unstable_javascript.packageManager setting!

unstable_pnpm:
  version: '10.15.0'
  installArgs: ['--frozen-lockfile']

Learn more about their settings:

• unstable_bun
• unstable_npm
• unstable_pnpm
• unstable_yarn

Migrating from legacy toolchains​

Migrating from the legacy toolchains to these new modern WASM toolchains is rather straightforward, as most of the existing settings have been ported over. Follow these steps:

• Move the node.npm, node.pnpm, and node.yarn configuration to its own top-level unstable_ toolchain.
• Move the bun.version or node.version setting to an unstable_bun or unstable_node toolchain respectively. If not using version, set an empty object.
• Remove the node.addEnginesConstraint setting.
• Rename the node or bun toolchain to unstable_javascript.
• Rename the node.binExecArgs setting to unstable_node.executeArgs.
• Rename the node.rootPackageOnly setting to unstable_javascript.rootPackageDependenciesOnly.

As an example, here's a before and after of our repository.

# Before
node:
  version: '22.14.0'
  packageManager: 'yarn'
  yarn:
    version: '4.8.0'
  inferTasksFromScripts: false
  syncPackageManagerField: true
  syncProjectWorkspaceDependencies: true

# After
unstable_javascript:
  packageManager: 'yarn'
  inferTasksFromScripts: false
  syncPackageManagerField: true
  syncProjectWorkspaceDependencies: true

unstable_node:
  version: '22.14.0'

unstable_yarn:
  version: '4.8.0'

Backwards incompatibility and caveats​

Because these new toolchains are built around a plugin system, and not hard-coded into core like the legacy toolchains, there are some backwards incompatibilities, changes, and caveats to be aware of:

1. Because the old node/bun toolchains are now spread across multiple new toolchains, instead of 1 toolchain, any configuration of the task toolchain setting may now be inaccurate, as this setting overrides all detected/inherited toolchains. We suggest omitting this field unless you want full control and understand what you are doing.

# Invalid
tasks:
  build:
    # ...
    toolchain: 'node'

# Valid
tasks:
  build:
    # ...
    toolchain: ['unstable_javascript', 'unstable_node', 'unstable_npm']
    # Or simply
    toolchain: ['javascript', 'node', 'npm']

2. Additionally, task inheritance may not function the same, based on what toolchains are now automatically detected. Ensure that projects and tasks inherit the correct toolchains by utilizing moon project and moon task commands.

If either of these issues, or other unexpected issues arise, please report it so we can fix it, or provide a work around!

New task caching options​

Tasks have always supported a cache option for toggling caching on and off. With the introduction of remote cache, we're expanding these options to provide more flexibility and control. Instead of supporting only a simple boolean flag, we're introducing new local and remote values, which will only cache locally or remotely, respectively.

This is useful for tasks that need caching, but should not persist in the remote cache, and vice versa.

tasks:
  build:
    # ...
    options:
      cache: 'local'

New local read-only mode for remote cache​

Adoption of our new remote cache solution has been going great, and we've heard positive feedback from users about its performance and reliability. However, it's not perfect and can always be improved!

And as such, we're introducing a new unstable_remote.cache.localReadOnly setting, which will only read (download) outputs from the remote cache when in local development, but will not write (upload) outputs. This is useful for teams that want to share cache between CI and local, but don't want the overhead of uploading in-development outputs.

unstable_remote:
  cache:
    localReadOnly: true

Other changes​

View the official release for a full list of changes.

• Updated moon query touched-files to default to comparing against remote branches when in CI, and local when not in CI. This aligns with the other moon query commands.
• Updated task commands (child processes) to utilize toolchain executables directly, instead of relying entirely on proto shims. It achieves this by locating the executables, and prepending their directory onto PATH.
• When running a task, we now set a MOON_TASK_HASH environment variable for the current hash, which can be read from child processes.
• Published the moon VSCode extension to Open VSX: https://open-vsx.org/extension/moonrepo/moon-console

What's next?​

With toolchains plugins being stabilized more, we'd like to focus on some other areas.

• Implement more of the task inputs RFC: https://github.com/moonrepo/moon/issues/1985
• Investigate a new unstable_deno toolchain
• Investigate better task inheritance: https://github.com/moonrepo/moon/issues/2023

Custom backend plugins​

In proto v0.47 we announced support for backend plugins, starting with asdf. However, the initial plan was for backend plugins to be an internal only feature, maintained by the proto team directly. After some thought, we realized that this was a bit limiting, and would ultimately slow down the growth of proto's ecosystem. So, in this release, we're opening up backend plugins to the community!

Backend plugins are a superset of tool plugins that inherit all of their functionality, with additional backend specific functionality layered on top. This means that backend plugins can define and manage multiple tools, and also handle installation, version resolution, and more.

To support backend plugins, we've made some changes to the configuration format. Backend plugins can be configured with the new [plugins.backends] section, and tool plugins have moved to the [plugins.tools] section. For backwards compatibility, the old [plugins] section will still work for now.

[plugins.backends]
my-backend = "https://raw.githubusercontent.com/my/backend/master/proto-plugin.wasm"

Breaking: New backend identifier format​

To support the backend plugins going forward, we've had to make a breaking change to the way backends are identified in configuration. Previously, the backend was specified by prefixing the version like asdf:1.2.3, or with the [tools.*.backend] setting. This was very restrictive.

Going forward, the backend can only be prefixed as part of the tool identifier.

# Before
zig = "asdf:0.13.0"

# After
"asdf:zig" = "0.13.0"

Other changes​

View the official release for a full list of changes.

• Updated lockfiles to track os and arch information when applicable.

Looking for contributors​

We have a lot of cool stuff planned for proto, like more official backends and tools, improved workflows, an official registry, and more! So if you're interested in Rust or WASM, we would love and appreciate your help. Feel free to ping us on Discord!

Improved task inputs​

A few months ago we introduced an RFC for improving task inputs that introduces new syntax, functionality, and input types. In this release, we have implemented a portion of the RFC for testing before we implement the rest. Continue reading for more details!

New formats​

To start, we are introducing 2 new formats for configuring task inputs, a URI format and an object format, both of which support custom parameters.

URIs​

URIs should be rather familiar, as they are a string prefixed with a scheme (://), followed by a value, and an optional list of query parameters (?). Currently files can be specified using the file:// scheme, and globs with the glob:// scheme. Environment variables do not support URIs.

tasks:
  build:
    # ...
    inputs:
      - 'file:///*.config.js?optional'
      - 'glob://src/**/*.ts'

Objects​

Objects provide an alternative to strings, allowing you to customize parameters in a standard and familiar format. Files can be specified using the file key, and globs with the glob key. Environment variables do not support objects.

tasks:
  build:
    # ...
    inputs:
      - file: '/*.config.js'
        optional: true
      - glob: 'src/**/*.ts'

New parameters​

As mentioned above, file and glob inputs now support parameters, which can be customized using URI and object formats. The following parameters are available:

Files​

• content (string) - When determining affected state, will match against the file's content using the defined regex pattern, instead of relying on file existence.
• optional (boolean) - When hashing and set to true and the file is missing, will not log a warning. When set to false and the file is missing, will fail with an error. Defaults to logging a warning.

Globs​

• cache (boolean) - When gathering inputs for hashing, defines whether the glob results should be cached for the duration of the moon process. Defaults to true.

Better proto integration​

In previous versions of moon, we would automatically install proto for you based on certain conditions. This logic was applied to all moon sub-commands, which was not necessary, as it was only required for task running related commands.

To improve this, we have integrated proto into the action pipeline through a new action, SetupProto, which runs before any SetupToolchain action. With this, proto is only installed when required by that specific toolchain, and not for every command.

New proto setting​

Additionally, we are introducing a proto setting in .moon/toolchain.yml, which can be used to control the integration of proto in moon. To start, you can now customize the proto version! This is extremely useful if you want to test new proto features, or need to rollback to an older version.

proto:
  version: '0.51.4'

Other changes​

Lastly, proto has been upgrade to v0.51, which includes 2 major features: lockfiles and custom registries. However, we have yet to test these features thoroughly in moon, so they are not "officially" supported yet, but you can still use them if you wish. We will be adding support for these features in the future.

Project layers​

Project layers may sound like a new feature, but they are simply a rename of the project type. Going forward, the type setting in moon.yml has been renamed to layer, but backwards compatibility will be maintained until v2. Why the rename?

The term "layer" better reflects the purpose and functionality of this concept, as it defines a layer (the layer setting) within the development stack (the stack setting), and helps to enforce proper relationships. This change aims to improve clarity and consistency in our configuration.

For example, the following layers are available, from highest to lowest. Layers can then depend on lower layers, but not higher layers. Except for automations and applications, they can also depend on themself.

Because of this rename, the following changes have been made:

• type --> layer in moon.yml
• --type --> --layer in moon query projects
• projectType --> projectLayer for MQL
• $projectType --> $projectLayer for task tokens
• enforceProjectTypeRelationships --> enforceLayerRelationships in .moon/workspace.yml

Other changes​

View the official release for a full list of changes.

• Added unstable support for bubbling up logs from WASM plugins.
• Updated the @moonrepo/cli npm package to no longer rely on postinstall scripts.
• Improved argument quoting for commands and scripts.

What's next?​

With toolchains plugins being stabilized more, we'd like to focus on some other areas.

• Better command line argument parsing/joining (especially for task args)
• Pkl configuration improvements
• WASM toolchain documentation

Unstable lockfile support​

Lockfiles have been requested by the community since proto's inception, but adopting them has been a non-trivial task, as it requires touching almost every aspect of proto. With that said, we've been slowly reworking the internals to support lockfiles, and with this release, we're introducing unstable support for them!

If you're unaware of what lockfiles are, they allow you to pin the exact version (and checksum) of a tool that is installed, ensuring that your development environment is consistent and reproducible. If you've used package managers like npm, Cargo, or uv, you're likely familiar with this concept.

In proto, the concept of lockfiles is mostly the same, but the manner in which they are created and updated may differ based on other tools. To start, lockfiles in proto are opt-in and can be enabled with the new settings.unstable-lockfile setting in .prototools.

[settings]
unstable-lockfile = true

This will create a .protolock file in the current directory, relative to the .prototools file. In effect, this locks that directory and all of its subdirectories. As a side-effect, nested lockfiles are not supported.

To demonstrate how lockfiles work, installing the following tools with proto install...

bun = "1.2.0"
deno = "2.4.0"
node = "22.17.0"

[settings]
unstable-lockfile = true

... would generate the following .protolock file:

# Generated by proto. Do not modify!

[[tools.bun]]
spec = "1.2.0"
version = "1.2.0"
checksum = "sha256:fa72173cb2220d00e2d2650fefdc0b5b37bfd8bb33d8d671b50efb409c2f5745"

[[tools.deno]]
spec = "2.4.0"
version = "2.4.0"
checksum = "sha256:c913d018d64c48dcc5b7b90d844efb6d017595a7c1e237f89141df1b3ef8b962"

[[tools.node]]
spec = "22.17.0"
version = "22.17.0"
checksum = "sha256:cc9cc294eaf782dd93c8c51f460da610cc35753c6a9947411731524d16e97914"

Updated workflows​

The proto run (shims), proto install, and proto uninstall commands have been updated to support lockfiles.

When running or installing tools and a matching specification exists in the lockfile, the locked version will be inherited even if there's a newer version upstream, and the tool's checksum will be validated when available. These checks can be bypassed with the new --update-lockfile flag (install only).

Inversely, when uninstalling tools, the lockfile will be updated to remove any matching specification records.

Still a work in progress​

We are marking lockfiles as unstable as they have not been fully implemented or thoroughly tested. There are other commands like proto outdated and proto status that are not lockfile aware yet, but will be in the future.

But please, give them a whirl and let us know what you think!

Unstable OCI registries for plugin storage​

Another important feature that is necessary for proto's success is support for an official plugin registry. Before we get to that, we need to lay the groundwork for how plugins are stored and distributed. With this release, we're introducing unstable support for OCI registries as a storage mechanism for plugins. If you're unfamiliar with OCI registries, they are a standard for storing and distributing container images (Docker), but can also be used to store other types of artifacts, in this case, WASM plugins.

To support registries, we have introduced a new settings.unstable-registries setting in .prototools, which allows you to configure a list of registries to query for applicable plugins. For example:

[settings]
unstable-registries = [
  { registry: "ghcr.io", namespace: "moonrepo" }
]

Additionally, we are introducing a new registry:// plugin locator, which allows you to configure a plugin by its OCI reference.

[plugins]
# Longform with tag
bun = "registry://ghcr.io/moonrepo/bun_tool:v1.2.3"
# Longform without tag
bun = "registry://ghcr.io/moonrepo/bun_tool"
# Shortform with tag
bun = "registry://bun_tool:v1.2.3"
# Shortform without tag
bun = "registry://bun_tool"

How it works​

Using a container registry to store plugins seems odd at first, but it actually allows us to leverage existing specifications, infrastructure, and tools to manage and distribute plugins. We don't want to re-invent the wheel here, so why not use something that most of the industry is already using?

With that said, how does this work in proto? Since we are not a container image, we use the artifact portion of the specification instead. Primarily, plugins are stored in layers! The blob/content of WASM, TOML, JSON, and YAML plugins are stored in CAS, and referenced in layers by a sha256 digest.

As for annotations, we support the OCI standard annotations, but will also support moonrepo-specific annotations in the future.

Official registry?​

We do have plans to support an official moonrepo plugin registry, for both proto and moon. We are in the process of investigating solutions to this and will provide more details soon.

Other changes​

View the official release for a full list of changes.

• Removed --canary from proto install, just use canary as the version specifier instead.

Looking for contributors​

We have a lot of cool stuff planned for proto, like backend plugins, more official tools, improved workflows, an official registry, and more! So if you're interested in Rust or WASM, we would love and appreciate your help. Feel free to ping us on Discord!

RFC: Task inheritance via inline configuration​

Task inheritance is one of moon's most powerful features, allowing you to define tasks at the top-level and have them automatically inherited by projects that match certain conditions. In it's current form, task inheritance is based on the file name of the configuration file, but this approach has several limitations.

We're planning to improve task inheritance and have written up an RFC to discuss these changes. We'd appreciate any and all feedback!

New Go toolchain powered by WASM​

Official Go toolchain support has been requested by the community for a long time now, and with the somewhat stabilization of WASM plugins and the introduction of the Rust toolchain in the last release, we felt it was finally time to add Go! To enable Go, run our new command or add an unstable_go entry to .moon/toolchain.yml.

$ moon toolchain add unstable_go

unstable_go:
  version: '1.24.0'
  workspaces: true

The Go toolchain releases with full tier 1, 2, and 3 support! Additionally, the following features and functionality is available when enabling the toolchain:

• Supports Go workspaces through the go.work file. Can be disabled with the unstable_go.workspaces setting.
• Extracts the go.mod module directive as a project alias.
• Extracts project relationships and dependency information from go.mod require directives.
• Extracts version and checksum information from go.sum and go.work.sum files.
• Injects Go globals directory (GOBIN) into task command/script child processes.
• Supports installing Go globals via go install commands. Can be customized with the unstable_go.bins setting.
• Automatically runs go mod or go work commands when installing dependencies.
• Basic Docker image and pruning support.

We hope you enjoy this new Go toolchain. With that said, we are not Go experts, and would love to hear from you on what works, what doesn't, what can be improved, and what features you would like to see added!

New MCP tools​

In our last release, we introduced the moon mcp command, offering deep editor integration with AI models like GitHub Copilot and Cursor. This release expands on that by introducing 3 more tools to utilize:

• get_touched_files - Gets touched files between base and head revisions.
• sync_projects - Runs the SyncProject action for one or many projects by id.
• sync_workspace - Runs the SyncWorkspace action.

New OS terminal notifications​

This was a feature we originally scoped out during moon's inception, almost 3 years ago, but we never got around to implementing it. However, there has been some improvements to native operating system notifications in Rust lately, so it felt like a good time to finally implement it!

And on that note, we are introducing a new notifier.terminalNotifications setting that allows you to receive terminal notifications for pipeline events.

notifier:
  terminalNotifications: 'failure'

View the official guide for more information!

Other changes​

View the official release for a full list of changes.

• Added new moon toolchain command and sub-commands.
  • Add a toolchain to .moon/toolchain.yml with moon toolchain add.
  • View information about a toolchain plugin with moon toolchain info.
• Added a notifier.webhookAcknowledge setting, that ensures webhooks resolve with a 2XX status code.
• Updated proto to v0.50.1 (from 0.49.4).

What's next?​

With toolchains plugins being stabilized more, we'd like to focus on some other areas.

• Better command line argument parsing/joining (especially for task args)
• Better child process I/O piping
• WASM toolchain documentation

Rewrite URLs for better interoperability​

proto is heavily reliant on URLs, as they power everything from tool and plugin downloading to version resolving. Many URLs are hard-coded into proto but most of them come from plugins. For the most part this is fine, but if you work within a corporate environment, or have a firewall, you may have to deal with proxy servers, mirrors, or other factors.

Until now, this was very difficult to circumvent, so we wanted to provide a built-in solution to this problem, and as such, we're introducing the new url-rewrites configuration setting. This setting accepts a map of regex patterns to replacements, and will rewrite URLs that match the pattern.

[settings.url-rewrites]
"github.com/(\\w+)/(\\w+)" = "gh-mirror.corp.com/$1/$2"
"mo+n" = "lunar"

For example, in the configuration above, any URL that contains github.com will be replaced with gh-mirror.corp.com, and any URL that contains the word "moon" (with different length o's) will be replaced with "lunar". Learn more about URL rewriting in the settings documentation!

Activation flow now triggers immediately​

Our activation flow (shell hooks) is seeing more and more usage, with improved stability, but based on feedback we've received, there was still some pain points. One of these pain points was that activation would not trigger immediately (new terminal window/tab), and would only trigger after changing directories.

There was a way around this using the --on-init flag, but that was not easily discoverable, and the setup as a whole was not very intuitive. With this release, that flag has been deprecated and the activation flow now triggers immediately, so you can start using your tools right away.

Historically we've been hesitent to do this, as we were worried about potential performance hits when having to download WASM plugins, or refetch caches. However in practice this has not been an issue.

Comments are now preserved in .prototools​

This has been a long standing issue and a long requested feature, and it's finally here! Comments are now preserved in .prototools files, and they'll no longer be removed when running proto commands that modify these files (like proto alias or proto pin).

Historically this has been a hard problem to solve, as Rust serde (serialization/deserialization library) strips comments when deserializing (reading) the file. To solve this problem, we had to avoid serde, and operate on an AST-like structure instead. Because of this, we lose type-safety and there may be some edge cases not accounted for.

Plugin commands are now executed within a shell​

When a plugin executes a command (child process) on the host system (your computer), it now executes it within a shell, e.g. bash -c "command". This change was made to ensure environment variables (like PATH), aliases, and other shell features that you have configured are available to the plugin.

By default the shell to use is detected from the parent host process, but you can override it with the PROTO_SHELL environment variable. For example, to use zsh you can set:

PROTO_SHELL=zsh

Other changes​

View the official release for a full list of changes.

• Added --dir and --all options to the proto bin command.
• Added environment variable support to many non-tool related .prototools settings.
• Updated proto install <tool> (without version) to install a version pinned in .prototools, instead of the latest version.

RFC: Task input additions and enhancements​

We're planning to improve task inputs and have written up an RFC to discuss these changes. We'd appreciate any and all feedback!

New Rust toolchain powered by WASM​

With toolchain plugins entering beta last release, it's only natural that we start migrating the legacy toolchains into plugins. And with this release, the next one we've migrated is the Rust toolchain! However, unlike the TypeScript toolchain, the new Rust toolchain is opt-in and must be enabled. Simply rename rust to unstable_rust in .moon/toolchain.yml.

unstable_rust:
  version: '1.87.0'
  components: ['clippy', 'rustfmt']
  targets: ['wasm32-wasip1']
  syncToolchainConfig: true

New functionality​

Although the new Rust toolchain is a one-to-one port, the WASM APIs provide far more flexibility and functionality than before. For example, the follow improvements and enhancements have been made:

• The Cargo workspace can now exist at any folder depth and does not need to exist at the moon workspace root. Additionally, because of this, we can now support multiple Cargo workspaces in the same moon workspace.
• Added a new addMsrvConstraint setting, which will sync the version as a constraint to Cargo.toml under the workspace.package.rust-version or package.rust-version fields.
• Improved the accuracy of implicit project dependencies (inferred from Cargo.toml).
• Improved the parsing of manifest (Cargo.toml) and lock (Cargo.lock) files. This information is then fed into the task hashing process.
• Improved the Docker prune implementation by preserving all binaries (inferred from cargo metadata) while deleting the target directory.
• Any cargo or rustup commands are now hashed and cached, and will only re-run when parameters change. Unlike the current toolchain, which always runs these commands.

Quite a list of improvements, and this doesn't even include all the WASM / plugin improvements that have been slowly introduced! Give this new toolchain a try, and let us know what you think!

MCP editor integration​

AI is all the rage these days, and even more so lately with the introduction of MCP (model context protocol) and agentic workflows. MCP is a new way for AI assistants to "understand" what's going on in your project without you having to explain everything. It works by feeding structured information, like in the context of moon, projects, tasks, and relationships, directly into AI models like GitHub Copilot or Cursor.

No more tedious explanations required! The AI can jump straight to helpful suggestions that actually work in your codebase, saving you time, and making the whole experience much smoother, especially in complex monorepos with lots of moving parts.

To support agentic workflows, we're introducing an experimental moon mcp command, that starts an MCP server, and can be integrated into your editor. For example, VS Code:

{
  "servers": {
    "moon": {
      "type": "stdio",
      "command": "moon",
      "args": ["mcp"],
      "env": {
        "MOON_WORKSPACE_ROOT": "${workspaceFolder}"
      }
    }
  }
}

Supported tools​

Our MCP server currently supports the following tools. We'll be adding more tools in the future, so if you have any suggestions, please let us know!

• get_project - Get a project and its tasks by id.
• get_projects - Get all projects.
• get_task - Get a task by target.
• get_tasks - Get all tasks.

Other changes​

View the official release for a full list of changes.

• Added environment.initializing and environment.initialized webhook events.
• Added root and toolchain fields to dependencies.installing and dependencies.installed webhook events.
• Updated proto to v0.49.4 (from 0.49.1).

What's next?​

With toolchains plugins being stabilized more, we'd like to focus on some other areas.

• Better command line argument parsing/joining (especially for task args)
• Better child process I/O piping
• Terminal notifications
• WASM toolchain documentation

Looking for toolchain contributors!​

Now that the Rust toolchain has been ported to WASM, we'd like to start porting the other toolchains, starting with Go and JavaScript (not Bun or Node.js), and also investigate supporting toolchains for entirely new languages, like PHP and Ruby! If you're interested in contributing these toolchains, please ping us in Discord!

The only requirements is that these toolchains must be written in Rust and must exist in the moonrepo/plugins repository!

Beta release of toolchain WASM plugins​

Two months ago we announced alpha toolchain plugins with support for tier 3, but not tier 2. The reason for this was that tier 3 is powered by proto APIs, which already existed! We simply hooked them up to moon. The bulk of the remaining plugin work was tier 2 support, which we are excited to announce has been completed! The following APIs have been implemented:

• extend_project_graph - Extend projects with toolchain specific info.
• extend_task_command - Extend the command child process with parameters.
• extend_task_script - Extend the script child process with parameters.
• locate_dependencies_root - Locate the package dependencies workspace root.
• parse_manifest - Parse a manifest file to extract dependencies.
• parse_lock - Parse a lock file to extract resolved dependencies.

And the following surface areas have been integrated with:

• In the project graph:
  • Extend projects with dependencies, tasks, and an alias.
• In the action pipeline:
  • Added SetupEnvironment action that executes the setup_environment API.
  • Added InstallDependencies action that executes the install_dependencies API.
• When running tasks:
  • Extend the command/script with additional parameters before executing.
  • Inject dependency and lock information into the hash.
• With Docker:
  • Updated docker prune to utilize the new WASM APIs for toolchain plugins.

As of this release, all 27 APIs have been implemented, and toolchain plugins are now available for general use! However, they are still quite unstable, not fully tested, and the APIs may change between releases, but you can start using them today if you're feeling adventurous!

With all this said, we do not have documentation yet. We plan to slowly work on this across the next few releases. In the meantime, check out the following resources for more information:

• moon_pdk - Rust plugin development kit.
• Existing toolchain plugins.
• In development Rust toolchain.

Optimized remote caching​

Like the past few releases, we've made some improvements to the remote caching layer.

To start, we're adding a new unstable_remote.cache.verifyIntegrity setting, that will verify the digest (hash) of downloaded blobs to ensure they aren't corrupted or incomplete. We currently check the file size, but this will also now check the content. This setting will slightly degrade performance but ensure reliability.

unstable_remote:
  cache:
    verifyIntegrity: true

While we're on the topic of reliability, we're also introducing an implicit rollback mechanic that will remove partially downloaded or incomplete blobs if hydration ever fails at some point. This will also run between executions to ensure there are no stale artifacts lying around.

And lastly, we've parallelized the blob existence checks, reducing the amount of large requests for heavy tasks, and reworked how we inherit MOON_REMOTE_* environment variables.

Improved code generation​

It's been a while since we've added new features to code generation, but thanks to some great requests from the community, we have 2 this release!

Archive URLs​

The first is that remote archives (zip, tar, etc) can be used as template locations. The archive will then be downloaded and unpacked into ~/.moon/templates.

generator:
  templates:
    - 'https://domain.com/some/path/to/archive.zip'

Array and object types​

The second is that we now support array and object variable types in template.yml. The values within each of these collections can be any JSON-compatible type.

variables:
  type:
    type: 'array'
    prompt: 'Type?'
    default: ['app', 'lib']
  metadata:
    type: 'object'
    prompt: 'Metadata?'
    default:
      internal: true

These variables and their nested values can then be accessed within templates using dot or bracket notation.

{{ type[0] }}
{{ metadata.internal }}

Other changes​

View the official release for a full list of changes.

• Added --host and --port options to moon action-graph, moon task-graph, and moon project-graph.
• Added --stdin option to moon ci and moon run, which will allow touched files to be passed via stdin, instead of running VCS commands to determine them.
• Removed the restriction around moon.{yml,pkl} not being allowed as a task input. However, will not be included when using **/*.

What's next?​

Now that toolchain plugins are in beta, we can take the next step in migrating an existing platform into a toolchain.

• Migrate the Rust toolchain to a WASM plugin.

Improved action graph​

For this release we wanted to introduce a new WASM based Rust toolchain, but we encountered a few blockers while integrating with the action graph, so instead of working on the toolchain, we decided to rewrite the action graph to properly support plugins.

The biggest blocker was around locating the toolchain's dependency root, and in Rust's case, the Cargo workspace (where Cargo.lock is located). We technically have some of this logic in the current Rust platform, but it always assumed that the Cargo workspace was in the root of the moon workspace (the same applies to Bun and Node). This heavily restricted all moon users. With the new plugin system, the dependency root can be located anywhere in the moon workspace, and we'll attempt to locate it!

While rewriting the action graph, we made a ton of improvements (some won't be noticeable until plugins are more prevalent). To start the graph is now async compatible, and in the future, we'll update it to also support concurrency, so that the graph can be built in parallel across threads. Additionally, a main focus was reducing the amount of edges (relationships) being created between nodes (actions). And lastly, the following changes were made for the actions themselves.

• Added a new InstallDependencies action for WASM plugins.
  • The dependencies root is now dynamically located by traversing the file system, unlike the previous implementation that assumed everything was in the workspace root.
• Added a new SetupEnvironment action for WASM plugins.
  • This runs after SetupToolchain but before InstallDependencies.
  • Can be used to setup the workspace or project environment. For example, initializing Python venv, or making manifest/lockfile changes.
• Updated RunTask to setup toolchains and install dependencies for each toolchain that has been configured, instead of just the 1st one (work in progress).
• Updated SyncProject to no longer depend on SetupToolchain, and not be grouped by language/toolchain, and instead encompass all of them applicable to the project.

Task priorities​

Based on a request from the community that we really liked, we're introducing a new concept called task priorities. Each task can configure a priority level using the new task option priority, and the priority level determines the position of the task within the action pipeline queue. A task with a higher priority will run sooner rather than later, while still respecting the topological order.

tasks:
  build:
    # ...
    options:
      priority: 'high'

There are a few things to be aware of with this implementation:

• All non-task related actions (like setup toolchain) will still always run first.
• Higher priority tasks that depend on lower priority tasks will effectively mark them as high priority, as we attempt to complete them sooner.
• The order within each priority level is sorted topological, but is still non-deterministic if tasks run in parallel.

Enabled experiments​

In our last release, we introduced 2 new experiments, fasterGlobWalk and gitV2. In the past few weeks, we've had many users (including ourself) enable these experiments without issue. As such, we've decided to enable them by default in this release.

If you encounter an issue with either of these experiments, you can disable them in .moon/workspace.yml. And of course, please report it so we can fix it!

experiments:
  fasterGlobWalk: false
  gitV2: false

Light terminal theme​

By default, moon assumes a dark themed terminal is being used, and will output our branded colors accordingly. However, if you use a light theme, these colors are hard to read, and there's no way to change them.

To mitigate this, we're introducing a light based terminal theme, which can be enabled with the --theme global option, or the MOON_THEME environment variable.

$ moon run app:build --theme light
# Or
$ MOON_THEME=light moon run app:build

Other changes​

View the official release for a full list of changes.

• Added a new task option, cacheKey, which can be used to seed the hash, and invalidate local and remote caches.
• Added a --log=verbose level, which includes span information on top of the trace level.
• Added 2 new webhooks, toolchain.installing and toolchain.installed, which emit when a toolchain WASM plugin is installing a tool (via proto).

What's next?​

Now that are action graph supports plugins, we can take the next step in migrating an existing platform into a toolchain.

• Migrate the Rust toolchain to a WASM plugin.
• Investigate a new args/command line parser.
• Add Poetry support for the Python toolchain.

moonbase has been sunset​

As mentioned in previous releases, we have sunset moonbase, our remote caching service. A while back we had internal discussions on whether to rework moonbase so that it could be self-hosted (on-premises), or adopt the Bazel Remote Execution API and utilize what the open source community has to offer. We ultimately decided with the latter, as it frees up resources on our end to focus on moon and proto, and also provides a better path forward for moon adoption.

If you are currently using moonbase, we suggest migrating to our new remote caching options. And if you have an active moonbase subscription, it will be cancelled within the week, and any partial billing for this month will be prorated.

Customize actions in the pipeline​

When a task is ran in moon, we create an action graph (not a task graph) of actions, which are operations required to run to ensure a successful execution. This includes non-task related functionality, like project and workspace syncing, installing dependencies, and ensuring the toolchain has been setup. While these actions only take milliseconds to execute (on a cache hit), they can become quite a barrier and source of friction (on cache miss).

Until now, there wasn't anyway to disable/skip these extra actions -- besides some non-documented environment variables that didn't actually omit the actions (they were still in the graph), but simply skipped the inner execution. In this release, we're introducing 4 new settings for pipeline (formerly runner) in .moon/workspace.yml.

• installDependencies setting toggles the inclusion of the InstallWorkspaceDeps and InstallProjectDeps actions, and can be scoped to toolchain IDs.
• syncProjects setting toggles the inclusion of the SyncProject actions, and can be scoped to project IDs.
• syncProjectDependencies setting toggles whether to recursively create SyncProject actions for each dependency of a project, or just for itself.
• syncWorkspace setting toggles the inclusion of the root SyncWorkspace action.

For example, if you want to disable all of these actions entirely, you can do this:

pipeline:
  installDependencies: false
  syncProjects: false
  syncProjectDependencies: false
  syncWorkspace: false

And as mentioned above, the installDependencies and syncProjects settings support configuring a list of IDs, which acts as an allow list. Any IDs not listed here will not create actions.

pipeline:
  # Only install Node.js dependencies
  installDependencies: ['node']
  # Only sync the `app` project
  syncProjects: ['app']

New --no-actions flag​

To expand upon the above, we're introducing a --no-actions flag to moon run, that will run the task without the other actions being added to the graph. We suggest only using this flag once dependencies have been installed, and the toolchain has been setup!

$ moon run app:start --no-actions

New experiments​

It's been a while since we've added new experiments, and in this release, we've got 2! We encourage everyone to enable these experiments to ensure they are working correctly, but do note that these are a work in progress and may be buggy.

Faster glob walking​

We've been monitoring glob performance for sometime now, as walking the filesystem has been one of the largest bottlenecks, especially in large codebases. We felt it was about time to tackle the problem.

With this new implementation, we are doing a few things to increase performance. To start, we are parallelizing walking per directory, where previously this would happen serially. Next, we partition globs based on a common ancestor directory, which reduces the amount of unnecessary walking. And lastly, we cache common globs to avoid walking all together.

In our benchmarks and tests (moon itself is already using it), we are seeing performance increases by 1.5-2x! To start using this new glob implementation, enable the new fasterGlobWalk experiment.

experiments:
  fasterGlobWalk: true

Better Git integration​

Our current Git integration works, assuming you're not doing anything complex, like using submodules or worktrees. If you are using the latter, things have been buggy. We're not happy about this, as we want to support all the different ways a repository can be architected.

So we started over from scratch! We even created real repositories to ensure our understanding and implementation of these features is accurate. This new implementation achieves the following:

• Supports submodules, subtrees, and worktees (unique among build systems).
  • Our competitors don't support these, and we expect them to "borrow" our implementation in the future (like they have with other features).
• Git commands are parallelized when applicable.
• Touched files within submodules are now properly extracted.
• File discovery and hashing is more performant.

If you'd like to try this new Git implementation (moon itself already is), enable the gitV2 experiment.

experiments:
  gitV2: true

Other changes​

View the official release for a full list of changes.

• Added a --json flag to moon templates.
• Integrated a new console rendering system with new terminal styles, prompts, and output.
• Improved the performance of environment variable substitution.
• Improved toolchain plugin loading to be on-demand.
• Improved sync cache invalidation for codeowners, config schemas, and VCS hooks.

What's next?​

Going forward, we plan to release new updates on a bi-weekly schedule, instead of a monthly schedule. This will result in less features each release, but will reduce the burden and complexity of large releases. With that said, this is what we have tentatively planned for the next release!

• Migrate the Rust toolchain to a WASM plugin.
• Investigate a new args/command line parser.
• Add Poetry support for the Python toolchain.

A while back we had internal discussions on whether to rework moonbase so that it could be self-hosted (on-premises), or adopt the Bazel Remote Execution API and utilize what the open source community has to offer. We ultimately decided with the latter, as it frees up resources on our end to focus on moon and proto, and also provides a better path forward for moon adoption.

If you are currently using moonbase, we suggest migrating to our new remote caching options. And if you have an active moonbase subscription, it will be cancelled within the week, and any partial billing for this month will be prorated.

With that said, we have some ideas brewing on how to bring this back in another form. Perhaps our own implementation of the Bazel Remote Execution API that can be self-hosted and deeply integrate with moon.

Alpha release of toolchain WASM plugins​

For over a year now, we've talked about supporting WASM-based toolchain plugins... but what's taking so long? Migrating from a "hard-coded in core" approach to a dynamic plugin approach was actually quite difficult, especially in Rust. It took us way longer than we expected.

With that said, we're excited to announce alpha support for WASM-based toolchain plugins. In this release, we have a working solution, but with partial support for the toolchain's tiered features. At this point in time, we provide full support for tier 0, major support for tier 1 excluding lockfile/manifest parsing, minor support for tier 2, no support for tier 3 (but will use proto's APIs), and support for non-tiered features, like moon init and moon docker.

If you're curious, the following WASM function APIs are now available:

• register_toolchain - Registers the toolchain and provide metadata for detection and other purposes.
• initialize_toolchain - Provides prompts to use during moon init to gather settings values.
• define_toolchain_config - Defines a configuration schema for use within JSON schemas.
• define_docker_metadata - Defines metadata related to docker commands.
• hash_task_contents - Injects content into the task hashing process.
• prune_docker - Custom operations to run during docker prune.
• scaffold_docker - Custom operations to run during docker scaffold.
• sync_project - Runs syncing operations per project (during the SyncProject action).
• sync_workspace - Runs syncing operations at the workspace root (during the SyncWorkspace action).

We know everyone is very excited about these plugins, so feel free to start using them today! However, since we don't have full tiered support, most of the advanced functionality related to running tasks is currently not supported (except for task hashing which is supported).

Additionally, we do not have documentation yet for these new APIs, but we do have the following resources to help you get started:

• Getting started with WASM plugins
• Example toolchain WASM plugins
• moon_pdk documentation (functions, macros, etc)
• moon_pdk_api documentation (structs, enums, etc)

TypeScript toolchain​

To verify that our WASM plugin implementation works correctly, we've migrated the TypeScript toolchain entirely to a WASM plugin, and it's no longer hard-coded in our Rust core! If you've configured typescript in .moon/toolchain.yml, then you'll automatically use the new plugin under the hood.

This is our first step in supporting plugins in core. We chose TypeScript as our 1st plugin because it was the simplest of all the toolchains, was primarily used for project syncing, and did not require all tiered APIs.

With that said, most of the code had to be rewritten when porting, but we tried to keep as much parity as possible. Please report an issues or differences you encounter. Additionally, because TypeScript is now a "true" toolchain, it will appear in the toolchains list for projects and tasks. This is required since it runs operations in the context of the plugin.

Because toolchain plugins are configured differently internally, and since TypeScript is now a plugin, the configuration syntax for disabling the TypeScript toolchain at the project-level has changed. While not a breaking change in this release, the old format will be removed in the future.

# Before
toolchain:
  typescript:
    disable: true

# After
toolchain:
  typescript: false # or null

Experimental moonx executable​

Based on a request from the community, we're introducing a new executable moonx, which is simply a shorthand for moon run .... In the future we will expand this with more "shorthand" functionality.

$ moonx app:build

Because of our current release process, the moonx executable is not packaged in the release (on GitHub), and is instead created the first time moon runs. Furthermore, moonx is not a binary executable, and is instead a shim (a Bash script on Unix, and a PowerShell (.ps1) script on Windows). In the future, this will become a true binary.

Dynamic JSON schemas​

With the initial support for toolchain plugins, the available configuration in .moon/toolchain.yml and moon.yml is no longer static, and is instead dynamic based on the enabled/configured toolchains. Because of this, the JSON schemas provided at moonrepo.dev and in the GitHub release are not accurate for some toolchain related settings, but accurate for everything else.

This may lead to a poor developer experience where your editor shows errors for unknown settings. To remedy this, we now generate dynamic schemas at .moon/cache/schemas with accurate settings. If you're editor supports the $schema property, you can update them like so:

$schema: './cache/schemas/toolchain.json'

$schema: '../.moon/cache/schemas/toolchain.json'

The VS Code YAML server does not support the $schema property, but there is a work around. However, that syntax is a bit unfortunate, so our official moon VS Code extension supports updating .vscode/settings. Simply open the command palette and select "moon: Append YAML schemas configuration to settings".

Other changes​

View the official release for a full list of changes.

• Added support for moon run ~:build, which will run the build task in the closest project (traversing upwards).
• Added $XDG_DATA_HOME support when detecting the moon store. Will be used if $MOON_HOME is not set, and will fallback to $HOME/.moon.
• Added elapsed/timing information to child processes and WASM calls within logs.
• Improved the handling of CTRL-C, CTRL-BREAK, and other signals on Windows.
• Updated moon init with toolchain plugin support.
• Updated toolchain.default in moon.yml to support a list of IDs.
• Updated file hashing (via git hash-object) to continously pipe stdin to avoid hanging processes.