feat: support custom flavor names in flutter_app template

[marcossevilla]

Description

Add support for customizable flavor names in the very_good_core template, instead of the hardcoded default names (development, staging, production).

Proposed API: a --flavors flag accepting a comma-separated list, e.g.:

very_good create flutter_app my_app --flavors="free,pro,dev"

This would allow any number of flavors with any names, and an empty string could optionally disable flavors altogether.

This issue was first created in Very Good CLI: #680

Requirements

• All CI/CD checks are passing.
• There is no drop in the test coverage percentage.

Additional Context

No response

[unicoderbot]

Great, I will work on a PR and push it soon.

• Preparing environment
  • Cloning repository
  • Setting up dev environment
• Working on changes
• Reviewing changes
• Opening pull request

I've opened a draft pull request: #568

The coding agent reported the work is incomplete: Implemented custom flavor names for the fixed three-flavor structure; arbitrary flavor count and disabling flavors were not done due to Xcode pbxproj UUID constraints.

[marcossevilla]

update on this issue: we can tackle this with a few approaches, some of them are breaking changes to how the template uses flavors, so please reply with your preferred approach and rationale behind

1. implement flavors like feat(flutter_app): add custom flavors #580, a dynamic list that always sets a default production (no suffixes) version if flavors is empty. this is breaking since it would go flavor-less if none are provided
2. implement flavors as a dynamic list but treat empty list as default current behavior: empty list == [dev,stg,prod]. this would lose the empty list == no flavors (minimal app like feat: add minimal Flutter app template #466 requests) but we could introduce a minimal template in a follow-up PR, which would add more maintenance to the overall repo but maybe enable easily stripping features from very_good_core
3. implement a fixed list of flavors that you can enable/disable, which would be a rather limited approach since the whole purpose of this is to have a dynamic, open-ended flavor list
4. Add a use_flavors boolean var (default true) whose gate lives in feat(flutter_app): add custom flavors #580 resolveFlavors: false → plain app ignoring the list, true → use the provided list or fall back to development/staging/production when none given.

please comment your thoughts! 🙏

[brianegan]

Do we know who our most common users of these templates are? Is it mostly VGV folks? If so, I'd say option 2 makes the most sense if I understand it correctly, to keep the mental model the same as it is now if you don't provide an explicit override.

[jorgecoca]

Agree with @brianegan, option 2 given where we are seems the most reasonable approach. I would not consider options 3 and 4 as a viable option, and option 1 would have been something I'd consider if we did not have already flavor support.

[taaha161]

I like the idea of disabling flavors altogther because i have had use cases where they were just redundant boiler plate code. To that end, i would go for option 4.

With the bool defaulted to true, consumers simply dont have to do anything new (except adding new flavor names to the list) while the consumers that would like to opt out of flavor can pass the extra flag.

[omartinma]

I see pros/cons in all solutions:

1. The problem I see with option 1 is that it goes flavorless by default, which could be a bit counterintuitive, and it would not benefit users who are used to those default environments running our CLI. Would we need to input all flavors we need each time, or could we have something pre-defined?
2. Not sure how much overhead there will be to have a dedicated minimal template if we want to support the case of no-flavors with this approach.
3. This is too limitative imo
4. The main issue I see with this approach is the need to maintain 2 flags for the same purpose.

With that said, I'm leaning between option 1 and 2.

[marcossevilla]

I'm personally leaning towards 1 since it makes less impact in terms of code addition and refactoring, which seems a better way to go for this instead of refactoring more for the sake of keeping the default behavior. also enables the template to stay simple by default and add flavors as an opt-in feature, keeping flavors extensible and dynamic, which is the whole point

option 2 would involve adding a new template that could be used for demos, otherwise it would be pretty much the same as flutter create so I don't think there's a necessity for that.

option 3 is very closed and defeats the purpose of the issue.

option 4 is adding unnecessary complexity to maintain the current behavior.

I think cons are very self explanatory, so I didn't get into them a lot 😄