fix: expose @wordpress/theme as window.wp.theme

[dcalhoun]

What?

Expose @wordpress/theme as window.wp.theme alongside the other WordPress globals, and add it as a direct dependency.

Why?

Jetpack blocks fail to register in the editor against Jetpack's upcoming 16.2 release, which currently ships on the wordpress.org trunk build that .wp-env.json installs. The web E2E third-party-blocks spec fails as a result.

Jetpack's editor bundle now includes @wordpress/ui 0.21, whose ThemeProvider shim reads window.wp.theme at module-evaluation time and throws when it is missing:

@wordpress/ui: @wordpress/theme must expose `ThemeProvider` or `privateApis.ThemeProvider`.

In wp-admin, WordPress registers the wp-theme script. GutenbergKit populates window.wp itself and did not define theme, and the Jetpack editor-assets endpoint treats wp- handles as core-provided, so nothing else fills the gap.

How?

Import @wordpress/theme in wordpress-globals.js and assign it to window.wp.theme. The installed 0.8.0 exposes privateApis, which the @wordpress/ui shim unlocks as a fallback for ThemeProvider. The package was previously only a transitive dependency via @wordpress/dataviews, so it is now declared directly.

Testing Instructions

1. Run make wp-env-start.
2. Run npx playwright test e2e/third-party-blocks.spec.js.
3. Both tests pass. On trunk they fail with the error above.

Accessibility Testing Instructions

N/A. No UI changes.

Screenshots or screencast

N/A

🤖 Generated with Claude Code

https://claude.ai/code/session_01VnQd7G77gehA2PgnzKvFei

[wpmobilebot]

XCFramework Build

This PR's XCFramework is available for testing. Add the following to your Package.swift:

.package(url: "https://github.com/wordpress-mobile/GutenbergKit", branch: "pr-build/614")

_{Built from fe48f8d}

[nbradbury]

@dcalhoun This looks good and I'll approve it, but Claude had this to say:

package.json:74 — "@wordpress/theme": "^0.8.0" pins the root copy to 0.8.x. The next routine bump of @wordpress/block-editor/@wordpress/editor will pull a @wordpress/ui requiring a later minor; npm will keep 0.8.x hoisted (to satisfy this new direct dep) and nest the newer copy under @wordpress/ui. window.wp.theme then hands plugins a ThemeProvider from a different module instance than the editor’s own UI uses — different ThemeContext, different tokens, no error thrown (private-apis 1.43 permits the same module name to opt in twice). Silent styling divergence.

Suggest a comment next to the dependency noting the range must be kept in lockstep with whatever @wordpress/ui requires.

I'm not sure if that's an actual problem but thought I should mention it.

[nbradbury]

[dcalhoun]

@nbradbury thanks for sharing. The finding is correct, but it is not new to these changes. The added ^0.8.0 is correct today. I'll address the possibility of version drift and duplication in a separate PR.