"default" task from included taskfile should be executed when no task name is provided

[ankushg]

I really like the behavior that

If you omit a task name, “default” will be assumed.

Unfortunately, it doen't seem to play well with included taskfiles.

For example, if I have a root Taskfile.yml with the following contents:

version: '3'

includes:
  main: .taskfiles/main.yml

and .taskfiles/main.yml:

version: '3'

tasks:
  default:
    - task: build
    - task: assets

  build:
    cmds:
      - go build -v -i main.go

  assets:
    cmds:
      - minify -o public/style.css src/css

I would like to run something like task main and have it automatically run task main:default

Currently though, I need to explicitly run task main:default

[tylermmorton]

Hi @ankushg! Thank you for the report.

This does seem like the intended behavior because of the way we merge included taskfiles into the parent. I think an additional step could be added to check for the existence of default in an included taskfile and 'flatten' it, for lack of a better term. This might be a breaking change that requires a version check, though.

Just after this step:

task/taskfile/read/taskfile.go

Line 113 in 2373743

if err = taskfile.Merge(t, includedTaskfile, namespace); err != nil {

if(includedTaskfile.Tasks["default"] != nil) {
	t.Tasks[namespace] = includedTaskfile.Tasks["default"]
}

I'm interested in how @kerma and @andreynering feel about this. This could be a good first issue for anyone looking to contribute to the project. We would need additional unit tests to cover the behavior.

For now a good workaround could be to define task main in your Taskfile.yml:

version: '3'

includes:
  main: .taskfiles/main.yml

tasks:
  main:
    cmds:
      - task: main:default

[andreynering]

Hi @ankushg,

I had the impression that this was proposed before, but I couldn't find the related issue in a quick search.

This probably makes sense, but we need to take possible conflicts into account. For example: it's possible that both a foo and a foo:default tasks exists. In this case, foo probably should be preferred instead of foo:default.

[ghostsquad]

I kind of see namespaces in task as subcommands, and maybe that makes sense for how they should be treated (more or less). There's currently no enforcement of this concept though (afaik), such that you can make a task at the root called main:default that essentially "shadows" the included main:default task.

I like the concept though that namespaces are strictly enforced, and "shadowing" is either prohibited, or there's a warning that a task is shadowing an include. Allowing you to call task main which maps to the default task in the main namespace. Thusly, if you have a main namespace, also having a main task in the root Taskfile would be discouraged. (this is similar to how packages are imported in Go, and how a variable can shadow a package).

I like to look at upstream code/binaries/packages not as a way to "follow the crowd", but as a way to help "preload" intent with what a user may already be used to or expect. So how does Make handle this? (opinion: quite elegantly)

https://www.gnu.org/software/make/manual/html_node/Goals.html
https://stackoverflow.com/questions/17834582/run-make-in-each-subdirectory

[ghostsquad]

linking this to #694 to track for v4

[andreynering]

Implemented on #661.

[aweseeker]

Hi Team,

Can't we run all task defined Taskfile.yml, because if we have n number of tasks do we need to manually name each task in cmd line ''task task1 task2...'', can't we have some option like --all to run all tasks.

Thanks.

[pd93]

@aweseeker see #360