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

Currently not working: after installing, there's an error while running the build:js task:

Running "jsvalidate:build" (jsvalidate) task
Validating src/wp-includes/js/media-audiovideo.js  
>> Line 1: Unexpected token )
Validating src/wp-includes/js/media-audiovideo.min.js  
>> Line 1: Unexpected token )
Validating src/wp-includes/js/media-grid.js  
>> Line 1: Unexpected token )
Validating src/wp-includes/js/media-grid.min.js  
>> Line 1: Unexpected token )
Validating src/wp-includes/js/media-models.js  
>> Line 1: Unexpected token )
Validating src/wp-includes/js/media-models.min.js  
>> Line 1: Unexpected token )
Validating src/wp-includes/js/media-views.js  
>> Line 1: Unexpected token )
Validating src/wp-includes/js/media-views.min.js  
>> Line 1: Unexpected token )
Encountered 16 errors.
Warning: Task "jsvalidate:build" failed. Use --force to continue.

I'm not sure if anything should be updated in the webpack config, as the files flagged are built with webpack.

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

Alternative to #4698. Updates the @wordpress npm packages without updating browserslist, to avoid the errors from the other PR.

PHP unit tests are failing because #4624 hasn't been committed yet.

I'm running into an issue that seems to be related to the framer-motion dependency of @wordpress/components: both the post and site editor crash when a popover is opened. Not entirely sure why this is happening yet.

Can we instead of avoiding to update browser list, remove that jsvalidation? Why are we validating built/ignored files anyway, maybe it's just a matter of excluding that js folder from some validation command or else, updating the validation rules to be inline with the latest supported browsers.

@tellthemachines This PR will be blocked by ​https://github.com/WordPress/wordpress-develop/pull/4152. Becasue of upstream changes. Please review this PR, I will commit and we can continue.

Related: #58628

Why are we validating built/ignored files anyway...

@youknowriad I was just asking myself this same question when I came across your comment here. From what I can tell this old validation process has become more of a hinderance than a help to our process over the last few releases. Now that it's no longer a maintained library, it may be time to eliminate it completely. Would appreciate you weighing in on ​the related conversation in Slack.

It seems like is not in this change. ​https://github.com/WordPress/gutenberg/pull/51866

It is needed now ​https://github.com/WordPress/wordpress-develop/commit/d8409a205a40a9c5a69d668a9aa2aa3123f4c3e5 is core.

Sync scripts have been updated and committed over at: ​https://github.com/WordPress/wordpress-develop/pull/4699

It seems like is not in this change. ​https://github.com/WordPress/gutenberg/pull/51866

As far as I know, that PR is marked for backporting to the 16.2RC, which will get backported to core after these packages.

Not sure if it's relevant, but if the sync script is blocked by the deprecated nux package, @ockham ​says:

I guess one workaround -- to unblock the sync script -- would be to add the wp-6.3 dist tag to the latest existing @wordpress/nux package; but I'm not sure if that's possible for a deprecated npm 🤔

Otherwise, I guess we'll have to remove the dependency before running the sync script, and then add it back afterwards

The changes for the @wordpress/block-serialization-default-parser packages include splitting the block parser PHP classes in to separate files in order to follow the WP coding standards and (at a future date) allow for the use of an auto-loader, see #57832.

In order to maintain the history of the relocated classes, an svn copy will need to be done so @isabel_brison and I are coordinating to do that package on a separate commit.

In 56048:

Not sure if it's relevant, but if the sync script is blocked by the deprecated nux package, @ockham ​says:

The problem isn't the nux package (or that might be _a_ problem, but it's not the main one). It's that ​some packages were published last week and the versions don't seem to have been updated on trunk, so the version bump from the publishing yesterday is actually a lower version than last weeks for some packages. Afaict the sync task picks up the highest version from npm, so it's picking up the wrong versions for a bunch of packages.

Can we instead of avoiding to update browser list, remove that jsvalidation?

I'm fine with doing that, but unless we have any volunteers to get it done in the next few hours, let's leave it until after Beta 1. The priority now is updating the npm packages.

I've been smoke testing GB 16.1 features and ​bugfixes.

Things are looking stable! 🙇

I guess we need to commit a few backports to get the unit tests passing (?)

Converting to a task as this can ship after beta 1 is released.

In 56065:

Committed in https://core.trac.wordpress.org/changeset/56065.

Follow-up to ​https://github.com/WordPress/wordpress-develop/pull/4699 / r56065.

Includes ​https://github.com/WordPress/gutenberg/pull/51978, which fixes the following fatal error:

Fatal error: Uncaught Error: Class 'WP_Navigation_Fallback_Gutenberg' not found

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

Activating Gutenberg v16.0.0 alongside this PR seems to result in a fatal error:

