Create Block: Update the list of default categories to pick from after WordPress 5.5 is out

[gziolo]

Description

It's possible now to register blocks without providing the category. It became optional in #22280.

In addition to that, there is now a refined list of categories as of #19279:

• Text
• Media
• Design
• Widgets (Unchanged)
• Embeds (Unchanged)
• Reusable (Unchanged)

@wordpress/create-block uses now those new categories and in general, with those two aforementioned changes, it should work just fine for blocks targeting WordPress 5.5 (scheduled for August) and with the next version (8.3) of Gutenberg plugin.

There is this question whether including an entry in the CHANGELOG file referencing this draft of Dev Note would be enough:
#19279 (comment)

An alternative would be to include PHP code that maps old and new names as explained in the same Dev Note.

Proposed Changes

When WordPress 5.5 is out we should update the list of categories and set the minimum required version of WordPress to 5.5.5. Related lines in the codebase:

gutenberg/packages/create-block/lib/templates/es5/readme.txt.mustache

Line 6 in d3503d4

Requires at least: 5.3.2

gutenberg/packages/create-block/lib/templates/esnext/readme.txt.mustache

Line 6 in d3503d4

Requires at least: 5.3.2

gutenberg/packages/create-block/lib/prompts.js

Line 73 in d3503d4

choices: [ 'common', 'embed', 'formatting', 'layout', 'widgets' ],

[aduth]

It could technically be possible as well to revert back to the old categories, which will work in WordPress 5.0 - 5.4, and continue to work in WordPress 5.5, albeit mapped automatically to their new approximate equivalents. It's really only a temporary solution though, and leaves open the question when to switch over to the new values. Plus, it's not ideal to continue shipping the scaffolding tool using now-defunct category values.

The solution at #19279 (comment) could be a nice middle-ground. I was a bit displeased to discover that get_block_categories requires a valid post argument. It would be good to test as a verification that the devnote sample is workable in all cases. It may also be worth testing to see if providing a value of null could suffice as well, though depending if a plugin filters the block_categories filter and expects the provided $post argument, it could yield some conflict if that were provided as null.

[gziolo]

It could technically be possible as well to revert back to the old categories, which will work in WordPress 5.0 - 5.4, and continue to work in WordPress 5.5, albeit mapped automatically to their new approximate equivalents. It's really only a temporary solution though, and leaves open the question when to switch over to the new values. Plus, it's not ideal to continue shipping the scaffolding tool using now-defunct category values.

I have only realized that we need to use the JavaScript version of the proposal because the template used doesn't register category on the server. Regardless, I'm leaning towards leaving old category names until WordPress 5.5 is out. At the same time, I see the need for a new optional template that uses block.json that could use a new set of categories as well. This way we could promote the best experience for those who want to work with what the Gutenberg plugin offers but ensure that the majority build blocks that work by default with the actual version of WordPress without the plugin installed.