Add config validation for UUIDs

+++ b/core/lib/Drupal/Core/Validation/Plugin/Validation/Constraint/UuidConstraint.php
@@ -0,0 +1,25 @@
+  public function validatedBy() {
+    return UuidValidator::class;
+  }

So this is interesting, as we otherwise use \Drupal\Component\Uuid\Uuid::isValid() in core. In general it would be nice to use the upstream validation, but I think if we want to do that we should do so wholesale and deprecate our own version? Or alternatively make our Uuid::isValid() use Symfony's implementation internally?

Pinged @tstoeckler: https://twitter.com/wimleers/status/857677738320293888

Let's get this issue moving forward again — almost 2 weeks without progress for something tiny.

So, what uses \Drupal\Component\Uuid\Uuid::isValid()? 3 classes:

1. \Drupal\Tests\field\Kernel\String\UuidItemTest
2. \Drupal\KernelTests\Core\Entity\EntityFieldDefaultValueTest
3. \Drupal\Tests\Component\Uuid\UuidTest

IOW: only tests (which coincidentally implies that we aren't validating UUIDs anywhere … GASP!).

+++ b/core/lib/Drupal/Core/Validation/Plugin/Validation/Constraint/UuidConstraint.php
@@ -0,0 +1,25 @@
+class UuidConstraint extends Uuid {
...
+  public function validatedBy() {
+    return UuidValidator::class;
+  }

This is reusing \Symfony\Component\Validator\Constraints\Uuid, whose corresponding pre-existing (!) validator is \Symfony\Component\Validator\Constraints\UuidValidator.

Why is this then even subclassing it? Because Drupal uses a annotation-based discovery system.

And so, to add an annotation, we must subclass. And in subclassing, we rename for consistency with Drupal's other validation constraints. And in subclassing, we must override the default validatedBy() implementation.

But, in the end, this is really just reusing the existing validation constraint!

I think it's fine to deprecate \Drupal\Component\Uuid\Uuid in favor of \Symfony\Component\Validator\Constraints\UuidValidator, but doing so is out of scope here. Opened #2876659: Deprecate \Drupal\Component\Uuid\Uuid in favor of \Symfony\Component\Validator\Constraints\UuidValidator for that.

@Wim in #11: Lame as it may be, that is indeed how core expects constraints to be declared right now :)

See other constraints such as Length or Count. Even though they change the parent's messages, they basically do the same. A solution could be to "discover" symfony constraints along with annotation based discovery, but that is also out of scope for this issue.

Committed b7eb07e and pushed to 8.4.x. Thanks!

I credited @Wim Leers, @tstoeckler and @kristiaanvandeneynde for reviews as they all considered the impact of adding the constraint and its implementation.

+++ b/core/config/schema/core.data_types.schema.yml
@@ -275,7 +282,7 @@ config_entity:
     uuid:
-      type: string
+      type: uuid

<3

diff --git a/core/tests/Drupal/KernelTests/Core/Validation/ConstraintsTest.php b/core/tests/Drupal/KernelTests/Core/Validation/ConstraintsTest.php
index a018f54..8e17422 100644
--- a/core/tests/Drupal/KernelTests/Core/Validation/ConstraintsTest.php
+++ b/core/tests/Drupal/KernelTests/Core/Validation/ConstraintsTest.php
@@ -40,8 +40,6 @@ public function testUuid() {
     $typed_config->get('uuid')
       ->setValue(\Drupal::service('uuid')->generate() . '-invalid');
     $this->assertCount(1, $typed_config->validate());
-    
   }
-  
 
 }

Fixed whitespace on commit.

Closed #2462155: Field settings schema missing for some field types as a duplicate, moving credit.