Add support for customizing default Taskfile name via TASKFILE_DEFAULT_NAME environment variable

[mattn]

Many users prefer the .yaml extension over .yml for YAML files, as it's more explicit and commonly used in various tools and editors (e.g., for better syntax highlighting or consistency with other projects).

Currently, running task --init (or task -i) always creates a file named Taskfile.yml, which requires manual renaming for those who prefer Taskfile.yaml.

This PR introduces a new environment variable, TASKFILE_DEFAULT_NAME, that allows users to override the default filename generated by task --init.

• If TASKFILE_DEFAULT_NAME is set (e.g., TASKFILE_DEFAULT_NAME=Taskfile.yaml task --init), the init command will create the file with that exact name.
• The path handling remains the same: if a directory is provided, the custom name will be used inside it; otherwise, it creates the file in the current directory.
• If the variable is not set, behavior remains unchanged (defaults to Taskfile.yml).
• Validation ensures the provided name includes a supported extension (.yml or .yaml) to avoid confusion.

This change provides more flexibility for users without altering the default experience or affecting existing Taskfiles. It addresses community feedback around filename preferences (related to discussions in issues like #2008 and historical PRs for .yaml support) in a non-breaking way.

No changes to Taskfile detection/loading logic are made—only the init-generated filename is customizable.

[trulede]

@mattn would this be better as an item in the Task configuration file?
https://taskfile.dev/docs/reference/config#example-configuration

[mattn]

@trulede I think the configuration file extension should be .yaml not .yml, and I just want to enforce that.

[trulede]

@mattn that part is fine. The question is about the mechanism you have chosen, and if using the taskrc.yml configuration file might be a better option ... on the basis that envars are good for changing behaviour from run to run, but longer term adjustments fit better to the configuration file (taskrc.yml) approach.

[mattn]

Ah, so you're saying that instead of environment variables, you can reference a Taskfile.yaml specified via a key like taskfile-default-name in .taskrc.yml ? Right?

BTW, can we handle .taskrc.yaml ?

[trulede]

@mattn there has been a recent change to the operation of the init command option. You can do this:

task --init foo.yml
and that gets you the default taskfile with the requested name.

Perhaps you are happy with that? And there is nothing more to do with this PR?