Getting CoBlocks into the Block Directory

[jrtashjian]

Getting CoBlocks into the Block Directory

Related links:

• https://developer.wordpress.org/plugins/wordpress-org/block-specific-plugin-guidelines/
• https://developer.wordpress.org/block-editor/getting-started/create-block/submitting-to-block-directory/
• https://wordpress.org/plugins/developers/block-plugin-validator/
• https://richtabor.com/gutenberg-block-plugins/
• https://richtabor.com/build-publish-gutenberg-block-plugins/

Requirements

Block plugins must adhere to the guidelines detailed here: https://developer.wordpress.org/plugins/wordpress-org/block-specific-plugin-guidelines/

Quick Summary of Requirements:

• Intended to be single purpose and independent blocks, not bundles.
• Must utilize block.json to load scripts and styles.
• Minimal PHP used - limited to the most basic initialization of the plugin (register_block_type()).
• Filesize must be as lightweight as possible to allow fast installation through the block inserter.

Each individual block will need to be submitted to the regular plugin directory as well as the new block directory: https://wordpress.org/plugins/developers/block-plugin-validator/

What we need to do for CoBlocks:

1. In order to make individual block plugins from CoBlocks we need to identify the blocks that fit the requirements for submission into the block directory. Any dynamic blocks (server rendered) or blocks heavily reliant on server side code will be excluded. We might have some blocks that are not server rendered but have associated server side code and could be refactored to either minimize or remove that requirement. Doing so would allow us to bring those blocks into the block directory.

2. Inside CoBlocks, we have extracted shared code into logical groupings for reuse which will need to be included in each single block plugin. If a user has installed multiple CoBlocks block plugins duplicate scripts and styles will also be loaded on the page. In order to resolve this problem we need to compile shared scripts and styles separately from the individual blocks. We can then include those files inside each block plugin with a simple enqueuing condition and still be minimizing our PHP code. We can prevent enqueuing shared scripts and styles if another CoBlocks block plugin has already initialized. We can also determine which version of the shared asset is loaded although this can cause conflicts or overriding each other.

   My personal opinion here would be to refactor in order to avoid shared scripts/styles entirely. Having different versions loading and trying to determine which version should be enqueued is going to be overly complex. This could increase each block plugin's bundled size but we would avoid a lot of problems that would cause difficulty debugging and supporting users.

3. It would benefit us to utilize core features as much as possible and migrate away from our custom solutions where a core feature exists. Doing so will minimize our bundle size and maintenance over time. For our shared components and extensions - for which there is no core feature - we could create our own npm package similar to how @wordpress/components is used so that we can version it and make it easier to maintain across projects.

4. We might be able to continue utilizing the main repository and include additional build scripts to bundle each individual block plugin during deployment but separate repositories may be clearer and would allow us to deploy individual block as needed vs all at once. I think the team needs to determine what would be better in the long run.