Cannot place a code component with an image prop

I'd like to ensure we never again run into this problem. We've only last week started to get really serious about ComponentSource plugin test coverage (landed on Friday: 📌 Introduce unit test coverage for both ComponentSource plugins (Block + SDC) Active ). I created 📌 [PP-1] Add `JsComponent` unit test Active specifically to make "in-browser code component" test coverage catch up to other ComponentSource plugins' test coverage.

So … I'd like to see this MR update \Drupal\Tests\experience_builder\Kernel\Plugin\ExperienceBuilder\ComponentSource\JsComponentTest.

There's also some config schema changes I need to dig deeper into to understand properly. Assigning to myself for that.

We should merge this ASAP so I'd recommend we move adding tests to a follow-up unless something that can be done very easily. There are quite a few people building on top of XB even though it's alpha and this is a pretty disruptive regression so we should try to roll a new release with this as soon as we can.

wim leers → credited longwave → .

Discussed with @longwave at Drupal Dev Days, he agrees that adding type: experience_builder.json_schema.object.json-schema-definitions://experience_builder.module/image is a no-go.

Added the missing tests. But can't get them to fail.

Neither of us understands why we can't reproduce the problem neither through that test, nor through the manual STR in the issue summary. My changes/the solution I believe should work does appear to work, but also appears to somehow trigger the e2e tests to fail.

I'm hoping @larowlan can figure this out 🤞

So the difference is strict schema checking in tests or rather SchemaCheckTrait also checks each individual value has a schema.
So whilst validation is checking that 'this data validates against the schema we have', strict config schema checking as seen in tests (and in FunctionalTestSetupTrait) fails if there is no schema at all. Which is what was happening. I've expanded the test to mimic what SchemaCheckTrait does.
The test did indeed fail with the missing schema. So then I reinstated the new schema and updated the test to validate invalid props against the new schema.
Then I removed it again and added a new schema class that could auto derive the mapping from the $ref.

As I started skimming the changes, I uttered "WOW" and went to get more coffee 😜☕️

#10: 🤯 Wow, I totally forgot that in some ways, SchemaCheckTrait is the more complete validation of config schema. The thing that it does and \Drupal\Core\Config\Development\ConfigSchemaChecker (which XB's tests use) does not is the completeness of the schema.

So: while \Drupal\Core\Config\Development\ConfigSchemaChecker does use SchemaCheckTrait, and so it does run for the entire XB codebase, it only runs upon saving. And the XB config entity validation test coverage tests validation *prior* to saving. We could gain extra confidence by also running the relevant subset of ConfigSchemaChecker on unsaved entities while asserting XB config entity validation errors, and only surfacing those schema incompleteness errors for which no validation errors occur.

Given that @larowlan has succeeded in undermining my confidence in the completeness of XB's config schema and validation 😬 😱, I'm generalizing what you did here, @larowlan! 🙏

Will merge when this passes tests.

I took @larowlan's impressive work and generalized it from that single config entity subtree in a single test method, to all test methods of all config entity types. Two tiny tweaks were necessary in ComponentValidationTest, but I'm relieved to report that no other XB config entity types surfaced similar additional problems! 🥵