The following discussion from !1112 should be addressed: - [ ] @wimleers started a [discussion](https://git.drupalcode.org/project/canvas/-/merge_requests/1112#note_915304): (+1 comment) > :thinking: Should this not already have been a dependency in HEAD? Doesn't that mean this was a bug in HEAD? How did that slip through the cracks? > > 1. Config validation always runs upon config save for all Canvas kernel tests, thanks to `\Drupal\Core\Config\Development\ConfigSchemaChecker`. > 2. One test was installing this `canvas_test_code_components_content_entity_ref` test module: `\Drupal\Tests\canvas\Kernel\ShapeMatcher\HostEntityPropSourceMatcherTest` > > Therefore this should've caught it? > > Ah … no :grimacing: That's _validating the contents_, it's not validating that the dependencies are complete! :grimacing: > > If `\Drupal\Tests\canvas\Functional\Config\DefaultConfigTest` had been installing it, it would've been caught. Except that that itself is not quite possible, because `canvas_test_code_components_content_entity_ref` assumes there's a `news_item` node bundle. > > ## Preventing this in the future > > I think the best way to test this going forward is for Canvas to either: > 1. add validation to all its Config entity types' `config_dependencies` to ensure that what's in there _matches_ what would be computed right now > 2. extend upstream core's `ConfigSchemaChecker` to do check that the declared/stored dependencies indeed match what would be computed right now > > I think a risk with proposal 1 is that config that was once valid and was exported into a recipe, and is then installed on a site where that would no longer be valid (e.g. because a bug was fixed in one of Canvas' config entity types), would fail to be installed. So I think proposal 2 is the safer choice. > > → follow-up. > > #lintcandidate