Update packages for 6.8 Beta 1 #8224

Mamaduka · 2025-01-30T12:34:03Z

A list of known issues:

Edit Site: Fix Fields package private APIs error gutenberg#68964

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

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.

github-actions · 2025-01-30T12:34:19Z

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.

Core Committers: Use this line as a base for the props when committing in SVN:

Props mamaduka, joemcgill, youknowriad, swissspidy, sergiomdgomes.

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

joemcgill

Thanks @Mamaduka! Doing some initial testing to ensure nothing obvious is broken, but no initial big red flags from me.

I see that this sync is including several new __experimental… settings, like __experimentalBorder and continues the use of existing __experimentalDefaultControls settings.

I've not been involved in these syncs in the past, but was under the impression that we were attempting to move away from shipping these kinds of features under the __experimental… prefix. Am I mistaken? Regardless, I don't think that's a blocker for this sync, since those settings could be stabilized to remove the prefix, or removed entirely prior to shipping a final release. I mainly want to make sure I understand your expectations for how this is meant to work.

joemcgill · 2025-01-30T18:04:54Z

tools/webpack/shared.js

+	'@wordpress/dataviews/wp',
 	'@wordpress/icons',
 	'@wordpress/interface',
 	'@wordpress/interactivity',
 	'@wordpress/sync',
+	'@wordpress/undo-manager',
+	'@wordpress/upload-media',
+	'@wordpress/fields',


Noting the new packages being bundled and their purpose in the commit message would probably be a good idea.

Noted! Only @wordpress/upload-media is the new package here; it looks like we missed synchronization of this config in past releases.

I'll double-check new values here before this is committed.

@youknowriad, can I get a sanity check here? Do I need to include @wordpress/data views/wp here? It seems to be a plugin-specific package.

Important note If you're trying to use the DataViews component in a WordPress plugin or theme and you're building your scripts using the @wordpress/scripts package, you need to import the components from @wordpress/dataviews/wp instead of @wordpress/dataviews.

No need, but it won't have any impact anyway.

joemcgill · 2025-01-30T18:05:52Z

tests/phpunit/includes/unregister-blocks-hooks.php

@@ -56,6 +56,7 @@
 remove_action( 'init', 'register_block_core_query_pagination_numbers' );
 remove_action( 'init', 'register_block_core_query_pagination_previous' );
 remove_action( 'init', 'register_block_core_query_title' );
+remove_action( 'init', 'register_block_core_query_total' );


👍🏻 New action being added to register the new core/query-total block.

Mamaduka · 2025-01-30T18:40:48Z

I've not been involved in these syncs in the past, but was under the impression that we were attempting to move away from shipping these kinds of features under the __experimental… prefix.

@joemcgill, that only applies to JS API. The block.json is a configuration file that can't have private APIs, hence the __experimental prefixes. They're and will be backward compatible.

joemcgill · 2025-01-30T19:09:04Z

Thanks for clarifying! Do we have any documentation or best practice for why and when to use those prefixes for block.json features? If they are intended to be backward compatible, should we be looking to remove these prefixes?

Mamaduka · 2025-01-30T19:17:23Z

These aren't new configuration values; they just got enabled for those blocks. When those features are stable, we usually create iteration issues like #64314 and stabilize the keys.

I don't recall any official docs, but it is probably worth documenting.

joemcgill

I was able to reproduce the error with the @wordpress/fields package, noted in the PR description.

I'm also seeing the following, which makes the site editor unusable currently.

Uncaught TypeError: Cannot read properties of undefined (reading 'initializeEditor')
    at HTMLDocument.<anonymous> (site-editor.php:2369:16)

I'm adding request changes until we're confident in these being resolved in a way that doesn't totally block the site editor from being usable in trunk

To reproduce:

Check out this PR
Run npm i && npm run build:dev
Visit the site editor with no other plugins activated

Mamaduka · 2025-02-05T07:34:53Z

