Size Change: 0 B

Total Size: 1.83 MB

_{compressed-size-action}

Flaky tests detected in 3d031a4.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/12135432278
📝 Reported issues:

• [Flaky Test] submenu click on the arrow interactions #61884 in /test/e2e/specs/editor/blocks/navigation-frontend-interactivity.spec.js

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.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: gziolo <gziolo@git.wordpress.org>
Co-authored-by: sirreal <jonsurrell@git.wordpress.org>

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

@gziolo Hey did you see the comment: fcee058#r150652268

It's still stopping me from using --hot because none of my blocks use script, editorScript or viewScript.

Testing Instructions
Run npx wp-create-block my-plugin --no-wp-scripts .

The npx wp-create-block didn't work (outdated?), but I did npx @wordpress/create-block my-plugin, edit block.json to remove:

"editorScript": "file:./index.js",
"viewScript": "file:./view.js"

and then in package.json change the script to "start": "wp-scripts start --hot", run, and the result is:

ERROR in Cannot convert undefined or null to object

With --stats=verbose it points to here:

This fixes it:

const fields = getBlockJsonScriptFields( blockJson ) || {};

Also, is it normal that the *.asset.php files have 'handle' => 'undefined-[name]'?

compilation.name seems to be undefined.

Another change in @wordpress/scripts that I must have missed (when upgrading from 30.5.1) is that I need to enqueue the runtime.js file that is generated to build dir myself? Or is there some logic that should do it automatically? Either way, looking at the docs there's no mention of "runtime" at all - maybe something that should be documented.

--hot – enables “Fast Refresh”. The page will automatically reload if you make changes to the code. For now, it requires that WordPress has the SCRIPT_DEBUG flag enabled and the Gutenberg plugin installed.

Is the Gutenberg part still the case? I usually develop without it and occasionally turn it on to check that what I have is "future-compatible" not vice versa. If Gutenberg has some logic for the "runtime" script then maybe that's what I'm missing, but for now I'll just enqueue it myself and seems to work with or without GB.

@gziolo Hey did you see the comment: fcee058#r150652268

No, I missed it.

This fixes it:

const fields = getBlockJsonScriptFields( blockJson ) || {};

Would you like to open PR with a bug fix proposed? You are 100% correct, this is one of the ways to address the case you explained when there are no scripts discovered.

Also, is it normal that the *.asset.php files have 'handle' => 'undefined-[name]'?

No, it needs to get improved. Ideally, it should fallback to some other alternative way to get some more distinct name for the webpack build, or the name of the project defined in package.json.

Another change in @wordpress/scripts that I must have missed (when upgrading from 30.5.1) is that I need to enqueue the runtime.js file that is generated to build dir myself? Or is there some logic that should do it automatically?

It should get enqueued automatically, but there might be some more edge cases as it's nontrivial.

Is the Gutenberg part still the case? I usually develop without it and occasionally turn it on to check that what I have is "future-compatible" not vice versa. If Gutenberg has some logic for the "runtime" script then maybe that's what I'm missing, but for now I'll just enqueue it myself and seems to work with or without GB.

Gutenberg is no longer required. Where does this information come from? The logic for including the runtime is a mix of WordPress core code and the webpack build. First, webpack automatically injects the path to the runtime inside block.json file generated in the `build folder:

In fact, this is where the bug you mentioned needs to be fixed.

The code that registers the webpack runtime and other scripts defined for the block in block.json gets processed here:

https://github.com/WordPress/wordpress-develop/blob/12eaef1dd97ce46d7e665c69764cdae7387b03cc/src/wp-includes/blocks.php#L564-L593