feat: Any variables 2

[pd93]

This PR proposes an alternative approach to the Any Variables experiment which is fully compatible with Task v3 (Unlike the original proposal). Instead of removing the sh key and allowing native maps variables, we keep the sh key for dynamic variables and create a new key: map for specifying a map value. All other variable types (scalars & array) will be defined directly.

Keeping these subkeys lets us do some other fancy things too. For example, I've added the json and yaml keys which let you specify a JSON/YAML string to be converted to an object/array. This to similar to {{fromJson}}, but with the key difference that templating functions must always return a string whereas the json/yaml keys allow you to store the variable as a object/array type.

I've also added a ref subkey which adds support for passing a variable around and maintaining its type as opposed to passing it via the templating engine (which always results in a string). I think this is really important if we're going to support any type of variable as otherwise we will get so many issues asking how to pass types around.

I've thoroughly documented all of this functionality in more detail in the changes to the docs included in this PR. If reviewing, I think it's worth spinning them up locally with task docs:start and taking a look at the Any Variables page.

To enable this alternative experiment functionality, you can run set the TASK_X_ANY_VARIABLES flag to a value of 2. e.g. TASK_X_ANY_VARIABLES=2 go run ./cmd/task --dir ./testdata/vars/any2.

---

In addition to the above changes, this PR also includes:

• Another small fix for error reporting when fast compiling variables
• Support for experiment values to have multiple values (if we want to try different things)
• Fixed a bug where silent values were not deep copied in dependencies

[andreynering]

The idea of map: is good indeed.

For json and yaml, I'm not sure how useful that would be because users may be unlikely to paste a JSON or YAML string into a Taskfile, and reading from a file wouldn't be possible. I don't see a problem on keeping them, though.

ref: was a good idea as well!

I haven't tested in depth, but this looks fine for now as a experiment. We can still do adjustment if we decide before we release the experiment.

[pd93]

For json and yaml, I'm not sure how useful that would be because users may be unlikely to paste a JSON or YAML string into a Taskfile, and reading from a file wouldn't be possible. I don't see a problem on keeping them, though.

My main motivation for this was when you want to read multiple independent values from a JSON/YAML config (e.g. package.json) and you don't want to parse the JSON multiple times. Example below:

version: 3 tasks: foo: vars: FOOSTRING: sh: cat package.json # Creates a string e.g. '{"version": 1, "author": "Pete"}' cmds: - 'echo {{(fromJSON .FOOSTRING).version}}' # <-- Parse JSON string every time you want to access a value - 'echo {{(fromJSON .FOOSTRING).author}}'

After:

version: 3 tasks: foo: vars: FOOSTRING: sh: cat package.json # Creates a string e.g. '{"version": 1, "author": "Pete"}' FOO: json: "{{.FOOSTRING}}" # <-- JSON string parsed once cmds: - 'echo {{.FOO.version}}' # <-- Access values directly - 'echo {{.FOO.author}}'

I haven't tested in depth, but this looks fine for now as a experiment. We can still do adjustment if we decide before we release the experiment.

Yep, sounds good. I think I generally prefer this over the 1st iteration, but they can live alongside each other in the next release which is nice! Hopefully, we can gather some feedback on them.