WordPress.org

Make WordPress Core

Opened 2 months ago

Closed 2 months ago

Last modified 4 weeks ago

#53690 closed enhancement (fixed)

Build: Split packages and blocks to their webpack configs

Reported by: gziolo Owned by: gziolo
Milestone: 5.9 Priority: normal
Severity: normal Version: trunk
Component: Build/Test Tools Keywords: has-patch has-unit-tests
Focuses: Cc:

Description

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.

Change History (8)

This ticket was mentioned in PR #1412 on WordPress/wordpress-develop by gziolo.


2 months ago

  • Keywords has-patch has-unit-tests added

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.

#2 @prbot
2 months ago

gziolo commented on PR #1412:

@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.

#3 @prbot
2 months ago

aristath commented on PR #1412:

@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:

#4 @prbot
2 months ago

gziolo commented on PR #1412:

@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.

#5 @gziolo
2 months ago

  • Owner set to gziolo
  • Resolution set to fixed
  • Status changed from assigned to closed

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.

#6 @gziolo
2 months ago

  • Version changed from 5.8 to trunk

#8 @desrosj
4 weeks ago

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.

Note: See TracTickets for help on using tickets.