Configuration entity fields are not exposed to the TypedData API in terms of data definition. If you remember, though, we do have the configuration schema that describes the type of data that is considered valid in the entity. This is, for the moment, the extent to which we can validate configuration entities as they are not (yet) exposed to the constraint-validator system.
But before we conclude this chapter, let's quickly see how we can validate a configuration entity. Here is a quick example:
$config_entity = View::load('content');
$config_entity->set('status', 'not a boolean');
$typed_config_entity = ConfigEntityAdapter::createFromEntity($config_entity);
$violations = $typed_config_entity->validate();
The first thing we do is load a configuration entity. In this case it's a View, but it doesn't matter as it's backed by a schema definition (found in views.schema.yml). By default, the entity is valid, so in this example, I change the status field to a string (not a Boolean). Then for the actual validation we create a new ConfigEntityAdapter instance (which is like the EntityAdapter we saw earlier for content entities). And we can now call validate() on that like before. The result will be a list of violations, which in the case of this example, will contain one that says we are using an incorrect primitive value for the status field. And that is pretty much it.