moon
moon copied to clipboard
RFC: Combine `command` and `args` fields within tasks.
When I first start building moon, I separated the command and args settings for the following reasons:
- The
commandis used heavily for lookups and child process execution. Having a simple string was easiest. - The
argswere initially a list of strings (supporting a string itself was added later), as iterating through and processing them was also easiest.
But now that moon is rather stable, and I have personally started using it on external projects (dogfooding, woo), as well as other developers, it's become quite apparent that having these be separate settings is rather annoying. Because of this, I'm proposing merging command and args into a single setting, command, which will include the command/binary name and all args.
This new setting can be written with a string or a list of strings, but the binary itself must be the first item.
# Before
tasks:
clean:
command: 'rm'
args: '-rf /'
type: 'system'
build:
command: 'webpack'
args:
- 'build'
- '--mode'
- 'production'
options:
cache: true
# After
tasks:
clean:
command: 'rm -rf /'
type: 'system'
build:
command:
- 'webpack'
- 'build'
- '--mode'
- 'production'
options:
cache: true
What about task merging?
When inheriting tasks from the global workspace, tasks of the same name are merged (https://moonrepo.dev/docs/concepts/task#merge-strategies). How will this be affected?
Internally, we have TaskConfig and Task structs. The combining of command/args into a new field will only occur in TaskConfig, while the separation of command/args will still persist for Task. And since the merging happens in the Task struct, this will continue to work without any changes.
What about token substitution?
Tokens, like merging (above), happen on the Task struct, and should continue to work without any changes.
Potential issues
- Values placed before the "command to run" will cause issues. If anything, it will just crash the process and force the developer to remedy the issue.