Fatal error: Cannot declare class WP_REST_Navigation_Fallback_Controller, because the name is already in use in /var/www/src/wp-content/plugins/gutenberg/lib/experimental/class-wp-rest-navigation-fallback-controller.php on line 0

Yay for name collisions. Looks like we'll need another round of npms 😕

Yay for name collisions. Looks like we'll need another round of npms 😕

CC @getdave

What about this Gutenberg reference:

​https://github.com/WordPress/wordpress-develop/blob/87a0ad45a51a0294b9056a06f7fcb15082b7ff3b/src/wp-includes/blocks/navigation-submenu.php#L204

I don't see that file updated here.

Activating Gutenberg v16.0.0 alongside this PR seems to result in a fatal error:

Fatal error: Cannot declare class WP_REST_Navigation_Fallback_Controller, because the name is already in use in /var/www/src/wp-content/plugins/gutenberg/lib/experimental/class-wp-rest-navigation-fallback-controller.php on line 0

Yay for name collisions. Looks like we'll need another round of npms 😕

Ah, interesting. Looks like those collisions have been fixed in GB trunk already — they’re just not present in the current stable version (16.0.0). They will be in 16.1.0, which I believe is scheduled for tomorrow 🤔 : (I’ve confirmed that a GB plugin built from current trunk doesn’t fatal upon activation.)

What about this Gutenberg reference:

​https://github.com/WordPress/wordpress-develop/blob/87a0ad45a51a0294b9056a06f7fcb15082b7ff3b/src/wp-includes/blocks/navigation-submenu.php#L204

I don't see that file updated here.

I'll look into this.

Sidenote, I guess we could really use something like this 😅

What about this Gutenberg reference:
​https://github.com/WordPress/wordpress-develop/blob/87a0ad45a51a0294b9056a06f7fcb15082b7ff3b/src/wp-includes/blocks/navigation-submenu.php#L204

I don't see that file updated here.

I'll look into this.

PR: ​https://github.com/WordPress/gutenberg/pull/51989

Thank you for reviewing/approving, folks!

As stated in Slack:

Since the tests on ​this PR are failing (​probably because Core trunk​is currently in a broken state), I’m considering only landing [this PR right here] for now (which should unbreak Core) and leave the rest for Beta 2. How does that sound? (It should shave off at least another hour of work for now; whereas landing [this PR] should be a matter of a few minutes only.)

Re-opening to fix a fatal error.

In 56076:

Committed to Core in https://core.trac.wordpress.org/changeset/56076/.

Sidenote, I guess we could really use something like this 😅

I'll add it to a list that I might never return to. I agree though. I'm sure this has been a problem before

thanks @ockham

I made a mistake when writing the commit message, so a number of changes that go beyond the npm packages version update aren't documented there. I'll cover those here instead:

• Amend the replace:source-maps Grunt task to remove source map URLs (added by react-spring) from the block-editor build that would otherwise be flagged by the verify:source-maps task.
• Modify the copy:block-json Grunt task to include line breaks (and indentation) in the block-json.php file it generates, as that file was rejected by a pre-commit SVN hook on the server due to all of its contents being on just one line.
• Rewrite a number of calls to str_contains and str_ends_with, which are only available in PHP 8+ and are polyfilled by WordPress for earlier PHP versions, as some of them are called even before WordPress' compat layer is loaded, thus leading to fatals on earlier PHP versions.

block_core_navigation_submenu_build_css_colors was deprecated in ​https://github.com/WordPress/gutenberg/pull/48936 in favour of wp_apply_colors_support

This commit adds a deprecation to core.

See comment: ​https://github.com/WordPress/wordpress-develop/pull/4699/files#r1243172213

Props to @peterwilsoncc

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

In 56126:

Committed in r56126 / ​ab9d5e3

This commit inadvertently changed uuid version from 9.0.0 to 8.3.2
It was previously updated in [54296]

In 56065:

Editor: update Wordpress npm packages.

Updates the wordpress npm packages and their dependencies to the latest versions, as well as auto-updates to relevant core PHP files.

Props youknowriad, joemcgill, spacedmonkey, ramonopoly, peterwilsoncc, bernhard-reiter, tyxla, dmsnell.
Fixes #58623.

Nice catch & triaging @hareesh-pillai, I see that @audrasjb referenced that there are "several upcoming commits" but not seeing a PR/patch that lines up with that. @bernhard-reiter @isabel_brison is there something pending here? Do you / someone need help to get that ready for review/commit?

uuid hasn't been updated back to 9.0.0 in trunk so we should still fix that. I can put up a quick PR.

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

Reverts the accidental downgrade of uuid in r56065.

Thanks for the PR! Approved for commit and backport.

In 56350:

In 56351:

Committed to trunk in r56350 and 6.3 in r56351.