Add validation constraints to config_entity.dependencies

Review

Review posted. Looks fantastic IMHO 🤩 👏

Test failures

Looks like 99% of the failures are in Drupal\Tests\ckeditor5\Kernel\ValidatorsTest, which … sort of makes sense: it's the only other place in Drupal core that uses config entity validation. So in an unexpected way, that is the perfect proof that this indeed works across all Drupal config entities! 😄👍

However … since that file does not actually specify dependencies: […] anywhere … I think it's actually an edge case bug in the validator.
Turns out that var_dump(array_is_list([])); prints TRUE (see https://3v4l.org/fCJQ8) — meaning that dependencies: [] would also be considered invalid.
I think this is simply caused by \Drupal\Core\Entity\DependencyTrait::$dependencies, which looks like this:

  /**
   * The object's dependencies.
   *
   * @var array
   */
  protected $dependencies = [];

Next

What do you think about

Bonus (because not sure if actually feasible): if a config entity type is known to depend on another config entity (for example: a field_config entity always needs a field_storage_config entity — at minimum), but it doesn't specify such a dependency, fail validation in that case too.

?

Do you think it could be done? 🤓

Epic progress here! 🤩

I think this issue represents a massive leap forward for #2164373: [META] Untie config validation from form validation — enables validatable Recipes, decoupled admin UIs …! 🤩🚀

Last round of feedback on the MR, just to make this as future-ready as possible. And on that same note: we might want to add the RequiredConfigDependencies constraint to all core config entity types? 🤞

Finally, this definitely needs a change record before it can go in.

But … I think this is very close to RTBC 😊

CR looks great — but makes it sounds like config validation is actually being used already, but it's not. I think we should clarify that the validation constraints have been added, and test coverage is included, but it's not yet enabled — TBD in #2164373: [META] Untie config validation from form validation — enables validatable Recipes, decoupled admin UIs … when it actually gets enabled.

Still have one important future-looking remark on the MR that I mentioned in #9 but failed to submit to the GitLab MR last night 🫣 Sorry!

Why would we do that? It's only there to validate config entities that have hard dependencies on other config entities, which (AFAIK) is not the case for most core entity types.

I of course meant only the ones that need it. I thought it was most of them!

And clearly that's not the case! 🤩

The 5 generic validation constraints that this adds will come in handy when working to add validation constraints to specific config/config entity types — I already see uses for several in #3324140: Convert field_storage_config and field_config's form validation logic to validation constraints!

I can't believe how far this has come along in such a short time, thank you so much, @phenaproxima! I only needed to post suggestions and you then made it a reality 🤩

@idebr: they are if you do call $config_entity->validate() … if that method even existed 🫣😅 That is how far removed we are from having validatable config entities. See the test coverage that was committed to find out how one can validate config entities today.

If so, at what point will constraints be called?

For sure when #2164373: [META] Untie config validation from form validation — enables validatable Recipes, decoupled admin UIs … is complete.

And also: what is the point of adding constraints if these are not validated?

Like the change record indicates (but perhaps insufficiently clearly?): because we have to start somewhere, we can't commit a multi-megabyte patch that adds validation constraints to 100% of core's config schema's in one fell swoop.

This is now helping us at #3361534-15: KernelTestBase::$strictConfigSchema = TRUE and BrowserTestBase::$strictConfigSchema = TRUE do not actually strictly validate! 🥳