task
task copied to clipboard
go-task
Introduce mono-mode for running single tasks
Describe in detail what feature do you want to see in Task.
I'd like to be able to setup a Taskfile such that the usage of -- to pass CLI args can be ommited. I'm experimenting with Taskfile in an agency setting, where we have a wide range of projects with varying tech stacks and framework versions (for older projects).
Taskfile looks like a great way to unify the interface across projects.
In this case Taskfile is not intended to be used to run multiple tasks quickly, but more as a shell that dishes the project-specific version of the command(s). Similar to how laravel/sail wraps docker-compose. There are a lot of features in Taskfile, such as the predicates and status, that are still very relevant for this use-case. Creating a shell script to wrap the tooling would mean we'd miss out on all of the features just because we don't want to run one command at a time, and are able to commit to that at the project level.
What I'm looking for is to bypass the entire feature to run each commandline word prior to -- as a task, but only to use the first and pass all other arguments on as tasks. A "mono-mode" for Taskfile if you will. This would make the existing behavior something like "multi-mode".
The key benefit is reducing friction in using single tools through Taskfile, inserting -- is counter intuitive especially when taskfile wraps them (e.g. yarn). Having to insert -- means the cognitive load is increased when using yarn (whether through Taskfile or not) as you have to think whether to use -- after yarn or not. Creating every sub-command of yarn as a task (like yarn:install) is not feasible as this postpones the -- issue one argument to the right.
There is a valid case for Taskfile to not parse as many arguments as runnable tasks as possible, however those don't mix well for obvious reasons and thus is a top-level choice you make early on in designing your setup. This feature doesn't change the way Taskfile has been used but provides a tradeoff that can be opted into: friction on starting multiple tasks at once -vs- friction in passing arguments to a specific tasks.
The idea is something like this
- A top-level config option to activate mono-mode
- Mono-mode only affects cli argument parsing, does not change behavior between tasks.
- In mono mode the first argument (that doesn't start with
--) implicitly has--as the next argument, unless there are no other arguments following it.
Since it is a mode switch, this is not a breaking change and can be offered in a minor version update.
Considerations
- Force mono-mode with
--mono - Force multi-mode with
--multi - Deprecate parsing switches (arguments prefixed with
--) after a taskname is specified (e.g.task build --helpdoesn't trigger--helpfor task) - In mono mode alternate methods of entering multiple tasks could use comma separated task names
- Supporting this at task-level may lead to confusing behavior, for the need to run multiple tasks they could also be handed as a single argument joined with
,.
Examples
What the top-level config option could look like. Since there already are top-level keys related to the command-line behavior (output) it is reasonable to introduce a naked top-level key to host the option.
Since I mentioned output, perhaps input would be a good key to store the setting under. Should there be more specific options in the future then this could be expanded later on by making input an object.
# Taskfile.yml
version: '3'
input: 'mono'
input: 'multi'
# Alternate terms for the modes, more closely related to the task count
input: 'single'
input: 'many'
# Variation with boolean toggle on the mono-ness of cli parsing
input:
mono: true
Command-line
# Switches --multi and --mono are to indicate task argument parsing in the respective mode
# NodeJS yarn
task --multi yarn -- build
task --mono yarn build
task --multi yarn docker -- build
task --mono yarn,docker build
# Laravel's artisan
task --multi artisan -- make:controller
task --mono artisan make:controller
I'm able to contribute if such a feature would be accepted in the project.
EDIT: The relevant code for the change is cmd/task/task.go :: getArgs. But introducing a separate variation of the function will likely be better (similar to ParseV2 and ParseV3 for reading vars).
Hi @maritaria,
I'm not sure what to think about this feature request. I feel that this could be a feature that very few people would use. And we already have -- for this purpose, so it's already possible to delegate args, just with an extra argument.
I think I can keep this issue open to collect 👍s and opinions from other users potentially interested into this feature. If it has enough interest, we can decide to implement in the future.
I would use this, i use taskfile mainly to shorten commands, and the extra -- gets annoying after the 1000th time
You could even write a bash function that does what you desire:
t () {
local tname="${1}"
shift
task "${tname}" -- "$@"
}
That sounds like a workable solution for individual use. For my intention I was asking for first party support of using taskfile as a project tooling wrapper. Having to modify your own shell to make the tooling egronomic does not sound palettable to me to base project setup on for a team.
On Mon, May 30, 2022, 22:57 Wes McNamee @.***> wrote:
You could even write a bash function that does what you desire:
t () { local tname="${1}" shift task "${tname}" -- "$@" }
— Reply to this email directly, view it on GitHub https://github.com/go-task/task/issues/662#issuecomment-1141472456, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJ657N64PRZIMCUUASD66TVMUTSNANCNFSM5MXYUQXQ . You are receiving this because you were mentioned.Message ID: @.***>
What I don't understand actually is how --mono is better than --. Usually typing less is better.
What I don't understand actually is how
--monois better than--. Usually typing less is better.
I noted it for completeness. The most likely case where you'd use this is in a CI script, those tend to be more verbose in program switches.