Build: Prepare for more Script Modules #7360

sirreal · 2024-09-17T17:49:42Z

Rework the way that Script Modules are registered.

This is a companion to WordPress/gutenberg#65460 that requires porting to Core. Namely, the block-library changes require registration with their updated script module IDs so that the blocks continue to work correctly. This change is safe to land before the block-library package is updated.

"modules" webpack config is renamed "script-modules" aligning with Gutenberg and with the feature name.
Script Module registration is handled in one central place.
A combined assets file is used for Script Modules registration.
Block library Script Module assets that are enqueued on demand are registered in a centralized location. The assets are enqueued on demand. This solves the problem where Gutenberg-specific code is being shipped in Core.
The block library Script Module asset Module IDs are renamed to indicate they are view files and align with the naming from Build: Prepare build for more script modules gutenberg#65064, e.g. @wordpress/block-library/query is now @wordpress/block-library/query/view (indicating it is a view file).

A change landed in Gutenberg anticipating this change. It's essential to name the core function wp_default_script_modules accordingly or update Gutenberg:

https://github.com/WordPress/gutenberg/blob/2632234b2bdd6ef8e8b89e7521d370cfa0041764/lib/client-assets.php#L652

This includes the necessary ports from WordPress/gutenberg#65460.

Why?

Registering Script Modules in several places is messy and difficult to maintain.
Script Modules dependency arrays and versions were manually maintained, which is error prone.
Some block library code included Gutenberg-specific functions and constants which is undesirable.

Testing Instructions

Try out this PR. Interactivity script modules (@wordpress/interactivity and @wordpress/interactivity-router) should be served from the script-modules directory.
I've added and reverted a commit that builds with the expected block-library changes soon to be included from Gutenberg. That specific commit can be used to test the block-library for future proof.

Try enabling and disabling SCRIPT_DEBUG. It should control the use of minified or non-minified assets. @wordpress/interactivity should use its debug version of the script with SCRIPT_DEBUG enabled.

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

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

github-actions · 2024-09-17T18:01:58Z

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

The Plugin and Theme Directories cannot be accessed within Playground.
All changes will be lost when closing a tab with a Playground instance.
All changes will be lost when refreshing the page.
A fresh instance is created each time the link below is clicked.
Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

Avoid registering modules twice. Anticipates changes in WordPress/wordpress-develop#7360

gziolo · 2024-09-20T11:09:59Z

This needs a rebase now after WP packages got synced from Gutenberg.

