fix: align editor globals with WP Admin

[dcalhoun]

What?

Improve alignment with the JavaScript globals found in the WP Admin environment.

Why?

We expose these globals to mimic the WP Admin environment, allowing plugins to access these extracted modules rather than bundling them themselves. This does not address a known bug, but improves robustness of the existing system.

How?

• Expose four missing modules
• Remove modules WP Admin does not expose
• Flag namespace globals __esModule and expose default exports where core does
• Define the screen globals from admin-header.php before plugins load
• Configure AJAX as early as possible for invocations during plugin loading

Testing Instructions

General automated and manual regression testing, this does not address an observable bug.

Accessibility Testing Instructions

N/A, no user-facing changes.

Screenshots or screencast

N/A, no user-facing changes.

---

AI-generated details

Aligns the editor's globals with WP Admin, so plugin scripts bundled with @wordpress/dependency-extraction-webpack-plugin get what they get there. Globals we deliberately don't support stay out: legacy APIs, cookie auth, outdated libraries, and anything tied to admin screens or sidebars.

• Missing packages: Adds blockSerializationDefaultParser, reduxRoutine, sync and uploadMedia, which core registers as wp-* scripts. sync and upload-media hold state, so plugins need the editor's own instance, as with fix: expose @wordpress/theme as window.wp.theme #614.
• __esModule flag: Core builds each namespace global with esbuild's __toCommonJS. Webpack resolves a plugin's default import to default only when that flag is set. A new toCommonJS helper wraps every namespace global, including wp.hooks and wp.i18n.
• Default exports: Core exposes the default export for packages flagged wpScriptDefaultExport. serverSideRender now exposes the component and shortcode the Shortcode class. isShallowEqual becomes a namespace, so named imports resolve.
• Globals core doesn't define: Drops icons and globalStylesEngine. Core registers no such scripts and plugin tooling bundles both; since build(deps-dev): Bump @wordpress/dependency-extraction-webpack-plugin from 6.43.0 to 6.56.0 #739 our own imports bundle them too. formatLibrary is undefined, as core's script exports nothing. Its import in wordpress-globals.js registers the formats; the one in visual-editor never ran, because our Vite transform strips it, so it's removed.
• Screen globals: admin-header.php sets ajaxurl, pagenow, typenow, adminpage, thousandsSeparator, decimalPoint and isRtl before any script runs. They are now defined before plugins load; previously ajaxurl arrived after them. The separators come from Intl.NumberFormat for now.
• ReactJSXRuntime: Drops the interop default key core's global lacks.

Verified: make lint-web-fix, make test-web-unit, make check-wp-packages, and CI=true make test-web-e2e (50 passed) against wp-env with Jetpack. A capture of every global in WP Admin's post-new.php and in the built editor differs only in deliberately skipped globals. The screen globals match WP Admin's values, except that ajaxurl is absolute because the editor isn't served from the site's origin.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Mp7HPYAD9KtkU4Dh994Pfm

[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/750")

_{Built from 61c08dc}

[adalpari]

Manual testing looks good to me!

Claude found these "medium" points, but I'm not sure they are at that severity level. So, just for you to double check,

#	Severity	File	Finding	Why it matters	Suggested fix
1	🟡 Medium	ajax.js:78	The auth prefilter decides isSameOrigin( options.url ) in its body but attaches the header in beforeSend; moving configureAjax() ahead of plugin load registers it first, so plugin prefilters now run in between.	A plugin prefilter assigning options.beforeSend discards our wrapper and admin-ajax goes out unauthenticated; one rewriting options.url cross-origin gets the token sent there — not CORS-gated on iOS, which loads from file:// with allowUniversalAccessFromFileURLs. Both reproduced against the installed jQuery with a clean trunk-vs-branch differential.	Re-evaluate isSameOrigin( options.url, siteOrigin ) inside the beforeSend wrapper rather than in the prefilter body.
2	🟡 Medium	admin-globals.js:37	getNumberSeparators() derives separators from Intl, but core prints $wp_locale->number_format from the site's translations — and the two disagree.	fr gets U+202F vs core's U+00A0, ru U+00A0 vs plain U+0020, ar U+066B vs . — 16 of 49 shipped locales. ICU 72 changed fr, so one build yields different values across WebView versions. A plugin splitting a number_format_i18n() string on window.thousandsSeparator parses 1 234 567,80 as 1.	Source the separators from the translation bundles or an explicit map. Also warn() in the catch at line 43 — it never fires for well-formed-but-unsupported tags like kab, which silently resolve to the device locale rather than the promised en_US.

[adalpari]

🚢 it!

[dcalhoun]

Thank you for testing and reviewing, @adalpari.

AJAX auth prefilter order: Valid and addressed. I reverted the re-ordering in 9e49b1e, as its original value is very low and unlikely to occur (plugin AJAX requests requiring auth triggered during load; Jetpack is the only opt-in plugin at the moment). I added the origin recheck hardening in 61c08dc.

Number separators: I opted to remove these globals in 27ceb63 after determining they are largely used for WP Admin list pages. They do not appear to be worth their weight, particularly given the gaps you noted.