Block supports: value changes on block.json not reflected in block store after watch task runs

[glendaviesnz]

Currently when making changes individual blocks metadata in block.json, the change is picked up by the dev watch process, and the change can be seen if logged out in the blocks index.js file at the point the block is being registered, but the change doesn't get reflected in the core/blocks store unless the dev watch process is restarted.

This means that changes to the block.json support settings can't be easily tested without restarting the dev task after each change.

To replicate

• Start the npm run dev process and run plugin in local dev env
• Add a Group block and check that the Dimensions panel shows in the settings panel
• Set the Group blocks block.json supports setting for padding to false
• Reload the browser and see that the Dimensions panel still shows
• Stop and restart the dev task
• Reload the browser and notice that the Dimensions panel is now not displaying
• You could also repeat the above with any of the block metadata, but the above example is visible on UI and saves inspecting the store

Expected behaviour

Changes to block.json support settings are reflected in the local dev env after watch process has detected the change

[talldan]

It seems like this regressed in the last day, because initially I tested using a slightly outdated version of trunk (7479921), and it works ok with that commit. #33818 is the only change to the build process since then.

To describe how watch works, my understanding is that there are the following steps that make up the watch task:

• watch.js watches particular files in packages for changes. When there's a change it triggers build.js passing it the changed files.
• build.js does some tracing of entry points for block.json and stylesheets (if block.json is changed, the block's index.js needs to be rebuilt). Once the right files to rebuild are known, build-worker.js is triggered.
• build-worker.js fires the right kind of build process for the file type (e.g. scss for stylesheets, babel for js) and builds the library code for packages (the contents of each package's build/build-module/build-style folders).
• Webpack watch (which is also running) detects the changes for package build code, and builds the Gutenberg 'application' in the root build folder.

In the console, it looks like webpack triggers ok, so it definitely gets through to that final stage.

[gziolo]

I wouldn't be surprised if webpack v5 impacted that. I tested JS and CSS and watch mode but I forgot about block.json that has magical handling 😅

I did a quick test and I think that I know where the issue is. I added the following line to packages/block-library/src/group/block.json:

	"attributes": {
+		"foo": "bar",
		"tagName": {

JavaScript file gets correctly updated by webpack:

However, the build/block-library/group/block.json file that is loaded by the server doesn't update:

The issue is with CopyWebpackPlugin. It triggers only when CSS or JavaScript changes are made. The same issue exists for PHP files used with core blocks.

[walbo]

Seems like it has to do with watchOptions.ignores in wepack.

Currently all files in src are ignored. This is fine for the .js and .scss files because they are build to build and build-style outside of src before webpack picks them up.

Created a PR (#34024) to only ignore files handled by the build script.