Validate that extension listed in the config.import section of recipe.yml has option to bypass all config of that extension

I'm not at all convinced that we need to validate that every module is listed here. I think that not being listed here means that the module's simple config is installed (as it is required) and nothing more is okay.

I do think that it is worth discussing changing the name from config to config_entities as that's what this is about.

I'm not at all convinced that we need to validate that every module is listed here. I think that not being listed here means that the module's simple config is installed (as it is required) and nothing more is okay.

I do think that it is worth discussing changing the name from config to config_entities as that's what this is about.

Note: the scope of this issue first came up in #3413824: Warn Recipe developers if a module being installed does not have a corresponding config import declaration → .

I do think that it is worth discussing changing the name from config to config_entities as that's what this is about.

+1! This would go a long way.

But … I'd still like to try to convince you that we should require config.import for every installed module:

1. installing a module in Drupal always installs default config — both simple config and config entities
2. … except in Recipes, only simple config is installed by default
3. unless you specify import: { some_module: '*' }. This is not obvious.

It's both for discoverability and explicitness/declarativeness that IMHO config.import.<module name> should be present for every installed module. Because then the validation can inform the Recipe author that they should say which (if any) config entities of the installed module should be installed.

But … I'd still like to try to convince you that we should require config.import for every installed module

In the last 6 months I think we have educated and documented why recipes don't behave like a regular module install, for recipe author specificity and idempotency.

I do think that it is worth discussing changing the name from config to config_entities as that's what this is about.

Do we want to change config to config_entities to add further clarity?