Improve scaffold feature's default parameter type for stencil file

[haeseoklee]

Resolves #5462

Short description 📝

The scaffold template's optional parameter is improved to support a variety of types (including Dictionary, Int..) for stencil file. The expected effect is that stencil's renderTemplate method will be able to receive a custom context.
Additionally, after being able to pass various types of parameters in the source code, users can construct a more expressive template file.

After

let attribute: Template.Attribute = .optional("environment", default: "string value")
// or
let attribute: Template.Attribute = .optional("environment", default: ["key": "value", "key2": "value2"])
// or
let attribute: Template.Attribute = .optional("environment", default: 99999)
// or
let attribute: Template.Attribute = .optional("environment", default: true)

How to test the changes locally 🧐

Include a set of steps for the reviewer to test the changes locally (see the documentation for reference).

Contributor checklist ✅

• The code has been linted using run mise run lint:fix
• The change is tested via unit testing or acceptance testing, or both
• The title of the PR is formulated in a way that is usable as a changelog entry
• In case the PR introduces changes that affect users, the documentation has been updated

Reviewer checklist ✅

• The code architecture and patterns are consistent with the rest of the codebase
• Reviewer has checked that, if needed, the PR includes the label changelog:added, changelog:fixed, or changelog:changed, and the title is usable as a changelog entry

[fortmarek]

Thanks a lot for this PR 👏

Might be also worth updating one of the scaffold acceptance tests to test this end-to-end.

The test failure looks unrelated and should be fixed by updating the branch.

[haeseoklee]

@danyf90 @fortmarek
Thank you for the review.

While writing additional tests, a critical issue was discovered. Unlike Template.Attribute in TuistGraph, Template.Attribute in ProjectDescription must conform to the Codable protocol. Since AnyHashable cannot conform to Codable, we need to come up with another idea.

One idea that comes to mind is to provide users with an explicit interface. We can define possible types as an enum and use associated values to store the desired values.

For example, .optional("name", default: "platform") can be represented as follows: .optional("name", default: .string("platform")) .

In the same context, various types such as bool, integer, dictionary, etc., are also possible.

[haeseoklee]

If the interface changes, it could be a breaking change.

[danieleformichelli]

I think we need something like PList.Value:

tuist/Sources/ProjectDescription/Plist.swift

Line 8 in 3771c26

public indirect enum Value: Codable, Equatable {

[haeseoklee]

@danyf90
I will give it a try by defining an enum.

[pepicrft]

@haeseoklee do you mind rebasing from the latest changes in main? We merged a branch with significant breaking changes and the work here is a bit behind. Let me know if you have questions when doing the rebase.

[haeseoklee]

@pepicrft Thank you, I will try to do the rebase

[haeseoklee]

@danyf90

e4e69d0

I reverted this commit. There is an issue with TuistGraph.Template.Value not passing the tests. We can resolve this problem, but it seems overly complex.

[danieleformichelli]

Thank you, please avoid force pushing on the branch. We squash-commit anyway so it just makes review harder 🙏

[pepicrft]

The failing tests are unrelated to your changes and have already been fixed in main. I'll go ahead with the merge.

[haeseoklee]

@danyf90
I will refrain from frequent rebasing in the future.
It was my first contribution, and I received a lot of help. Thank you very much.

[danieleformichelli]

@danyf90

I will refrain from frequent rebasing in the future.

It was my first contribution, and I received a lot of help. Thank you very much.

No worries! Thanks a lot for your contribution 🔥