Repository navigation
fix: align window.wp globals with WordPress script packages - #785
Conversation
WordPress 7.0+ no longer registers the wp-sync script, and Gutenberg removed the global upstream (WordPress/gutenberg#81999). Core data bundles the package, so the direct dependency is unnecessary. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
WP Admin's post editor exposes it, and plugin tooling would externalize it there if it ever leaves the bundled packages list. Core data and compose already bundle it, so exposing it costs nothing. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
WordPress exposes a window.wp global for each package flagged wpScript, and a missing one breaks every plugin script that reads it. The window.wp.theme gap went unnoticed for months until Jetpack adopted it; this flags such gaps on the dependency bump that introduces them. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
4952a7a to
454fe42
Compare
XCFramework BuildThis PR's XCFramework is available for testing. Add the following to your .package(url: "https://github.com/wordpress-mobile/GutenbergKit", branch: "pr-build/785")Built from 5db1e88 |
A stray file such as .DS_Store in node_modules/@WordPress made the whole test file fail with ENOTDIR before any test ran. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The coverage check only caught missing globals, so the stale wp.sync global would have passed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Merge the existence and shape checks so a missing global fails once with a clear message, list packages in one pass, and assert membership against plain lists for short failure diffs. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
| window.wp.serverSideRender = serverSideRender.default || serverSideRender; | ||
| window.wp.shortcode = shortcode.default || shortcode; | ||
| window.wp.styleEngine = toCommonJS( styleEngine ); | ||
| window.wp.sync = toCommonJS( sync ); |
There was a problem hiding this comment.
Does this mean packages that are built with older version WordPress packages won't be able to get wp.sync? Would that cause any issue?
There was a problem hiding this comment.
Yes, but the impact to GBK is very narrow and the breaking change was accepted in upstream Gutenberg core in WordPress/gutenberg#81999. It's expected that plugins bundle @wordpress/sync themselves or access the relevant utility via @wordpress/core-data's Y option added to the provider creator.
Details explained by Claude below:
Only for plugins built with
@wordpress/dependency-extraction-webpack-plugin6.40–6.56 that import@wordpress/sync; builds before Feb 2026 and from 6.57 on bundle their own copy. In practice those are real-time collaboration transports (e.g. Jetpack's, VIP's). Those can't work in GBK anyway, since collaboration only runs whenwindow.__experimentalEnableRealTimeCollaborationis set, which we never do. A script that throws on load doesn't stop the remaining assets from loading.Upstream accepted the same break: WordPress/gutenberg#81999 lists it as breaking, WP 7.0/7.1 never shipped
wp.sync, and Gutenberg 24.2 drops it. On our side,wp.syncwas only added in #750 and never shipped in a GBK release, so nothing regresses.
What?
Align
window.wpglobals with latest WP Admin state. Flag future misalignment with unit tests.Why?
Ensure the GutenbergKit environment remains aligned with the WP Admin environment after #780, which removed the
window.wp.syncglobal. Misalignment can lead to cryptic errors.How?
window.wp.syncglobalwindow.wp.undoManagerglobalTesting Instructions
N/A, no user-facing changes.
Accessibility Testing Instructions
N/A, no user-facing changes.
Screenshots or screencast
N/A, no user-facing changes.
AI-generated details
What: Remove
window.wp.sync, exposewindow.wp.undoManager, and add a unit test that flagswindow.wpgaps against installed packages flaggedwpScript.Why:
wp-sync, and Gutenberg removed the global in 24.2 (Sync: Remove exposed wp.sync package WordPress/gutenberg#81999), which core trunk picks up with its next Gutenberg pin update.@wordpress/dependency-extraction-webpack-plugin6.57.0 (build(deps-dev): Bump @wordpress/dependency-extraction-webpack-plugin from 6.56.0 to 6.57.0 #780) now bundles it into plugin builds. Its only consumers are real-time collaboration transports, which GutenbergKit never enables.wp.undoManager. Plugins bundle it today, but would read the global if it leavesBUNDLED_PACKAGES. Core data and compose already bundle it, so exposing it adds no size.wp.theme(fix: expose @wordpress/theme as window.wp.theme #614) went missing for ~10 months until Jetpack adopted it; this test would have flagged it on the first dependency bump.How: The test reads
wpScriptandwpScriptDefaultExportfrom each installed@wordpress/*/package.jsonand thewindow.wp.X = …assignments inwordpress-globals.jsandwordpress-i18n.js. It reads source rather than importing the modules, which Node can't evaluate. It fails when:X.default || Xfor default-export packages,toCommonJS( X )otherwise);wp.sync);wpScriptapproximates core's globals;base-stylesis the one exclusion (flagged only to build its stylesheet).Testing:
make test-web-unit. Each check was confirmed to fail when its case is introduced: removingundoManager, swapping thetokenList/urlshapes, and re-addingwp.sync.🤖 Generated with Claude Code