Automatically sync stable blocks from Gutenberg to wordpress-develop on release

[adamziel]

What problem does this PR solve?

Syncing stable blocks from the Gutenberg repository to wordpress-develop is currently a manual process.

The thing is, it can be automated.

That's what this PR does.

How does this PR solve it?

The big idea is to:

1. Read all the block.json files from the @wordpress/block-library directory.
2. Pick the ones without __experimental restrictions – these are the stable blocks.
3. Use that list to generate PHP code that requires appropriate dynamic blocks PHP files.
4. Use that list to generate PHP code that calls remove_action with appropriate arguments in PHP unit tests.
5. Use that list yet again in Webpack config, instead of the hardcoded one.

All of this is possible thanks to WordPress/gutenberg#40655

To make the process smooth, require and remove_action calls were extracted to separate PPH files that can be easily autogenerated and overwritten:

• wp-includes/blocks/require-blocks.php
• tests/phpunit/includes/unregister-blocks-hooks.php

How to test?

1. Wait for the Gutenberg 13.2 release on May 11th where Declare blocks as __experimental in block.json to automate syncing Gutenberg packages to WordPress gutenberg#40655 will be included
2. Confirm all the checks are green on this PR
3. Checkout this branch
4. Run npx grunt sync-gutenberg-packages
5. Confirm all the stable blocks are now represented in the php files listed above
6. Confirm all the stable blocks were included in the build.
7. Confirm experimental blocks like post-author-name were excluded from both lists

cc @gziolo

[gziolo]

This looks great. I left some minor comments but overall it's ready for testing with the real changes coming from the Gutenberg repository and the most recent version of WordPress packages. We should give it a try updating WP packages in trunk next week with all the automations we have in place now and see if that is ready to land.

[gziolo]

A good example of what type of issues this patch would prevent: WordPress/gutenberg#41292 (comment).

[adamziel]

This one should be ready to go @gziolo @swissspidy!

[gziolo]

I'll give it a spin with the trunk and see if it works as intended. Otherwise, it feels like it's ready to land and improve the way we handle syncing blocks. Excellent work @adamziel! ❤️

[gziolo]

Nit: Let's move /blocks/require-blocks.php as the first import before all special cases.

[gziolo]

Any reason we can't use?

Suggested change

	const { main } = require( __dirname + '/tools/release/sync-stable-blocks' );
	const { main } = require( './tools/release/sync-stable-blocks' );

Is there also any reason why it has to be required dynamically rather than in the header of the file?

[gziolo]

I'm seeing the following error after executing in the most recent trunk:

npm run grunt sync-gutenberg-packages

I noticed two things:

• Table of Contents block is marked as experimental so it shouldn't be processed in the first place
• Comments Query Loop got renamed to Comments (core/comments) so I'm not quite sure why it tries to process the old name

So I might find the answer to my question from #2647 (comment). We update all the packages first, and we should dynamically discover core blocks at this point. We probably do it before and that would be the reason of this error.

[gziolo]

The good news is that second run of npm run grunt sync-gutenberg-packages finished successfully so it must be exactly the same issue as I described in my previous comment.

There is also an edge case which we probably can ignore. We have now two folders src/wp-includes/blocks/comments and src/wp-includes/blocks/comments-query-loop after this block got renamed.

There is one more place where the list of block names is hardcoded and it would be great to move it to automatically generated file:

wordpress-develop/src/wp-includes/blocks/index.php

Lines 78 to 106 in 0abc2b2

	$block_folders = array(
	'audio',
	'button',
	'buttons',
	'code',
	'column',
	'columns',
	'embed',
	'freeform',
	'group',
	'heading',
	'html',
	'list',
	'media-text',
	'missing',
	'more',
	'nextpage',
	'paragraph',
	'preformatted',
	'pullquote',
	'quote',
	'separator',
	'social-links',
	'spacer',
	'table',
	'text-columns',
	'verse',
	'video',
	);

Otherwise, new core blocks that are static (no PHP file) won't get registered on the server.

[gziolo]

I had to open #2940 to rebase this branch with trunk and to apply further changes.