Restrict private Block.json and Theme.json APIs usage to Gutenberg plugin

[adamziel]

Description

Now that the usage of private selectors, actions, components, functions, and other exports can be restricted to the Gutenberg plugin, it's time to also make it possible for block.json and theme.json APIs.

This issue is a part of Developer Experience: There's ~280 __experimental APIs. Let's stabilize them!.

Block.json

At the moment, the private block.json APIs can be restricted to core blocks by manually checking the block type. For example, here's how that would look like for supports.__experimentalMetadata:

export function hasBlockMetadataSupport( blockType, feature = '' ) {
+   if ( ! blockType.startsWith('core/') ) {    
+       return false;
+   }
    const support = getBlockSupport( blockType, '__experimentalMetadata' );
    return !! ( true === support || support?.[ feature ] );
}

It would be convenient to automate this process and apply it to all __experimental block.json entries. Here's an idea: preprocess all the block.json metadata and remove the __experimental keys from all non-core blocks. This wouldn't apply to the __experimental entries that have already become a public API. Technically speaking, I'm thinking of recursive filtering based on the block type prefix and an allowlist of public experimental APIs.

Theme.json

I don't understand the meaning of restricting the experimental theme.json API to the Gutenberg plugin. Would it be based on a list of core themes? Theme.json files have a hierarchy – what if a third-party theme inherits experimental settings from a theme.json file related to WordPress core? CC @scruffian @mtias @draganescu @youknowriad

CC @gziolo @dmsnell @jsnajdr @ciampo @noisysocks @talldan @ntsekouras @andrewserong

[gziolo]

It would be convenient to automate this process and apply it to all __experimental block.json entries. Here's an idea: preprocess all the block.json metadata and remove the __experimental keys from all non-core blocks. This wouldn't apply to the __experimental entries that have already become a public API. Technically speaking, I'm thinking of recursive filtering based on the block type prefix and an allowlist of public experimental APIs.

We remember we discussed this idea some time ago for block.json. I still believe it's worth exploring with some remarks:

• Blocks can be registered on both the server (preferred approach) and the client (legacy approach), so my understanding is we would have to filter block settings during registration in both places and also do it after all WordPress filters get applied. What are the performance implications for processing block settings to remove experiments?
• Is it possible to allow experiments to run for 3rd party blocks with the Gutenberg plugin but not WordPress core? could it break anything?

[draganescu]

I think a person to offer some pointers along the lines of "do we need private theme.json experimental values" is @oandregal