Let's say you have a very simple recipe that provides a role called super_editor. The recipe doesn't bother adding any permissions to super_editor; it just provides the role in its config directory, as config/user.role.super_editor.yml.
You apply this recipe once, and the role is added to your site. Cool! You go about your day and add more permissions to the super editor role. Everything's copacetic.
A week later, you try to apply another recipe, that happens to itself depend on the super_editor recipe. You hit this nasty-looking error message:
The configuration 'user.role.super_editor' exists already and does not match the recipe's configuration
This is caused because the recipe system is overzealous about comparing the config that the recipe ships (this includes config it imports from modules) against your site's active config. It requires that they be absolutely identical in every detail, or it throws this error at your face and ruins your day.
Until #3478332: Add a way to prevent recipes' imported config from being compared too strictly to active config, that is. As of this issue, recipes can opt out of this strict comparison by adding this in the config section of recipe.yml:
config:
strict: false
import: ... # stuff here
actions: ... # more stuff! whee!
This flag, if it's there, will cause the recipe system to respect existing config, instead of trying to compare it against what the recipe wants to ship. So to use our example: if the super_editor recipe has strict: false, the recipe system will allow it to be applied even if the super_editor role already exists, no matter what it looks like. The existing role will simply be ignored by the recipe.
That said, in certain situations, recipes might want the strict behavior. The recipe can set strict: true to keep doing things the old way.
A recipe can choose to opt only certain config into the strict checking. Let's say you have a recipe like this:
config:
import:
user:
- user.role.authenticated
metatag: '*'
strict:
- metatag.metatag_defaults.global
This will treat metatag.metatag_defaults.global strictly, and user.role.authenticated leniently. When this recipe is applied, if the authenticated role already exists, the recipe system will ignore it. But if metatag.metatag_defaults.global exists in your site, then it must be identical to what Metatag provides out of the box, or the recipe will fail.
Long story short: strict: false is probably safe for most use cases, so if in doubt, use that. But if your recipe is strongly opinionated about its config -- or even just a subset of it -- you have a tool to enforce that.
