WIP: Update npm packages to latest versions for 6.4 Beta 1

[mikachan]

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

This PR includes changes from #5235 & #5195.

I'm currently seeing the following error:

Running "verify:source-maps" task
Warning: The build/wp-includes/js/dist/sync.js file must not contain a sourceMappingURL. Use --force to continue.

I'm not sure if there are any other missing changes that should be included in this PR - perhaps that's all that's missing for the sync script to run successfully.

---

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.

[luisherranz]

This is a potential fix for the Warning: The build/wp-includes/js/dist/sync.js file must not contain a sourceMappingURL error until you reach @youknowriad for confirmation: luisherranz@e38b785

[luisherranz]

There is a mismatch with the type of files that are enqueued in the frontend. When you run npm run build:dev or npm run dev, the file enqueued for the Interactivity API runtime is the development version (interactivity.js), which is correct, but the files enqueued for the blocks are the production version (view.min.js instead of view.js).

It looks like in trunk the files enqueued for the blocks are also the production version, so it's not something we introduced. But we need to fix it. I'll try to locate where those enqueues happen.

On the other hand, I've manually copied the files and they work fine when they match (both are development or both are production), so the new Webpack configuration seems to have worked well and I don't think we'll need to make any further adjustments.

[luisherranz]

It looks like in trunk the files enqueued for the blocks are also the production version, so it's not something we introduced. But we need to fix it. I'll try to locate where those enqueues happen.

It looks like those files are hardcoded in the block.json:

"viewScript": "file:./view.min.js",

So for the moment, instead of honoring the development/production mode, let's always enqueue the production version of the Interactivity API runtime to match what the blocks are doing.

@mikachan, you can cherry-pick this commit to fix this: luisherranz@facb976

[tellthemachines]

Thanks for getting this started! Looks like we'll need to make a few more changes in Gutenberg and republish the packages. I'm not quite sure why, but removing the sync package and rebuilding is causing neither editor to load in my local env. Can anyone reproduce this?

It looks like those files are hardcoded in the block.json:

These changes will also have to be made in Gutenberg.

[luisherranz]

These two files can be removed now because the view-modal.js file doesn't exist anymore:

• src/wp-includes/blocks/navigation/view-modal.asset.php
• src/wp-includes/blocks/navigation/view-modal.min.asset.php

Apart from that, the new Webpack configuration is adding two unnecessary files to the js/dist folder:

• src/wp-includes/js/dist/interactivity.asset.php
• src/wp-includes/js/dist/interactivity.min.asset.php

I guess it'd be better to delete them. We can do so using this: luisherranz@9ad3846

[mikachan]

Thanks everyone for all the help here.

I think I've cherry-picked all the changes you mentioned, @luisherranz. The sync script is now running successfully 🎉, but I know we need a fresh GB 16.7 RC as well. I can cherry-pick the new GB PRs and trigger a build as soon as all the needed changes are merged.

[tellthemachines]

A couple things still need to be addressed; I'm mostly concerned about the sync package. We should remove it, which will require a few more changes in Gutenberg. Can we hold off on republishing the packages until this is sorted out?

[felixarntz]

One more non-blocking recommendation.

Given the beta timeline, I don't want to hold up this PR, but it would be great to consider this change prior to the next beta.

[felixarntz]

Per my response in #5262 (comment), given we want to avoid exposing this API too much until it's stable, how about we don't register it unconditionally?

We could introduce a function like this:

function _wp_maybe_enqueue_interactivity() {
	if ( wp_script_is( 'wp-interactivity' ) ) {
		return;
	}
	wp_enqueue_script(
		'wp-interactivity',
		'/wp-includes/js/dist/interactivity.min.js',
		array(),
		false,
		array( 'strategy' => 'defer' )
	);
}

That function could then be called in all the blocks where it is needed, and with such an approach the use of the wp-interactivity script would be more obviously discouraged.

[mikachan]

cc. @luisherranz for your thoughts here.

[luisherranz]

Thanks for the ping, @mikachan 🙂

---

given we want to avoid exposing this API too much until it's stable, how about we don't register it unconditionally?

@felixarntz:

1. If your worries are about third-party scripts accessing the exports that are inside of that JavaScript file:

   That file is generated by Webpack as an independent chunk. Only the entry points generated in the same webpack config have the correct auto-generated ID to access those exports.

   I'm happy to explore other additional measures. For example, I also tested a random ID that changes each time Webpack runs, although it didn't feel necessary to me as accessing a private Webpack generated chunk is already very hacky and there's no guarantee that the auto-generated ID won't change either.

2. If your worries are about having a script that sometimes is registered unnecessarily and you would prefer to make sure that it's only registered if it's finally enqueued: sure, we can try to add logic to check for that 🙂

Just let me know and I'll take care of it as soon as possible.

[luisherranz]

Related to the random ID:

• WIP: Update npm packages to latest versions for 6.4 Beta 1 #5262 (comment)

[hellofromtonya]

Closing as https://core.trac.wordpress.org/changeset/56710 has committed the package updates.