feat: add option to declare an included Taskfile as flatten

[vmaerten]

It's one of the most upvoted feature ! So I gave it a try

Closes : #273

[ccoVeille]

Please accept my humble code review

[vmaerten]

Thanks a lot @ccoVeille for your review. I've done all fixes in one commit

[ccoVeille]

You are welcome

[andreynering]

Hey @vmaerten, thanks for working on this!

I noticed a bug: dir: is not being respected on includes: when flatten: true is given.

version: '3'

tasks:
  pwd:
    desc: Print working directory
    cmds:
      - pwd

includes:
  included:
    taskfile: ./TaskfileIncluded.yml
    dir: ./website
    flatten: true

With flatten: true, it prints the root directory instead of the specified one (dir: ./website in my example).

Also @pd93 mentioned here (#273 (comment)) that he has refactors in mind that could affect this work. Worth getting an opinion before merging.

[vmaerten]

Thank @andreynering for the review. I've forgot the AdvancedImport's part
It's now fixed and work as intended. Let me know if there are some usecase I've forgotten

[elocke]

Thank @andreynering for the review. I've forgot the AdvancedImport's part It's now fixed and work as intended. Let me know if there are some usecase I've forgotten

Awesome to see this feature in a PR, I've been eager to build something with this.

An usecase that I would benefit from, would be if I could specify override as an option to flatten. If set, the inheriting Taskfile's cmd would take precedence over the included files set to flatten. I could then provide sets of Task "templates" but my users could override specific cmds if they need to.

[vmaerten]

Thank @andreynering for the review. I've forgot the AdvancedImport's part It's now fixed and work as intended. Let me know if there are some usecase I've forgotten

Awesome to see this feature in a PR, I've been eager to build something with this.

An usecase that I would benefit from, would be if I could specify override as an option to flatten. If set, the inheriting Taskfile's cmd would take precedence over the included files set to flatten. I could then provide sets of Task "templates" but my users could override specific cmds if they need to.

I agree but for now, I would keep this feature as simple as possible
We can iterate through this after ffc

[pd93]

Also @pd93 mentioned here (#273 (comment)) that he has refactors in mind that could affect this work. Worth getting an opinion before merging.

I have some WIP code that removes the merging altogether. This feature will need to be reworked into that at some point. However, I've not had the time to work on it recently and I don't see any reason to delay this functionality given its popularity.

The PR seems well thought out and reimplementing it if merging is removed should be simple enough.

1 minor comment, but otherwise happy. Thanks for working on this @vmaerten! 🚀

[pd93]

This error is also returned when a task in a child taskfile conflicts with one in a parent taskfile (as opposed to two children taskfiles). We could improve the message to include those cases.

[vmaerten]

Do you think about CodeTaskNameConflict or another one ?
At first I used CodeTaskNameConflict but I found more readable to distinct both. That being said, it would make sense, so I'll give a try to adjust the message