moon v1.19 - Improvements to task dependencies, codegen, and more
In this release, we're introducing some long-awaited and requested improvements.
Configure args and env vars for task dependencies
This has been a long standing request from the community, and we're happy to finally deliver it.
Starting with v1.19, you can now configure optional command line arguments and environment variables
for each task deps
entry. These values will be passed to the task
when it is executed.
Here's an example of what both patterns look like. The target
field is required when configuring
an object, and both the args
and env
fields can be mixed and matched.
tasks:
build:
command: 'vite build'
deps:
# Just a target
- '^:build'
# With args (string)
- target: '^:build'
args: '--mode production'
# With env vars
- target: '^:build'
env:
NODE_ENV: 'production'
# With args (array) and env vars
- target: '^:build'
args:
- '--mode'
- 'production'
env:
NODE_ENV: 'production'
When using this functionality, there are a few things to understand about its implementation, and how it affects the rest of the pipeline:
- When extending or inheriting a task and a merger is required, and this task has a dependency with
a colliding target, the
args
andenv
fields will NOT be deeply merged. Whichever task is inherited last will have itsdeps
used. - When multiple dependencies of the same target are ran in the action pipeline, but with differing args or env vars, only 1 will run at a time. We try to avoid running them in parallel to avoid collisions and corrupting outputs.
- Arguments and environment variables do NOT support tokens.
- If dependencies all write to the same output, cleaning the output is your responsibility, not moon's.
Codegen improvements
Code generation is one of moon's oldest features, and hasn't been improved in quite a while. We felt the time was right to give it a little love.
Extend other templates
This has been a request for over a year, and we
finally found the time to put it on the roadmap. Starting with this release, you can now extend
other templates using the extends
setting in
template.yml
, which supports a list of template names.
Templates will be recursively extended from top to bottom, and all files and variables will be inherited and merged at the top-level.
title: 'npm package'
extends: ['node-common']
Configure a default destination
When you call moon generate
you must provide a destination directory
for the generated files, or we'll prompt you to provide one. But what if you wanted to standardize
the destination? For example, a package scaffolding template should go to packages/
. This is now
possible with the optional destination
setting in
template.yml
.
If no destination is provided to moon generate
, we'll use this default destination.
title: 'npm package'
destination: 'packages/[name | kebab_case]'
variables:
name:
type: 'string'
default: ''
required: true
prompt: 'Package name?'
For better interoperability, this setting can also reference variables using [var]
syntax, and can
also use Tera filters. Learn more about this in the
code generation documentation.
Resolved long-standing experiments
moon has a concept of experiments, where certain features are gated behind a flag. This allows us to support new and old functionality in parallel, and also allow users to gradually upgrade when encountering a breaking change. For many months now, we've had 2 experiments running, and have decided on a path forward.
The first is experiments.interweavedTaskInheritance
, which would inherit global and local tasks in
order, interweaved within each other. The old implementation would inherit global first, then local
second, distinctly grouping them. Since this experiment was introduced, we have not received a
single bug report or issue. This is a good sign that the new behavior is working as expected, and as
such, have decided to move forward with this experiment and make it the new implementation. The
old implementation has been removed entirely.
The second is experiments.taskOutputBoundaries
, which was rather controversial when introduced.
This experiment would trigger an error anytime a task's outputs
overlapped within
another task's outputs
. The reason for this change, is that multiple tasks writing to
the same output location could "corrupt" the expected state, and trigger unexpected results when
hydrating from the cache. However in practice, this restriction has caused more headache and
introduced a steeper learning curve then expected. It also caused problems with
tasks that extend from another, resulting in the same outputs being
used. Because of this, we've decided to not move forward with this experiment, and allow
whatever task outputs you wish (we trust you're smart enough to not shoot yourself in the foot).
Other changes
View the official release for a full list of changes.
- Updated proto to v0.26 (from v0.25), which includes a new shims implementation.
- Updated VS Code extension to support multiple VS Code workspace folders.