Updated packages to fix private API errors breaking the Site Editor (WordPress/gutenberg#68964). It should be working correctly now.

Remaining issues:

I noticed the "Go to the Dashboard" buttons don't work in the Site Editor. It requires changes to block editor settings from Site Editor: Redirect old urls to the new path based ones #7903. I can cherry-pick them in this PR to unblock merging.
~~Some JavaScript CI tests fail due to this warning.~~

Screeenshot

Mamaduka · 2025-02-05T08:10:14Z

Gruntfile.js

@@ -1663,6 +1663,7 @@ module.exports = function(grunt) {
 	grunt.registerTask( 'verify:source-maps', function() {
 		const ignoredFiles = [
 			'build/wp-includes/js/dist/components.js',
+			'build/wp-includes/js/dist/data.js',


I think this should be okay; the sourceMappingURL in this package build doesn't cause 404 errors.

The recent update of the Redux package might have introduced the sourceMappingURL change. See: WordPress/gutenberg#66966.

github-actions · 2025-02-05T08:20:19Z

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

The Plugin and Theme Directories cannot be accessed within Playground.
All changes will be lost when closing a tab with a Playground instance.
All changes will be lost when refreshing the page.
A fresh instance is created each time the link below is clicked.
Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

Mamaduka · 2025-02-05T08:34:29Z

It looks like wp-polyfill has been reintroduced as a dependency, which causes the test_wp_add_inline_script_before_after_concat_with_core_dependency unit test to fail. It was initially removed via https://core.trac.wordpress.org/ticket/60962.

@swissspidy, any suggestions on how to approach this?

swissspidy · 2025-02-05T10:51:34Z

Hmm good question, I wonder what caused this.

Last time this topic came up was in WordPress/gutenberg#66552 and WordPress/gutenberg#67230

A quick test here shows that wp-polyfill is now suddenly a dependency of wp-i18n, hence this unit test is failing with the new diff.

I thought with WordPress/gutenberg#65292 / WordPress/gutenberg#65582 the wp-polyfill dependency should only be added when needed.

Tinkering with the Gutenberg package build process I see that the i18n package now tries to load these two polyfills for iterator helpers (which are currently not supported by Safari) in create-i18n.js:

import "core-js/modules/esnext.iterator.constructor.js";
import "core-js/modules/esnext.iterator.for-each.js";

And that's why ultimately the wp-polyfill dependency is added.

create-i18n.js uses new Set() and Set.forEach(), so that's why. But those are supported in Safari, so adding the iterator polyfills is incorrect.

I wonder if we should do something like WordPress/gutenberg#67230 but for Iterator. That would solve this issue. cc @sgomes

Related: it can't hurt to update Babel & core-js to the latest versions in the Gutenberg repo, as this will affect polyfills too.

sgomes · 2025-02-05T11:10:23Z

The reason why polyfills are being added unnecessarily is due to fundamental limitations in core-js, the JS polyfill library that we use to make wp-polyfill, and which is used by Babel as well. In a nutshell, it's monolithic where it comes to objects like Set, and assumes that if a Set object is present anywhere, it's going to need all its methods, and therefore all the internal dependencies it uses to polyfill them.

This was likely caused by a core-js update that added new functionality, perhaps WordPress/gutenberg#67708?

sgomes · 2025-02-05T11:14:20Z

To follow up on the above, the aforementioned Gutenberg PR updated core-js to version 3.39, which according to the project changelog added the Iterator functionality, so we have our smoking gun.

@gziolo: Would it be worth it to replicate the unit test that's failing here (test_wp_add_inline_script_before_after_concat_with_core_dependency) at the Gutenberg level, so that we catch these situations in the Gutenberg repo, before they make their way to Core?

Mamaduka · 2025-02-05T12:54:56Z

Thanks, @swissspidy, @sgomes.

So, for now, would the proposed resolution be something similar to WordPress/gutenberg#67230?

swissspidy · 2025-02-05T12:59:34Z

In that case I would say so, yes.

Adding a unit test or CI check for this stuff would be nice for sure.

Mamaduka requested review from desrosj and joemcgill January 30, 2025 15:34

joemcgill reviewed Jan 30, 2025

View reviewed changes

joemcgill requested changes Jan 30, 2025

View reviewed changes

Mamaduka added 3 commits February 5, 2025 11:14

Update packages for 6.8 Beta 1

ba3d970

Sync BUNDLED_PACKAGES webpack config

b5cb7a2

Update packages with bugfix release

e64d778

Mamaduka force-pushed the try/initial-package-update-6-8 branch from bd2d325 to e64d778 Compare February 5, 2025 07:26

Don't verify source maps for data package build

72d2d21

Mamaduka commented Feb 5, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update packages for 6.8 Beta 1 #8224

Update packages for 6.8 Beta 1 #8224

Mamaduka commented Jan 30, 2025 •

edited

Loading

github-actions bot commented Jan 30, 2025 •

edited

Loading

joemcgill left a comment

joemcgill Jan 30, 2025

Mamaduka Jan 30, 2025

Mamaduka Feb 5, 2025

youknowriad Feb 5, 2025

joemcgill Jan 30, 2025

Mamaduka commented Jan 30, 2025

joemcgill commented Jan 30, 2025

Mamaduka commented Jan 30, 2025

joemcgill left a comment •

edited

Loading

Mamaduka commented Feb 5, 2025 •

edited

Loading

Mamaduka Feb 5, 2025

github-actions bot commented Feb 5, 2025

Mamaduka commented Feb 5, 2025

swissspidy commented Feb 5, 2025

sgomes commented Feb 5, 2025

sgomes commented Feb 5, 2025

Mamaduka commented Feb 5, 2025

swissspidy commented Feb 5, 2025

Update packages for 6.8 Beta 1 #8224

Are you sure you want to change the base?

Update packages for 6.8 Beta 1 #8224

Conversation

Mamaduka commented Jan 30, 2025 • edited Loading

github-actions bot commented Jan 30, 2025 • edited Loading

joemcgill left a comment

Choose a reason for hiding this comment

joemcgill Jan 30, 2025

Choose a reason for hiding this comment

Mamaduka Jan 30, 2025

Choose a reason for hiding this comment

Mamaduka Feb 5, 2025

Choose a reason for hiding this comment

youknowriad Feb 5, 2025

Choose a reason for hiding this comment

joemcgill Jan 30, 2025

Choose a reason for hiding this comment

Mamaduka commented Jan 30, 2025

joemcgill commented Jan 30, 2025

Mamaduka commented Jan 30, 2025

joemcgill left a comment • edited Loading

Choose a reason for hiding this comment

Mamaduka commented Feb 5, 2025 • edited Loading

Screeenshot

Mamaduka Feb 5, 2025

Choose a reason for hiding this comment

github-actions bot commented Feb 5, 2025

Test using WordPress Playground

Some things to be aware of

Mamaduka commented Feb 5, 2025

swissspidy commented Feb 5, 2025

sgomes commented Feb 5, 2025

sgomes commented Feb 5, 2025

Mamaduka commented Feb 5, 2025

swissspidy commented Feb 5, 2025

Mamaduka commented Jan 30, 2025 •

edited

Loading

github-actions bot commented Jan 30, 2025 •

edited

Loading

joemcgill left a comment •

edited

Loading

Mamaduka commented Feb 5, 2025 •

edited

Loading