website/blog/2025-07-24_moon-v1.39.mdx
This is a rather small release, but it does include some important changes to task inputs, and proto's integration.
<!--truncate-->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!
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 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'
:::info
Files and globs can still be configured using literal strings. The URI format can be used when customizing parameters!
:::
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'
As mentioned above, file and glob inputs now support parameters, which can be customized using URI and object formats. The following parameters are available:
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.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.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.
proto settingAdditionally, 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'
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 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.
| Layer | Description |
|---|---|
automation | An automated testing suite, like E2E, integration, or visual tests. |
application | An application of any kind. |
tool | An internal tool, CLI, one-off script, etc. |
library | A self-contained, shareable, and publishable set of code. |
scaffolding | Templates or generators for scaffolding. |
configuration | Configuration files or infrastructure. |
unknown | When not configured. |
Because of this rename, the following changes have been made:
type --> layer in moon.yml--type --> --layer in moon query projectsprojectType --> projectLayer for MQL$projectType --> $projectLayer for task tokensenforceProjectTypeRelationships --> enforceLayerRelationships in .moon/workspace.ymlView the official release for a full list of changes.
@moonrepo/cli npm package to no longer rely on postinstall scripts.With toolchains plugins being stabilized more, we'd like to focus on some other areas.
args)