build: pin the wp-env WordPress core and plugin versions

[jkmassel]

What?

Pins .wp-env.json to explicit versions instead of latest.zip and unversioned plugin zips.

-"core": "https://wordpress.org/latest.zip",
+"core": "https://wordpress.org/wordpress-7.1.zip",
 "plugins": [
-    "https://downloads.wordpress.org/plugin/gutenberg.zip",
-    "https://downloads.wordpress.org/plugin/jetpack.zip"
+    "https://downloads.wordpress.org/plugin/gutenberg.23.9.1.zip",
+    "https://downloads.wordpress.org/plugin/jetpack.16.1.3.zip"
 ]

Why?

wp-env downloads whatever the URL resolves to, so every CI run installed whatever shipped that day. A third-party release could turn every open PR red without a line of code changing — and did.

A Jetpack release began bundling @wordpress/ui 0.21, whose ThemeProvider shim reads window.wp.theme at module-evaluation time and throws when it is missing. No Jetpack block registered, so e2e/third-party-blocks.spec.js failed on every branch that predated #614:

Boolean( window.wp.blocks.getBlockType( 'jetpack/tiled-gallery' ) )  // false

Nothing in any affected branch had changed. #594 last passed on Aug 21 and first failed on Sept 3; the only commit between the two deletes a logError call. The break came from outside the repo, arrived unannounced, and surfaced as a red check on eleven unrelated PRs — where the natural first assumption is that the PR broke something.

Trade-off

Pinning is not free, and this is the part worth arguing about.

Cost: nothing watches these versions — Dependabot does not read .wp-env.json — so they will rot until someone bumps them, and the local environment drifts from what users actually run.

Benefit: an upgrade becomes a reviewable change whose failure is attributable to the upgrade, rather than a surprise on someone else's PR.

A lighter alternative, if the bump chore isn't wanted: pin only Jetpack, the third-party dependency we don't control and the one that actually broke, and leave core and Gutenberg tracking latest since those are the surfaces GutenbergKit is meant to stay current with. Happy to cut it back to that.

How?

The three versions are what CI resolved latest to on a passing run, so this freezes a known-good state rather than proposing an upgrade. Each was confirmed against the WordPress.org API (core/stable-check, plugins/info/1.0), and all three versioned URLs return HTTP 200 — a 404 would break wp-env outright.

.wp-env.json is strict JSON with no comment support, so the rationale and the bump procedure go in docs/code/local-wordpress.md, under the existing "wp-env Configuration" section. That includes the part that bites: bumping requires make wp-env-start RESET=1, since an existing environment keeps the version it was created with.

Testing Instructions

• .wp-env.json is valid JSON
• All three versioned URLs return HTTP 200
• ESLint and Prettier clean
• Web E2E green in CI — the actual proof

I have not booted wp-env with these pins locally; the versions match what CI just used and the URLs resolve, but only a green E2E run demonstrates it. Worth watching that check specifically before this merges.

Related

• fix: expose @wordpress/theme as window.wp.theme #614 — exposed window.wp.theme, the fix for the incident above
• Found while rebasing the fix: recover media uploads that fail server-side post-processing #594 stack (fix(ios): gate the media upload server on the site root too #624–docs: state the invariant that makes the media field decode safe #633) onto trunk to pick up that fix

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

_{Built from 95c5f6a}