Deleting optional props from an SDC/code component causes validation errors in config-defined component instances: regression for monolingual sites, bug for multilingual sites
The following [discussion](https://git.drupalcode.org/project/canvas/-/merge_requests/1271#note_1273034) from !1271 should be addressed: > :warning: :exploding_head: While sprinkling `self::assertEntityIsValid(…)` calls over @tedbow's a41099c6d32b6e13296eb0325b1a94cf8ef14b16, this was a highly unexpected find! > > This means #3591667+ would be surfacing validation errors for many component trees using `sdc` or `js` component instances that have had optional props removed. > > Fixing it is out of scope here; needs follow-up. ### Problem Removing an optional prop from an SDC/code component (which triggers a new version for the corresponding `Component` config entity) causes **validation errors for a previously valid-and-completely-unchanged config-defined component tree.** ### Root cause 1. #3582478+ introduced `ComponentInputsMapping`, to allow for translations of config-defined component trees 2. :bulb: But this also ensures stricter validation for _all_ config-defined component trees! (Also on monolingual sites.) This improves DX, because for example exported config-defined component trees gained predictable ordering of `inputs` in each component instance. 3. It calls `JsonSchemaPropsComponentInstanceInputsConfigSchemaGenerator::getConfigSchemaMapping()` 4. Which calls `JsonSchemaPropsComponentSourceBase::getExplicitInputDefinitions()` 5. Which calls `JsonSchemaPropsComponentSourceBase::getMetadata()` 6. Which for both an SDC and a code component can only return the metadata for the _live implementation_: the JSON schema for each prop that is stored in an SDC's `*.component.yml`, or in a code component's `JavaScriptComponent` config entity 7. :bug: ⇒ **The mapping computed by `ComponentInputsMapping` does not actually respect the component version: it always uses the live/deployed JSON schema!** <details> <summary>How does this relate to translations?</summary> The original purpose: `::getConfigSchemaMapping()` in 3. _uses this JSON schema to determine which inputs ("props") are translatable, and sets config schema's `translatable: true` on whichever inputs ("props") have a JSON schema definition that is translatable — for example `type: string` is, and `type: boolean` is not. </details> ### End-user impact - :green_circle: Low, because automatic component instance updating (`ComponentInstanceUpdaterInterface`) automatically fixes it - :yellow_circle: Medium, because #3591667+ will surface lots of validation errors that are more noise than value, although auto-component-instance-updating will trivially fix it. ### Proposed solution Expanding what `type: canvas.json_schema_props`'s `prop_field_definitions` stores: either add 1. `translatable: { type: boolean }` 2. `json_schema: { type: ignore }` ← raw, originally defined JSON schema 3. `shape`: { type: ignore }` ← normalized JSON schema, see `\Drupal\canvas\PropShape\PropShape` This would then enable `JsonSchemaPropsComponentSourceBase::getMetadata()` to return the _version-specific metadata_, instead of the _live/deployed metadata_. > Change record: [#3608942](https://www.drupal.org/node/3608942) > Change record: [#3608946](https://www.drupal.org/node/3608946)
issue