Autodiscovery/import of Taskfiles

[hanoii]

Description

I work on different projects that sometimes use common libraries or helpers. It might be very good if one can ship Taskfiles that are autodiscovered. This could be default taskfiles or a custom filename like Taskfiles.autodiscover.yaml. This can be made an opt-in setting on the main Taskfile including maybe discovery paths that you whitelist for autodiscovery.

[vmaerten]

By autodiscovered, do you mean automatically included?

This raises a few questions: what should the namespace be for those Taskfiles? Should they be flattened or namespaced ?

I’ll mark this as a feature request and leave it open for now to see whether other users are interested in it as well.

[hanoii]

Bear in mind that I am not fully familiar with all of the configuration schema, just started to try this tool to move away from https://github.com/ahoy-cli/ahoy, a tool I've used for many years but I really think is a superb replacement.

So, I have been going back and forth (AI assisted) with an idea around this feature, and thinking good schema and simple principles.. Also note that I am only pasting what I liked and feel it robust. Tried not to over complicate things and make things opt-in

---

Autodiscovery is opt-in via explicit glob patterns in the root Taskfile.yaml. Discovered files require no modification — any existing Taskfile.yaml can be autodiscovered. Files are
passive; the discovery context owns the configuration.

Schema

Root Taskfile.yaml:

autodiscover:
  rules:
    - pattern: '.ddev/**/Taskfile.autodiscover.yaml'
      namespace: ddev        # optional: override namespace
      optional: true         # same options as includes
    - pattern: '../shared/Taskfile.yaml'
      namespace: shared

Discovered file (optional autodiscover block):

autodiscover:
  self:
    namespace: docs          # preferred namespace; parent rule wins if both set
  rules:                     # recursive: this file can discover further files
    - pattern: './**/Taskfile.autodiscover.yaml'

Namespace resolution

Priority order:

1. Parent rule namespace (explicit override — wins always)
2. self.namespace in the discovered file (declared preference)
3. Neither → flatten (tasks merged into caller's namespace, zero-config default)

This means any unmodified Taskfile.yaml from another project can be autodiscovered with no changes — the parent rule supplies the namespace:

autodiscover:
  rules:
    - pattern: '../project-a/Taskfile.yaml'
      namespace: project-a   # project-a needs no modification

Rules are an ordered list

Rules must be a list, not a map, because order determines precedence: the first rule that matches a file wins for that file's options. This allows specific overrides before a catch-all:

autodiscover:
  rules:
    - pattern: '.ddev/web/Taskfile.autodiscover.yaml'
      namespace: docs-web    # specific override
    - pattern: '.ddev/db/Taskfile.autodiscover.yaml'
      namespace: docs-db     # specific override
    - pattern: '.ddev/**/Taskfile.autodiscover.yaml'
      # catch-all: remaining files use self.namespace or flatten

Conflict handling

Namespace collision (two files resolve to same namespace) → hard error with actionable hint:

error: namespace collision "docs"
  - .ddev/web/Taskfile.autodiscover.yaml
  - .ddev/db/Taskfile.autodiscover.yaml
hint: add specific rules before the catch-all to resolve:
  autodiscover:
    rules:
      - pattern: '.ddev/web/Taskfile.autodiscover.yaml'
        namespace: docs-web
      - pattern: '.ddev/db/Taskfile.autodiscover.yaml'
        namespace: docs-db
      - pattern: '.ddev/**/Taskfile.autodiscover.yaml'

Task name collision on flatten → existing task manager behavior applies, no new logic needed.

Deduplication and cycles

• Files are deduplicated by resolved absolute path — a file matched by multiple rules (specific + catch-all) is loaded once using the first matching rule's options.
• Cycles in recursive rules (A discovers B, B discovers A) → hard error listing the cycle.

Rules inherit existing includes options

To avoid a feature gap, rule entries accept the same options as includes:

autodiscover:
  rules:
    - pattern: '.ddev/**/Taskfile.autodiscover.yaml'
      namespace: ddev
      optional: true
      internal: false
      vars:
        ENV: staging

Summary of design principles

• Opt-in: no magic filesystem scanning; root Taskfile explicitly whitelists patterns
• Zero-config default: flatten means discovery works without touching discovered files
• Namespace is opt-in: declare it when you need isolation, omit it for flat merge
• No structural difference between root and discovered files: same schema, same rules, fully recursive
• Fail loud: collisions are hard errors with actionable hints, never silent

[trulede]

@hanoii you can do something like this, for a lot less effort:

find . -name "Taskfile.yml" -not -path "./Taskfile.yml" | while read f; do yq eval ".imports += [{taskfile: \"$f\", namespace: \"$(dirname "$f" | xargs basename)\"}]" -i Taskfile.yml; done

Then define a task in your Taskfile.yml to "self update", however you wish.

[hanoii]

Thanks. I figured that. The request is not to make it easier for me. The request is for being able to ship something without requiring everyone else to self update. This approach could be made globally opted in as well.