feat: simplify relying on defaults when using `mason make` in CI

[Alejandro Santiago]

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:

mason make my_brick --config-path config.json --my-option "my_value"

Achieves different results depending on the config.json content.

Given the following config.json:

{
  "my-option": "another_value"
}

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:

vars:
  my-title:
    type: string
    description: The title of the project
    default: my_title
    prompt: What is the tile of the project?
  package-manager:
    type: enum
    values: ["none", "pub", "onepub"]
    description: Determines what package-manager your project will rely on.
    prompt: What package manager would you like to use?

To generate and verify the output of a project with all the different package managers you would require three configuration files:

/// config1.json
{
  "my-title": "my_title",
  "package-manager": "none",
}

/// config2.json
{
  "my-title": "my_title",
  "package-manager": "pub",
}

/// config3.json
{
  "my-title": "my_title",
  "package-manager": "onepub",
}

Having multiple JSON configuration files duplicate the default values, in this case "my_title".

Another options are:

• Having the JSON configuration files only specify those non-default values and run the command with default values provide by numerous command arguments.
• Completely ditching the configuration file and only rely on specifying all numerous arguments per command.

All these approaches harden the maintainability and require duplication of those default values, either in multiple JSON config files or per command.

Proposed behaviour

• Add an optional argument to mason make where all prompts are ignored and the default values specified within the brick.yaml are used.
• Let those command arguments being specified in mason make override those specified in a configuration file. As in Cookiecuttter:

It reads a settings file and prompts the user interactively whether or not to change the settings.

• Move prompting to the programming language as in Yeoman generators

[Felix Angelov]

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:

1. Check if the variable is specified via command-line
   a. If yes, use the value from the command-line args
2. Check if there is a config containing a value for that variable
   a. If yes, use the value from the config
3. Prompt for the value

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!

[Alejandro Santiago]

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 🙌