Open alestiago opened 6 months ago
Hey @alestiago 👋 Thanks for opening an issue!
This is a bug imo and should be easy to fix. Imo we should ensure the logic for prompting is as follows:
Would the above flow address the issue?
Move prompting to the programming language as in Yeoman generators
Isn't this already the case with hooks? You can write complex prompting logic in Dart using a pre_gen hook. Are you suggesting a separate hook specifically for prompting? Thanks!
If you believe this is a bug, solving it using the priority list you specified sounds great to me! In essence we would:
Let those command arguments being specified in mason make override those specified in a configuration file.
Sounds good to me!
Isn't this already the case with hooks? You can write complex prompting logic in Dart using a pre_gen hook. Are you suggesting a separate hook specifically for prompting? Thanks!
I'm glad you picked on that point, I think we can move this conversation to #1251. I'll try providing a document with any suggestions that apply there 🙌
Description
The
mason make
command config file overrides those values given via argument. This makes it difficult to operate within CI, since it is cumbersome to define defaults (read below for a better understanding of the problem).Current behaviour
Currently, doing:
Achieves different results depending on the
config.json
content.Given the following
config.json
:The
mason make
command will completely ignore the value "my_value" provided via argument.However, given the following
config.json
:The
mason make
command will use the value "my_value" provided via argument.In essence, the configuration files overrides any argument specified if an entry is present in the
config.json
file.Current limitations
As part of your CI (for example GitHub), you might want to generate the template and ensure the generated content is valid by performing some checks on the output.
In CI, you will require to specify values for all the variables either by config file or arguments to avoid being prompted since those prompts will not receive an input from the CI. Given this, if you want to have "default" values you can't rely on those that would be utilised by the prompt if empty (defined in the
brick.yaml
).Instead, you may want to define the default values in a
config.json
. This approach works fine, until you would like to generate multiple variantes of the same template by only altering some of those variables. For example, consider:To generate and verify the output of a project with all the different package managers you would require three configuration files:
Having multiple JSON configuration files duplicate the default values, in this case "my_title".
Another options are:
All these approaches harden the maintainability and require duplication of those default values, either in multiple JSON config files or per command.
Proposed behaviour
mason make
where all prompts are ignored and the default values specified within thebrick.yaml
are used.mason make
override those specified in a configuration file. As in Cookiecuttter: