Stricter validation for config schema types is available

A config schema type can now declare itself fully validatable by adding the FullyValidatable validation constraint. For example:

Simple config

my_module.settings:
  type: config_object
  label: 'Update settings'
  mapping:
    foo:
      type: boolean
…
  constraints:
    FullyValidatable: ~

Config entity type

shortcut.set.*:
  type: config_entity
  label: 'Shortcut settings'
  mapping:
    id:
      type: machine_name
…
  constraints:
    FullyValidatable: ~

What it means to be "fully validatable"

All values are required by default

In a fully validatable config schema type, all values are required by default (they cannot be NULL). A particular property can be marked optional (that is, allowed to be NULL) by specifying nullable: true.

(In configuration, type: sequence and type: mapping are the two types that can contain other values.)

So in the example above:

• if my_module.settings:foo is set to null, you will see a validation error: This value should not be null. on my_module.settings:foo.
• if shortcut.set.MY_SHORTCUT_SET:id is set to null, you will see a validation error: This value should not be null. on shortcut.set.MY_SHORTCUT_SET:id.

All keys of a mapping must be present

In a fully validatable config schema type, all type: mappings contained in that type will run the ValidKeys constraint in a strict mode, which will flag errors if any keys are missing (see the related change record for the Mapping object).

So in the example above:

• if my_module.settings:foo is missing, you will see a validation error: 'foo' is a required key. on my_module.settings.
• if shortcut.set.MY_SHORTCUT_SET:id is missing, you will see a validation error: 'id' is a required key. on shortcut.set.MY_SHORTCUT_SET.

A particular property can mark itself as optional (i.e., does not need to be present) by specifying requiredKey: false.

Config used in tests must be valid

The above validation also be applied to all tests.

Why?

1. modifying config via JSON:API/GraphQL/REST requires full validation of config, which means we can't rely on forms to ensure certain config keys or values are present
2. for the Recipes initiative to be able to provide a reliable experience, full validation of config is required
3. updates would become more reliable (and Automatic Updates for contrib becomes more feasible)
4. et cetera

In other words: these changes allow us to trust (and verify) config in many more situations than just the admin UI!