Rework how Script Modules are registered in Gutenberg. Script Module registration is handled in one central place. A combined assets file is used for Script Modules and registration. This means that dependencies and versions will be used correctly and kept up-to-date while avoiding repeated file reads. Block library Script Module assets that are enqueued on demand _are registered in a centralized location_. The assets are enqueued on demand. **This requires a Core change** since the block library PHP files are synced to Core and also require centralized Script Module registration (WordPress/wordpress-develop#7360). This solves a problem where Gutenberg-specific code was being shipped in Core through block-library. The block library Script Module asset Module IDs are renamed to indicate they are view files and align with the naming from #65064: @wordpress/block-library/query is @wordpress/block-library/query/view (indicating it is a view file). --- This is sufficient to change Script Modules to use Gutenberg in a backwards compatible way: - `@wordpress/ineractivity` and `@wordpress/interactivity-router` were registered on `wp_enqueue_scripts`. That action fires after the `wp_default_scripts` used here. Registering an already registered Script Module is a no-op. This change registers first. - The only other Script Modules currently available in Core are from the block library. Those have been registered conditionally on use. The ID is changed here, so there's little risk of the wrong version being used. There is a Core companion PR that will be necessary to land: WordPress/wordpress-develop#7360 --- Co-authored-by: sirreal <jonsurrell@git.wordpress.org> Co-authored-by: gziolo <gziolo@git.wordpress.org>

- Better modules - Parse wp modules from package.json - Combine asset file

github-actions · 2024-09-20T13:29:51Z

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props jonsurrell, gziolo, wildworks, noisysocks.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

sirreal · 2024-09-20T13:38:36Z

@gziolo I think CI will pass now, this should be ready for review.

src/wp-includes/interactivity-api/class-wp-interactivity-api.php

sirreal · 2024-09-20T16:42:49Z

There are some test failures, it looks like an easy fix from the newly deprecated function:

Unexpected deprecation notice for WP_Interactivity_API::register_script_modules.

gziolo · 2024-09-20T17:35:36Z

There are some test failures, it looks like an easy fix from the newly deprecated function:

Unexpected deprecation notice for WP_Interactivity_API::register_script_modules.

Tests should no longer run these two deprecated methods.

gziolo

This is looking great. I’m happy to give it a round of testing next week. This is cool on many levels: better performance due to fewer disk operations, further automated and abstracted logic, great efficiency in using the asset files.

gziolo · 2024-09-20T17:40:04Z

src/wp-includes/interactivity-api/class-wp-interactivity-api.php

 	 */
 	public function add_hooks() {
-		add_action( 'wp_enqueue_scripts', array( $this, 'register_script_modules' ) );
-		add_action( 'admin_enqueue_scripts', array( $this, 'register_script_modules' ) );
-
 		add_filter( 'script_module_data_@wordpress/interactivity', array( $this, 'filter_script_module_interactivity_data' ) );


I’m not sure if this should still live here. Could get wired in wp_default_script_modules next to handlers for script modules. No strong preferences, though.

Good question. My first thought is that this is specific to Interactivity API and it should manage its script module data filters, but it's true that other script modules may have their data filters added in a more generic place.

I'm inclined to leave it now just because there's no obvious reason to move it now. Maybe in time these core script module data filters should all be registered in one place if there are many of them.

I don't feel strongly one way or another.

sirreal · 2024-09-20T18:58:43Z

@michalczaplinski @DAreRodz @cbravobernal It would be great to test out the Interactivity API on this PR as well as the interactive blocks in the block library.

There's a reverted commit on this branch that can be re-applied to test with new block-library versions as well. The commit message is "Test with block-library assets from Gutenberg" (currently 404336b).

sirreal · 2024-09-20T19:28:08Z

I've started preparing next steps in #7405 to add the a11y script module.

This pulls the block-library assets from: WordPress/gutenberg@2632234

This reverts commit 404336b.

This script module requires an additional change that will be landed separately before it can be landed. See WordPress/gutenberg#65380.

Rework how Script Modules are registered in Gutenberg. Script Module registration is handled in one central place. A combined assets file is used for Script Modules and registration. This means that dependencies and versions will be used correctly and kept up-to-date while avoiding repeated file reads. Block library Script Module assets that are enqueued on demand _are registered in a centralized location_. The assets are enqueued on demand. **This requires a Core change** since the block library PHP files are synced to Core and also require centralized Script Module registration (WordPress/wordpress-develop#7360). This solves a problem where Gutenberg-specific code was being shipped in Core through block-library. The block library Script Module asset Module IDs are renamed to indicate they are view files and align with the naming from #65064: @wordpress/block-library/query is @wordpress/block-library/query/view (indicating it is a view file). --- This is sufficient to change Script Modules to use Gutenberg in a backwards compatible way: - `@wordpress/ineractivity` and `@wordpress/interactivity-router` were registered on `wp_enqueue_scripts`. That action fires after the `wp_default_scripts` used here. Registering an already registered Script Module is a no-op. This change registers first. - The only other Script Modules currently available in Core are from the block library. Those have been registered conditionally on use. The ID is changed here, so there's little risk of the wrong version being used. There is a Core companion PR that will be necessary to land: WordPress/wordpress-develop#7360 --- Co-authored-by: sirreal <jonsurrell@git.wordpress.org> Co-authored-by: gziolo <gziolo@git.wordpress.org> Source: WordPress/gutenberg@2632234

Rework how Script Modules are registered in Gutenberg. Script Module registration is handled in one central place. A combined assets file is used for Script Modules and registration. This means that dependencies and versions will be used correctly and kept up-to-date while avoiding repeated file reads. Block library Script Module assets that are enqueued on demand _are registered in a centralized location_. The assets are enqueued on demand. **This requires a Core change** since the block library PHP files are synced to Core and also require centralized Script Module registration (WordPress/wordpress-develop#7360). This solves a problem where Gutenberg-specific code was being shipped in Core through block-library. The block library Script Module asset Module IDs are renamed to indicate they are view files and align with the naming from #65064: @wordpress/block-library/query is @wordpress/block-library/query/view (indicating it is a view file). --- This is sufficient to change Script Modules to use Gutenberg in a backwards compatible way: - `@wordpress/ineractivity` and `@wordpress/interactivity-router` were registered on `wp_enqueue_scripts`. That action fires after the `wp_default_scripts` used here. Registering an already registered Script Module is a no-op. This change registers first. - The only other Script Modules currently available in Core are from the block library. Those have been registered conditionally on use. The ID is changed here, so there's little risk of the wrong version being used. There is a Core companion PR that will be necessary to land: WordPress/wordpress-develop#7360 --- Co-authored-by: sirreal <jonsurrell@git.wordpress.org> Co-authored-by: gziolo <gziolo@git.wordpress.org> Source: WordPress/gutenberg@8488c64

noisysocks · 2024-09-23T04:04:14Z

Nice work here, thanks. Quick reminder that deadline to commit this backport is 6.7 Beta 1 which is scheduled for 1 October.

gziolo

Code-wise this looks great, and it mirrors how regular scripts are handled. Fantastic job on that front. This is what I see on disk after running npm run build:dev:

trunk

This branch:

I did some smoke tests and at least the expand on click for the Image block continues to work as before.

gziolo · 2024-09-23T12:16:36Z

src/wp-includes/script-modules.php

+		 *   - interactivity/index.min.js  => @wordpress/interactivity
+		 *   - interactivity/debug.min.js  => @wordpress/interactivity/debug
+		 *   - block-library/query/view.js => @wordpress/block-library/query/view


I'm wondering if these paths are the same on Windows. The challenge is that for regular scripts, the path contains only the file name. In this case, it's also folders so let's confirm that there isn't block-library\query\view.js or something like that. This would mean script-modules-packages.min.php under version control differs between operating systems.

Maybe @t-hamano could help with that like in WordPress/gutenberg#65064 (comment).

After npm run build, here's what's expected at build/wp-includes/js/dist/script-modules

# tree build/wp-includes/js/dist/script-modules build/wp-includes/js/dist/script-modules ├── block-library │ ├── file │ │ ├── view.js │ │ └── view.min.js │ ├── image │ │ ├── view.js │ │ └── view.min.js │ ├── navigation │ │ ├── view.js │ │ └── view.min.js │ ├── query │ │ ├── view.js │ │ └── view.min.js │ └── search │ ├── view.js │ └── view.min.js ├── interactivity │ ├── debug.js │ ├── debug.min.js │ ├── index.js │ └── index.min.js └── interactivity-router ├── index.js └── index.min.js 9 directories, 16 files

I tested this PR on a Windows host OS. From my understanding, build:dev does not generate a build directory, but generates some directories in the src directory. On the other hand, the build command generates a complete WordPress in the build directory.

In both commands, the script-modules-packages.min.php file contains only forward slashes.

npm run build:dev

npm run build

I then replaced the core files in my local WordPress environment on my Windows host OS with the files built in this PR.

The image lightbox works and scripts seem to be enqueued correctly. The navigation block works fine too.

Thank you 👍

In both commands, the script-modules-packages.min.php file contains only forward slashes.

Perfect, so that file should be stable across different systems and working correctly 👌

@t-hamano, thank you so much for testing and confirming it works the same on Windows.

gziolo · 2024-09-24T07:34:54Z

Committed with https://core.trac.wordpress.org/changeset/59083.

sirreal mentioned this pull request Sep 18, 2024

Script Modules: Centralize (re)registration WordPress/gutenberg#65460

Merged

sirreal added a commit to WordPress/gutenberg that referenced this pull request Sep 19, 2024

Replace WP modules action with GB modules

62c105e

Avoid registering modules twice. Anticipates changes in WordPress/wordpress-develop#7360

sirreal added a commit to WordPress/gutenberg that referenced this pull request Sep 19, 2024

Replace WP modules action with GB modules

ee5535f

Avoid registering modules twice. Anticipates changes in WordPress/wordpress-develop#7360

sirreal added a commit to WordPress/gutenberg that referenced this pull request Sep 20, 2024

Replace WP modules action with GB modules

f5b783e

Avoid registering modules twice. Anticipates changes in WordPress/wordpress-develop#7360

sirreal added a commit to WordPress/gutenberg that referenced this pull request Sep 20, 2024

Replace WP modules action with GB modules

cb3a31b

Avoid registering modules twice. Anticipates changes in WordPress/wordpress-develop#7360

github-actions bot mentioned this pull request Sep 20, 2024

PHP backports for WP 6.7 WordPress/gutenberg#63827

Open

sirreal added 8 commits September 20, 2024 15:07

Prepare build for more script modules

d6de7d0

Redo script modules build

54476a9

- Better modules - Parse wp modules from package.json - Combine asset file

Register scripts from asset file

17e7dbc

Work on centralized script module registration

bdd5123

Remove redundant case

a3011f4

Fix interactivity-api deprecation note

b207015

Rename "modules" webpack to "script-modules"

b2547a2

Update script module loading code

502f146

sirreal force-pushed the build/prepare-more-script-modules branch from 6760209 to 3656c5b Compare September 20, 2024 13:29

sirreal marked this pull request as ready for review September 20, 2024 13:29

sirreal commented Sep 20, 2024

View reviewed changes

src/wp-includes/interactivity-api/class-wp-interactivity-api.php Outdated Show resolved Hide resolved

sirreal commented Sep 20, 2024

View reviewed changes

src/wp-includes/interactivity-api/class-wp-interactivity-api.php Outdated Show resolved Hide resolved

gziolo reviewed Sep 20, 2024

View reviewed changes

sirreal mentioned this pull request Sep 20, 2024

Add @wordpress/a11y script module #7405

Closed

sirreal added 10 commits September 20, 2024 21:33

Use buildTarget in assets path

1f65609

Update script modules assets

96a28a8

Prettier webpack config file

d2317ab

Test with block-library assets from Gutenberg

fb04163

This pulls the block-library assets from: WordPress/gutenberg@2632234

Revert "Test with block-library assets from Gutenberg"

47524d4

This reverts commit 404336b.

Remove a11y script module

02deb22

This script module requires an additional change that will be landed separately before it can be landed. See WordPress/gutenberg#65380.

Prevent deletion of script-modules-packages.min.php by grunt

7047c60

Fix function name in deprecation notices

92aa6f9

Remove debug code

d864449

Test deprecation

7836320

sirreal requested a review from gziolo September 20, 2024 21:20

sirreal force-pushed the build/prepare-more-script-modules branch from f2715ab to 7836320 Compare September 20, 2024 21:24

gziolo approved these changes Sep 23, 2024

View reviewed changes

gziolo added the props-bot Adding this label triggers the Props Bot workflow for a PR. label Sep 24, 2024

github-actions bot removed the props-bot Adding this label triggers the Props Bot workflow for a PR. label Sep 24, 2024

gziolo closed this Sep 24, 2024

sirreal deleted the build/prepare-more-script-modules branch September 24, 2024 09:33

This was referenced Sep 24, 2024

Interactivity Router: Update for latest GB changes. #7304

Closed

Script Modules: Implement script interoperability #6239

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Build: Prepare for more Script Modules #7360

Build: Prepare for more Script Modules #7360

sirreal commented Sep 17, 2024 •

edited

Loading

github-actions bot commented Sep 17, 2024

gziolo commented Sep 20, 2024

github-actions bot commented Sep 20, 2024 •

edited

Loading

sirreal commented Sep 20, 2024

sirreal commented Sep 20, 2024

gziolo commented Sep 20, 2024

gziolo left a comment

gziolo Sep 20, 2024 •

edited

Loading

sirreal Sep 20, 2024

sirreal commented Sep 20, 2024 •

edited

Loading

sirreal commented Sep 20, 2024

noisysocks commented Sep 23, 2024

gziolo left a comment

gziolo Sep 23, 2024

sirreal Sep 23, 2024

t-hamano Sep 23, 2024

sirreal Sep 23, 2024

gziolo Sep 24, 2024

gziolo commented Sep 24, 2024

Build: Prepare for more Script Modules #7360

Build: Prepare for more Script Modules #7360

Conversation

sirreal commented Sep 17, 2024 • edited Loading

Why?

Testing Instructions

github-actions bot commented Sep 17, 2024

Test using WordPress Playground

Some things to be aware of

gziolo commented Sep 20, 2024

github-actions bot commented Sep 20, 2024 • edited Loading

sirreal commented Sep 20, 2024

sirreal commented Sep 20, 2024

gziolo commented Sep 20, 2024

gziolo left a comment

Choose a reason for hiding this comment

gziolo Sep 20, 2024 • edited Loading

Choose a reason for hiding this comment

sirreal Sep 20, 2024

Choose a reason for hiding this comment

sirreal commented Sep 20, 2024 • edited Loading

sirreal commented Sep 20, 2024

noisysocks commented Sep 23, 2024

gziolo left a comment

Choose a reason for hiding this comment

gziolo Sep 23, 2024

Choose a reason for hiding this comment

sirreal Sep 23, 2024

Choose a reason for hiding this comment

t-hamano Sep 23, 2024

Choose a reason for hiding this comment

sirreal Sep 23, 2024

Choose a reason for hiding this comment

gziolo Sep 24, 2024

Choose a reason for hiding this comment

gziolo commented Sep 24, 2024

sirreal commented Sep 17, 2024 •

edited

Loading

github-actions bot commented Sep 20, 2024 •

edited

Loading

gziolo Sep 20, 2024 •

edited

Loading

sirreal commented Sep 20, 2024 •

edited

Loading