Add command to @wordpress/scripts to create block manifest PHP file

[felixarntz]

What problem does this address?

WordPress Core has for several years now included a blocks-json.php file, which is a built asset that combines all Core block.json files into an already parsed PHP array. This means notable server-side performance benefits by avoiding lots of filesystem reads and JSON parse calls.

As of WordPress 6.7, it will be possible for plugins to use the same approach to get the same performance benefits: https://core.trac.wordpress.org/ticket/62002 / https://core.trac.wordpress.org/changeset/59132 introduces a wp_register_block_metadata_collection() function that allows plugins to register such a block metadata PHP manifest file, which especially helps plugins that register several block types.

However, as of today, there's no clear and trivial path for plugin developers to generate the kind of block metadata manifest file that they would need for this. It's already possible today by looking at e.g. how WordPress Core does it, but that's still tedious and most people won't go the extra mile for this. So having an easy-to-use command handy for this would be crucial.

What is your proposed solution?

The @wordpress/scripts package, which is commonly used by WordPress plugin developers, should provide a new command that generates such a block metadata PHP manifest from all the block.json files that are part of the plugin. This would lead to having a cohesive story for plugin developers to make use of the functionality.

WordPress Core currently has this process implemented as a Grunt task. It shouldn't be too difficult to re-implement this in a reusable way and make it available for any developer to use via @wordpress/scripts.

[felixarntz]

cc @gziolo @mreishus

[felixarntz]

If anyone is willing to work on this, I think this would be super cool to have within the next month or so. This way, we could promote it in combination with the new WordPress 6.7 API function, which is supposed to receive a developer note blog post either way.

[mreishus]

Draft here: #65866

[gziolo]

Implemented with #65866.