[Remote] Resolve the "latest" WordPress alias before comparing versions - #4247
[Remote] Resolve the "latest" WordPress alias before comparing versions#4247amitraj2203 wants to merge 1 commit into
Conversation
github-actions
Bot
added
[Type] Documentation
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Resolves the latest WordPress alias to a concrete build version during worker boot so version comparisons use consistent build-version strings and avoid false mismatch warnings.
Changes:
- Normalize
latest(and keepnightly) to a concrete minified build version inboot(). - Update an in-code comment to reflect the new alias-resolution behavior.
- Add a parameterized Vitest case asserting alias-to-build resolution for
latest,nightly, and explicit versions.
Reviewed changes
Copilot reviewed 2 out of 8 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| packages/playground/remote/src/lib/playground-worker-endpoint-blueprints.ts | Resolves latest/nightly early so later logic compares build versions rather than aliases. |
| packages/playground/remote/src/lib/playground-worker-endpoint-blueprints.spec.ts | Adds a parameterized test to assert requestedWordPressVersion is normalized to a build version. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| it.each([ | ||
| { wpVersion: 'latest', expected: LatestMinifiedWordPressVersion }, | ||
| { wpVersion: 'nightly', expected: 'trunk' }, | ||
| { wpVersion: '6.8', expected: '6.8' }, | ||
| ])( | ||
| 'resolves the requested WordPress version $wpVersion to a build version', | ||
| async ({ wpVersion, expected }) => { | ||
| let endpoint: | ||
| | { | ||
| boot(options: Record<string, unknown>): Promise<void>; | ||
| requestedWordPressVersion?: string; | ||
| } | ||
| | undefined; | ||
| vi.doMock('@wp-playground/wordpress', () => ({ | ||
| bootWordPress: vi.fn(), | ||
| })); | ||
| vi.doMock('@php-wasm/web', () => ({ | ||
| certificateToPEM: vi.fn(), | ||
| createDirectoryHandleMountHandler: vi.fn(), | ||
| exposeAPI: vi.fn((api) => { | ||
| endpoint = api; | ||
| return [vi.fn(), vi.fn()]; | ||
| }), | ||
| loadWebRuntime: vi.fn(), | ||
| })); | ||
| await import('./playground-worker-endpoint-blueprints'); | ||
| if (!endpoint) { | ||
| throw new Error('Expected exposeAPI to receive an endpoint'); |
There was a problem hiding this comment.
vi.resetModules() already runs in the describe-level beforeEach (line 7), which Vitest applies before every case, it.each rows included. beforeEach also stubs a fresh self, so the once-per-global guard flag is cleared too — both conditions for re-evaluating the entrypoint are met per case.
The last test in this file demonstrates it: it imports the entrypoint, calls vi.resetModules(), imports again, and asserts the guard throws. That only happens if the module body re-runs, so the module isn't served from cache after a reset. The existing 4-row handles a concrete WordPress release ... it.each uses the same doMock + dynamic-import pattern.
Verified all three rows pass in isolation, and each has an explicit if (!endpoint) throw guard, so the failure mode described here couldn't pass silently.
On cleanup: afterEach already doUnmocks @php-wasm/web, @wp-playground/blueprints and @wp-playground/wordpress, plus vi.unstubAllGlobals().
`requestedWordPressVersion` stored the `latest` alias verbatim while the loaded-version check compared it against a resolved build version, so every default boot warned about a mismatch that did not exist. Resolve `latest` to LatestMinifiedWordPressVersion at the same place `nightly` is already resolved to `trunk`.
32696db to
b89fdf8
Compare
Motivation for the change, related issues
Fixes #4246.
Every default Playground boot logs a mismatch that isn't one:
The website defaults
wpto the literal stringlatest(resolve-blueprint-from-url.ts:223).requestedWordPressVersionstored that alias verbatim, whilefinalizeAfterBoot()compared it against the resolved build version fromgetLoadedWordPressVersion()— so'latest' !== '7.0'warned even though thecorrect build had loaded.
nightlywas already normalized totrunk, andbeta/trunkare real keys inwp-versions.json, solatestwas the only alias that mis-compared — and being the default, it fired for essentially every visitor. That noise also defeats the check's purpose: the genuine mismatch it exists to catch (WordPress restored from browser storage at a different version) looked identical to the false positive.Implementation details
Resolve
latesttoLatestMinifiedWordPressVersionat the same placenightlyis already resolved totrunk, inPlaygroundWorkerEndpointBlueprints.boot().The download path is unchanged. Previously
latestfailed theMinifiedWordPressVersionsList.includes()check and fell through toLatestMinifiedWordPressVersion; now it passes that check and yields the same value. It still can't reach the wordpress.org branch, which requires!isMinifiedVersion. The now-stale comment describinglatestas falling through is updated.This also improves
getWordPressModuleDetails(), whosemajorVersionfallback could previously reportlatestinstead of a version.Fixing it here rather than at the caller keeps
?wp=latestworking as the documented public value — the alias just stops leaking past the boot boundary.Testing Instructions (or ideally a Blueprint)
npm run dev, open http://127.0.0.1:5400/website-server/ with the console open, and wait for boot — no version-mismatch warning (there is one ontrunk).?wp=nightlyand?wp=6.9— still no warning, correct build boots.npx nx test playground-remote --testFile=playground-worker-endpoint-blueprints.spec.tsAdded a parameterized test asserting
requestedWordPressVersionholds a build version forlatest,nightly, and an explicit6.8. Verified it fails ontrunk(expected 'latest' to be '7.0') and passes with the fix.