Add ComponentAuditabilityTest

From DX perspective the value of duplicating this information in the config seems questionable. There could be implementation reasons why it's needed but it's hard for me to consider this from that perspective. However, if we do it, we need to somehow allow getting changes to components, as well as the field type + widget settings to the config (if that's what defines what gets used in XB). During development, it seems normal that these values get changed. We have to account for the effort to address that, and the complexity it introduces for us to manage that.

However, if we do it, we need to somehow allow getting changes to components, as well as the field type + widget settings to the config (if that's what defines what gets used in XB).

How will that work if there is already data associated with the component in the database?

From DX perspective the value of duplicating this information in the config seems questionable.

It would be transparent towards SDC developers.

We need some record of what exists, is being used, and what the expected shape is. That's necessary for the following product requirements:

1. 1.2 Design systems (foundations) (nutshell: "which components exist?")
2. 14. Configuration management (nutshell: "changes to components")
3. 15. Developer-created components (nutshell: "easy way to expose components" + "not all SDCs should be exposed automatically")
4. 49. Component migration (nutshell: "change component props and migrate existing content")
5. 63. Shared components (nutshell: "can use the UI to create a component")
6. 64. Module shipped no-code components (nutshell: "build component in UI, export and ship with my module so that consumers can import and edit it")

So as an MVP example, we need to know what props for each component exist and how the Content Creator can populate them. That is some sort of state. That state must remain in sync with the code base. That's why configuration is the most natural choice to track that state: because it already must be kept in sync with the code. Which means that tracking this under the hood in configuration also means there's no new deployment requirements being imposed!

👆 explains the rationale for both 📌 Auto-create/update Component config entities for all discovered SDCs that meet XB's minimum criteria Fixed and this issue.

But I do recognize the need for a smooth DX! The key thing there though is that not every SDC change is equal:

1. The above already works fine with deployment
2. You're worried about front-end developer-created/modified SDCs not taking effect. For that, the solution is: #3463999-9: [PP-1] Auto-generate Component config entities for all discovered SDCs that meet XB's minimum criteria →
3. You're worried about SDCs built by the Site Builder through XB's future "Theme Builder" not taking effect. For that, the solution is: selectively update the ComponentPluginManager's cache and Twig's cache: the component being edited should have its changes reflected immediately. (And once that component is already being used, no existing properties can be renamed, and no new required properties can be added. For that, we'll need the 44. Component usage product requirement to be solved.)

Related: .

Actually, as of 📌 [PP-2] Add ComponentAuditabilityTest Active , that earlier issue would already unblock this 👍

📌 Introduce `hook_storable_prop_shape_alter()`, use it to prefer the Media Library widget for "image" PropShape if Media Library is installed Fixed is in! 🚀

Because that added both an alter hook and a concrete implementation (media_library_storage_prop_shape_alter()), the status with initially NOT the Media Library module installed, and then WITH that module installed, will cause configuration changes … at least once 📌 Auto-create/update Component config entities for all discovered SDCs that meet XB's minimum criteria Fixed lands.

That means this will for sure be unblocked by #3463999 👍

I.e. this is no longer blocked by 📌 [PP-1] Introduce `FieldTypeStorageForJsonSchemaDefinition` plugin type Postponed !

📌 Auto-create/update Component config entities for all discovered SDCs that meet XB's minimum criteria Fixed landed weeks ago.

I think that now it makes sense to wait for 📌 [PP-2] Add ComponentAuditabilityTest Active , which will introduce part of what this aims to address: the beginnings of a UI that allows auditing what components are available in XB or not, and if not: why not.

📌 Surface the REASON for an SDC not being made available in XB (i.e. not meeting criteria) Fixed is in!

(And that's of course the issue that #9 should've linked 🙈)

Stumbling upon https://www.drupal.org/node/3250104 → thanks to 📌 Allow ChangedItem to skip updating the entity's "changed" timestamp when synchronizing Fixed made me wonder … should we improve auditability by tracking a "last time changed" thing in Component config entities too? 🤔 It may be unconventional, but it's … also not unreasonable I think?