conflict with task parsing arguments required for go list command

[aperseke]

I was creating a task to build Golang gRPC source files from proto files using the protoc compiler and I had a conflict with Task parsing an argument that needs to be used for a go list command. I had to use a very ugly way to declare my argument to avoid Task to parse it. Here's an except of the Task file:

  proto:
    summary:
      Use protoc to build all protofiles into GoLang source code
    vars:
      PACKAGE_DIR:
        # couldn't find a better way to avoid 'task' to parse {{.Dir}} variable reference
        sh: echo '{''{''.Dir''}''}'
      COMMONDEF:
        sh: go list -f '{{.PACKAGE_DIR}}' -m github.com/avenuesec/common
      MOVFINDEF:
        sh: go list -f '{{.PACKAGE_DIR}}' -m github.com/avenuesec/movfin-contracts

In the task above, both go list commands expect to receive a -f '{{.Dir}}' which will be parsed by Task if I don't have a way to indicate that I don't want it to parse the {{.Dir}} string. This is the reason I created the workaround variable PACKAGE_DIR to declare a string that is not going to be parsed.

My question is, does Task have a way like bash, to declare a string delimited by single quotes and that are not parsed, and only parses strings delimited by double quotes ?
Is there a better way to solve my workaround in line 7 of the code above ?

[ghostsquad]

try

'{{`{{.DIR}}`}}'

Task does not have a way to declare a string as something not to parse. Quoting won't make a difference, as this it's "just yaml".

Might be a good feature request though.

[aperseke]

Overall, your suggestion works a lot better than mine, so thanks for the help. This escaped way to avoid Task to parse the {{.Dir}} works fine, but I still think it should be a nice idea to have a feature to do this in a more straightforward way. I also didn't found this information you gave me in Task documentation web page (https://taskfile.dev/) so, it would be helpful for others to add this information there. What do you think ?

[ghostsquad]

What should likely be in the documentation is which fields are parsed as a text template by the engine, and how ordering works.

Also, something to note, if you do this as a var passed to another task, it will be parsed twice, which is also unfortunate.