SdcPropKeysConstraintValidator::validate() should complain about extraneous keys too, not just missing keys

None of the code in 0.x can generate this, it had to be manually constructed by @tedbow in a test.

Therefore, even sites created on beta1 should never run into this. Even if that's the case, the update path would be trivial 👍

I updated the SdcPropKeysConstraintValidator::validate() method to check for extra keys in the input mapping that are not defined in the SDC props.
To support this, I added a new extraMessage property to the SdcPropKeysConstraint class for the error message.

Looking good! That’s step 1 done 😄

Steps 2 and 3 are in the issue summary, do you think you could handle those too? 🙏

I think is probably moot post 🐛 Deterministic Component version hash should depend not only on source-specific settings, but also slots + explicit input schema Active as the validation won't pass because the version doesn't match?

🤔 I think it can still be wrong.

Because \Drupal\experience_builder\ComponentSource\ComponentSourceBase::generateVersionHash() looks at

    $normalized_data = [
      'settings' => $typed_source_specific_settings->toArray(),
      'slot_definitions' => $this instanceof ComponentSourceWithSlotsInterface
        ? self::normalizeSlotDefinitions($this->getSlotDefinitions())
        : [],
      'schema' => $this->getExplicitInputDefinitions(),
    ];

There's nothing preventing $typed_source_specific_settings to contain too much data — that'd just end up being hashed along with it; still resulting in a predictable version … just one based on mismatched settings.

In fact, \Drupal\Tests\experience_builder\Kernel\Config\ComponentValidationTest::setUp() proves that this is still the case.

Given @larowlan's #9, I figured I'd just get this done 😇

Thanks, @meghasharma, for getting this going! :)

Automatically closed - issue fixed for 2 weeks with no activity.