Consider making recipes' comparison with existing config lenient by default

Blocker's in!

There are more cases that need to be handled than just strict or not strict. When applying a recipe, I can imagine the following possible courses of action if the recipe has a config file that contains different config from what is installed in the site:

Perhaps this should be controlled by an on-conflict key in the YML file. This would echo how some SQL databases, such as Postgres, have an ON CONFLICT clause to INSERT which takes values DO NOTHING and DO UPDATE.

I’m not sure replace and update are going to fly as you describe.

Replace would be the same as the concept of “force apply” — i.e., “import the recipe’s version of the config even if it already exists”. We intend to support that in another issue but it will not likely be something that is selective. Either the entire recipe is force-applied or it isn’t.

Update, on the other hand, sounds like allowing recipes to ship partial config, which is probably a non-starter. That’s just plain not what recipes are designed to do. Recipes that want to tweak parts of a config entity should use config actions; that’s what they’re there for.

That just leaves ignore and error, which we have implemented. We just call it strict and lenient. :)

Does that make sense?

Update can be achieved with config actions, but that means changing the format of the config. Files for the config directory can be generated using Drush config export. I am not aware of any automated way of converting those into the format needed for inclusion in a YML file as an action.

What if I want a recipe that installs and configures a module and adds a button to the CKEditor toolbar? I don't want that to remove buttons that are already there.

I'm imagining that a file used for Update would always be a complete config file so installing it wouldn't create an invalid config object.

I don't think "strict" and "lenient" are clear in their meaning.

Generally speaking, if a recipe does not install the config that it comes with, it would be misleading for the recipe to report that it was successfully applied.

Since we now have the option of importing config from modules or the config folder strict, the default should be changed to lenient.

Since you can't set strict: false and then enforce individual strict configs, changing to lenient will allow the greatest flexibility.

Does this mean that recipes can now be applied successfully on the command line, even if the configuration they include isn't actually applied to the site? How would a site builder identify pre-existing configuration issues and distinguish them from problems with the recipe itself?

This was discussed in a Recipes initiative meeting and we decided it was best to leave it as is. Recipe author documentation was updated with the following that allows for most of everyone's needs except for replace/override which is a deliberate decision that the recipe team has made to not be destructive to sites.

  # The recipe system compares configuration from your recipe and the modules
  # you bring in against your site's active configuration. By default it
  # requires that they be identical in every detail, or it throws an error.
  # strict: true

  # You can set this to false to have the recipe runner skip the config import
  # if it finds anything different.
  # strict: false

  # A recipe can choose to opt only certain config into the strict checking. If
  # you specify individual config files to be treated strictly, then all others
  # will be treated lenient.
  # strict:
  #   - field.storage.field_oysters
  #   - field.storage.field_quahogs