Block Directory: Convert it to UI Plugin to avoid bundling into Core

[gziolo]

Description

This PR optimizes the way modules are configured to ensure that wp-block-directory isn't bundled into the WordPress core. It turns out that @wordpress/block-directory has side effects coming from the store registration so we can't tree-shake it using GUTENBERG_PHASE flag. That's why I started the process of converting it into a UI Plugin which is enqueued separately. It also means that we don't need to enqueue

I removed the logic which uninstalls the block/plugin if it isn't used in the post. We should bring it back in a separate PR once we agree on the best approach. It's already listed as an action item on #17440.

This PR also introduces gutenberg_is_experiment_enabled helper method to make it easier to validate whether a given experiment is enabled.

How it works

The block directory is behind the experimental flag. That's why we don't need to enqueue CSS and JS files where this feature is disabled. The fact that this module/package works now as a UI Plugin makes it completely independent from the rest of Gutenberg. It works like an internal plugin.

To get us there and use enqueue_block_editor_assets to enqueue CSS and JS files only when the block editor is loaded on the page I had to apply quite aggressive refactor. The biggest change is that we no longer use wp_enqueue_scripts and admin_enqueue_scripts to override CSS and JS assets. This drastic change was motivated by the fact that enqueue_block_editor_assets is triggered before those 2 hooks. Fortunately, it was possible to refactor plugin's code to use wp_default_styles and wp_default_scripts instead. It required some moving code around which makes this PR harder to review. On the bright side, it seems like this is something which makes the whole override dance more reliable as it happens just after all those scripts and styles get registered in the WordPress core before any other hooks get applied.

[youknowriad]

I like this direction a lot 👍

[talldan]

@gziolo I tested this and it seems to work the same as what's in master apart from the uninstall feature. I notice it's still a draft, what's left to do?

I like this approach as well, so happy to give the thumbs up.

[gziolo]

@talldan, I was concerned about #17576 (comment). Plus we need to add a note about the uninstall feature in the master issue with follow-up tasks. Unless you feel we should do it here. I’m AFK until Tuesday so feel free to do whatever is necessary to land it.

[gziolo]

I added some refactoring which ensures that assets for the block directory aren't enqueued when the expirement is disabled.

There is one issue still to resolve but I don't think it's a blocker for inclusion in Core: https://github.com/WordPress/gutenberg/pull/17576/files#r331999772. We probably will have to fix it in WordPress core first regardless.

[gziolo]

@jorgefilipecosta and @mcsf - can you double-check if the approach taken in 91499ef goes in the right direction? The idea is to be able to use enqueue_block_editor_assets to enqueue scripts and styles only when it's necessary for a given context.

[gziolo]

@ellatrix - it looks like we can safely remove this override which adds wp-hooks as a dependency since you landed: #16683. Can you confirm?

If yes. It would mean we can also do it WordPress core.

[ellatrix]

Yes, there is no more hooks dependency!

[mcsf]

I was not very inside our asset enqueuing process, but to me, this PR seems to bring some code simplification.

I agree. There's a lot of code moving around, but the whole thing reads relatively well and puts us in a better place.

[mcsf]

Great work!

[gziolo]

Thank you all for all the help and reviews. I merged it after the RC for the plugin was published yesterday so we could have enough time for testing as it potentially might have some unexpected impact on the JS and CSS assets. I didn't discover any issues while testing but you never know when changing hooks in WordPress :)