Add wp-theme as a style dependency of wp-components

[mirka]

What?

Adds wp-theme as a style dependency of wp-components in the Gutenberg plugin asset registration, and removes the wp-theme bootstrap from wp-base-styles.

Why?

@wordpress/components styles consume --wpds-* design tokens defined by the wp-theme stylesheet. The JS packages already declare this dependency, but the style graph did not.

admin-schemes.css (which is essentially what the wp-base-styles stylesheet handle loads) does not consume tokens itself, so it is not quite logical that wp-base-styles declares wp-theme as a dependency. We were only hooking into wp-base-styles as a kind of convenience. Entry points that need tokens should declare the dependency explicitly.

I was rethinking this in the context of WordPress/wordpress-develop#12560, and this PR basically matches the stylesheet dependency logic we're implementing upstream in Core.

How?

• Add wp-theme to wp-components style dependencies in lib/client-assets.php.
• Remove wp-theme from wp-base-styles style dependencies.

Testing Instructions

1. Run npm run build (Gutenberg plugin activated).
2. Make sure that the design-tokens stylesheet is still loaded in places where it should, like the editor iframe or the extensible site editor.

[github-actions]

Flaky tests detected in ba13e60.
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/29513155595
📝 Reported issues:

• [Flaky Test] Should insert content using the global inserter #78924 in /test/e2e/specs/widgets/editing-widgets.spec.js

[github-actions]

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: mirka <0mirka00@git.wordpress.org>
Co-authored-by: ciampo <mciampini@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: aduth <aduth@git.wordpress.org>

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

[ciampo]

🚀

[ciampo]

Removing this dependency should be fine, since wp-edit-blocks directly depends on wp-theme, and editor styles depend on wp-components.

But we may still need to tweak the theme package's README, since it claims that wp-theme loads through shared base styles on standard admin pages. We should probably remove / generalize that claim to make it more future-proof

[mirka]

I'll update the readme separately 👍

[t-hamano]

Just to confirm, do consumers who want to use design tokens without depending on wp-components need to explicitly enqueue wp-theme?

For example, plugin developers might register their own custom settings pages, where they may want to use design tokens to build their UI. I am one of those people who want to use design tokens to add some UI to the dashboard. Are there any concerns about always enqueuing design tokens for all screens?

[aduth]

Just to confirm, do consumers who want to use design tokens without depending on wp-components need to explicitly enqueue wp-theme?

For example, plugin developers might register their own custom settings pages, where they may want to use design tokens to build their UI. I am one of those people who want to use design tokens to add some UI to the dashboard. Are there any concerns about always enqueuing design tokens for all screens?

I touched on this in my merge proposal post, but the short answer is: Yes, you do need to enqueue it, and yes, we eventually should expect it to be enqueued for all screens.

Under "What's next":

Better default availability of design tokens: While the new wp-theme stylesheet will be registered, it will only be enqueued by default on specific WordPress screens that use the new theming feature. As theming extends to more parts of the interface, it’s expected that the tokens would be available more universally throughout the admin interface. In the meantime, developers can enqueue the stylesheet themselves.

[mirka]

we eventually should expect it to be enqueued for all screens

In WordPress/wordpress-develop#12560, I noticed that:

• The wp-theme stylesheet will now be loaded in all pages that load the wp-commands stylesheet (for the ⌘K menu in the toolbar), because wp-commands depends on wp-components which depends on wp-theme. Which it looks like covers virtually all logged-in wp-admin pages now?
• If we really want to load the wp-theme stylesheet on "all wp-admin pages" explicitly, that seems pretty easy to do as well.

[t-hamano]

Under "What's next":

Better default availability of design tokens: While the new wp-theme stylesheet will be registered, it will only be enqueued by default on specific WordPress screens that use the new theming feature. As theming extends to more parts of the interface, it’s expected that the tokens would be available more universally throughout the admin interface. In the meantime, developers can enqueue the stylesheet themselves.

Thank you for explaining it in detail!

The wp-theme stylesheet will now be loaded in all pages that load the wp-commands stylesheet (for the ⌘K menu in the toolbar), because wp-commands depends on wp-components which depends on wp-theme. Which it looks like covers virtually all logged-in wp-admin pages now?

This appears to be true. I checked the style handles in a tree format using code like the following:

Details

add_action( 'admin_print_footer_scripts', function () {
	$wp_styles = wp_styles();
	$done      = $wp_styles->done;

	// Recursively expand a handle into a { handle, deps } node.
	$build = function ( $handle, $seen ) use ( &$build, $wp_styles, $done ) {
		$dep = $wp_styles->registered[ $handle ] ?? null;

		// Unregistered handle: leaf.
		if ( null === $dep ) {
			return array(
				'handle' => $handle,
				'deps'   => array(),
			);
		}
		// Already on this branch: stop to avoid cycles.
		if ( isset( $seen[ $handle ] ) ) {
			return array(
				'handle' => $handle,
				'deps'   => array(),
			);
		}
		$seen[ $handle ] = true;

		$children = array();
		foreach ( $dep->deps as $child ) {
			$children[] = $build( $child, $seen );
		}

		return array(
			'handle' => $handle,
			'deps'   => $children,
		);
	};

	// One tree per enqueued handle.
	$tree = array();
	foreach ( $wp_styles->queue as $handle ) {
		$tree[] = $build( $handle, array() );
	}

	// Does this subtree reach wp-theme?
	$contains = function ( $node ) use ( &$contains ) {
		if ( 'wp-theme' === $node['handle'] ) {
			return true;
		}
		foreach ( $node['deps'] as $child ) {
			if ( $contains( $child ) ) {
				return true;
			}
		}
		return false;
	};

	// Keep only the roots that pull in wp-theme.
	$tree = array_values( array_filter( $tree, $contains ) );

	// Print the tree to the browser console.
	wp_print_inline_script_tag(
		sprintf(
			'( function () {
				var tree = %s;
				function label( node ) {
					return node.handle;
				}
				function walk( node ) {
					if ( ! node.deps.length ) {
						console.log( label( node ) );
						return;
					}
					console.group( label( node ) );
					node.deps.forEach( walk );
					console.groupEnd();
				}
				console.group( "Style deps tree (%d root handles)" );
				tree.forEach( walk );
				console.groupEnd();
			} )();',
			wp_json_encode( $tree ),
			count( $tree )
		)
	);
} );

This PR	wordpress-develop #12560

Therefore, I found that design tokens are effectively enqueued on all dashboard pages.