Editor: Add missing support for script handles in asset files for blocks

[gziolo]

In the [documentation for WPDefinedAsset definition](​https://developer.wordpress.org/block-editor/reference-guides/block-api/block-metadata/#wpdefinedasset) for block metadata there is a note about handle:

handle (string) – the name of the script. If omitted, it will be auto-generated.

We never implemented it, but it would be very useful for block authors. One of the limitations of the way scripts get registered for blocks is that whenever a single file needs to be shared between blocks, then it has to be registered using wp_register_script separately, and the script handle used needs to be passed to one of the script fields in block.json: editorScript, script or viewScript. It would be great if we could pass the predictable script handle in the .asset.php file so you could still use local paths in block.json and the rest would get automatically handled by WordPress core. In effect, the logic proposed would read the script handle from the asset file and ensure that all other occurrences reuse the script that is already registered under the same name. It would open the possibility to have firs-class support for shared chunks or runtimes generated by bundlers like webpack.

• Part of ​https://github.com/WordPress/gutenberg/issues/2768.

---

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

One of the limitations of the way scripts get registered for blocks is that whenever a single file needs to be shared between blocks, then it has to be registered using wp_register_script separately, and the script handle used needs to be passed to one of the script fields in block.json: editorScript, script or viewScript. It would be great if we could pass the predictable script handle in the .asset.php file so you could still use local paths in block.json and the rest would get automatically handled by WordPress core. In effect, the logic proposed would read the script handle from the asset file and ensure that all other occurrences reuse the script that is already registered under the same name. It would open the possibility to have firs-class support for shared chunks or runtimes generated by bundlers like webpack.

My initial goal was to find a way to enable runtime chunk for @wordpress/scripts in development mode and automatically register it in WordPress core to ensure that React Fast Refresh works correctly with more than one block as summarized in ​https://github.com/WordPress/gutenberg/issues/25188#issuecomment-1104898123.

However, I figured out that we could also use the exact mechanism with any shared chunk that @jsnajdr made possible in the first place with ​https://github.com/WordPress/gutenberg/pull/41002 by improving asset file generation in the webpack plugin that handles dependencies for WP core.

---

Note: This work, if we agree it's the good direction, is going to require follow-up changes (not a blocker for this patch) to the @wordpress/dependency-extraction-webpack-plugin, example build/shared-script.js:

<?php

return array(
        'handle'       => 'my-plugin-shared-script',
        'dependencies' => array(),
        'version'      => 'test',
);

My initial thinking is that we can auto-generate the script handle based on the combination of the name of the webpack config or the project, plus the sanitized path of the entry file relative to the build folder:

'my-plugin' + '-' + 'shared-script'

[gziolo]

@youknowriad, I’d like to land it before 6.5 Beta 1 if you don’t raise any concerns.

The reasoning makes sense. I wanted to mention that we could potentially be smarter and check whether multiple blocks refer to the same file even If the handle is not specified and just use the same generated or uuid handle as well.

@jsnajdr The remark about the build changing the path from "source" to "built" is relevant but I'd also compare it to "package.json".

In "package.json", you don't define a path the "source" file, you only define a path to the "built" files (main, module, exports), so while it's indeed a bit confusing, I think not targeting the source file can be a good thing because you don't really know how the "source" file is written: is it typescript, it it jsx, .... so unless it's normalized, it's not entirely clear why you should point to it from a declarative file like block.json.

I wanted to mention that we could potentially be smarter and check whether multiple blocks refer to the same file even If the handle is not specified and just use the same generated or uuid handle as well.

I will explore that further, as that would be indeed a nice addition. The biggest question for me is how much processing would be required to detect the same paths because scripts are stored with handles as keys.

[gziolo]

In 57590:

Blocks: Allow reading the script handle from asset files

In the [documentation for WPDefinedAsset definition](​https://developer.wordpress.org/block-editor/reference-guides/block-api/block-metadata/#wpdefinedasset) for block metadata there is a note about the handle. That was missing in WordPress core.

Props gziolo, jsnajdr, youknowriad.
Fixes #60485.

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