Make WordPress Core

Opened 3 years ago

Closed 3 years ago

Last modified 2 years ago

#53690 closed enhancement (fixed)

Build: Split packages and blocks to their webpack configs

Reported by: gziolo's profile gziolo Owned by: gziolo's profile gziolo
Milestone: 5.9 Priority: normal
Severity: normal Version: 5.9
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 (10)

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


3 years ago
#1

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

gziolo commented on PR #1412:


3 years ago
#2

@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 commented on PR #1412:


3 years ago
#3

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

gziolo commented on PR #1412:


3 years ago
#4

@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
3 years 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
3 years ago

  • Version changed from 5.8 to trunk

#8 @desrosj
3 years 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.

#9 @gziolo
3 years ago

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.

#10 @SergeyBiryukov
2 years ago

#53565 was marked as a duplicate.

Note: See TracTickets for help on using tickets.