Build: Split packages and blocks to their webpack configs

[gziolo]

It aligns with the changes proposed in Gutenberg: ​https://github.com/WordPress/gutenberg/pull/33293.

The idea here is to split the growing webpack config into two parts:

• blocks
• packages

We need to add handling for JavaScript files that are going to be used with blocks on the frontend. They don't work quite well with the current setup for entry points created for packages because of reasons like:

• the output path is different
• frontend scripts should not be exposed under wp globals

In general, it looks like the split is a good strategy because it nicely separates two independents parts: packages and blocks. There isn't that much overlap between configs anyway.

Add View Script support for block types

As part of the effort, this PR adds support for viewScript in block.json metadata file that is later translated to $view_script in WP_Block_Type class and exposed as view_script from the REST API endpoint for block types.

Trac ticket: https://core.trac.wordpress.org/ticket/53690

It aligns with the changes proposed in Gutenberg: ​https://github.com/WordPress/gutenberg/pull/33293.

The idea here is to split the growing webpack config into two parts:

• blocks
• packages

We need to add handling for JavaScript files that are going to be used with blocks on the frontend. They don't work quite well with the current setup for entry points created for packages because of reasons like

• the output path is different
• frontend scripts should not be exposed under wp globals

In general, it looks like the split is a good strategy because it nicely separates two independents parts: packages and blocks. There isn't that much overlap between configs anyway.

## Add View Script support for block types

As part of the effort, this PR adds support for viewScript in block.json metadata file that is later translated to $view_script in WP_Block_Type class and exposed as view_script from the REST API endpoint for block types.

@aristath and @youknowriad – do you think we should some automated handling for the view script? At the moment it's handled manually by the File block in render_callback. I personally think about enqueuing automatically the view script when a block is rendered and render_callback isn't provided. We can safely assume that in such a case the block author wants to have the view script to be loaded on the frontend when the block is present in the HTML.

@aristath and @youknowriad – do you think we should some automated handling for the view script? At the moment it's handled manually by the File block in render_callback. I personally think about enqueuing automatically the view script when a block is rendered and render_callback isn't provided. We can safely assume that in such a case the block author wants to have the view script to be loaded on the frontend when the block is present in the HTML.

Automatically enqueueing the script when the block is rendered would make sense... I don't see why we'd require manually adding it to render_callback :+1:

@aristath and @youknowriad – do you think we should some automated handling for the view script? At the moment it's handled manually by the File block in render_callback. I personally think about enqueuing automatically the view script when a block is rendered and render_callback isn't provided. We can safely assume that in such a case the block author wants to have the view script to be loaded on the frontend when the block is present in the HTML.

Automatically enqueueing the script when the block is rendered would make sense... I don't see why we'd require manually adding it to render_callback 👍

Added in ​https://github.com/WordPress/wordpress-develop/pull/1412/commits/179116566e8a251d52b89b769033de42d4d84362. If the render_callback is provided then it has to be explicitly handled to account for the more complex cases like with the core blocks: File and Navigation.

[gziolo]

In 51501:

Build: Split packages and blocks to their webpack configs

It aligns with the changes proposed added in Gutenberg: ​https://github.com/WordPress/gutenberg/pull/33293.

The idea here is to split the growing webpack config into two parts: blocks and packages.

We need to add handling for JavaScript files that are going to be used with blocks on the frontend. They didn't work quite well with the current setup for entry points created for packages.

As part of the effort, it adds support for viewScript in block.json metadata file that is later translated to $view_script in WP_Block_Type class and exposed as view_script from the REST API endpoint for block types.

Props youknowriad, desrosj, aristath.
Fixes #53690.

Closed with https://core.trac.wordpress.org/changeset/51501.

[desrosj]

In 51693:

Coding Standards: Apply some minor alignment fixes.

These are updates caused by running composer format.

Follow up to [51501], [51599], [51618], [51653].
See #53359, #50542, #53238, #53668, #53690.

[gziolo]

In 52011:

Build: Remove polyfills from block view scripts

Related changes in Gutenberg: ​https://github.com/WordPress/gutenberg/pull/35038.

When adding a block with a view.js script, the frontend loads an additional ~20kb of scripts that were previously not there. These are coming from polyfills that are defined as a dependency for view.js scripts.
Since WordPress dropped support for IE, these polyfills are no longer needed and can be removed.

Follow-up to [51501].
See #53690.
Props aristath.

[SergeyBiryukov]

#53565 was marked as a duplicate.