Bump Playground to 3.1.45

[gcsecsey]

Related issues

• Related to STU-1370
• Ships the upstream fix [CLI] Remove process.exit() from library APIs WordPress/wordpress-playground#3478, released in Playground v3.1.45

How AI was used in this PR

I used Claude to trace STU-1370 to the upstream runCLI() process.exit() behavior, confirm the fix shipped in Playground 3.1.45, bump the dependencies, and regenerate the lockfile. I reviewed the diff and verified single-copy resolution of the Playground and PHP-WASM packages myself. Claude also diagnosed and fixed the Windows-only CLI E2E failure the bump surfaced (see below), reproducing it locally on Windows.

Proposed Changes

Studio runs each site's Playground server in a child process that imports runCLI() from @wp-playground/cli. When a site hit a PHP error during startup, runCLI() called process.exit(1) before the error could propagate, which killed the child process, so Studio's error handling never ran and the real error was lost.

The upstream fix (WordPress/wordpress-playground#3478, in 3.1.45) removes process.exit() from the Playground CLI's library APIs, so runCLI() now throws instead of exiting.

This PR:

• Bumps Playground and PHP-WASM to 3.1.45 to pick up that fix
• This is the prerequisite that lets Studio catch PHP-error start failures at all. On its own it makes the failure report the real PHP error (via the existing Surface PHP errors when a site fails to start #3813 handling) instead of tearing the child process down. The user-facing STU-1370 behavior (the site starting and serving the error page) is a follow-up PR that depends on this bump.
• Lockfile note: alongside the version bumps, npm deduped fast-xml-parser (a nested duplicate collapsed into a single top-level copy, within existing ranges) and added zstddec, a new dependency of @wp-playground/wordpress@3.1.45.
• Windows import fix: on Windows, importing a backup into a running site failed to restart the server with Error connecting to the SQLite database. wp sqlite import leaves the imported database in WAL journal mode, and 3.1.45 boots the site through the WASM SQLite driver, which cannot reopen a WAL-mode database on Windows (WAL needs shared memory the WASM filesystem can't provide there). After importing, Studio now converts the database back to rollback (DELETE) journal mode — using Node's native node:sqlite, since PHP-WASM itself can't touch the WAL database — so Playground can reliably reopen it.

Testing Instructions

Because 3.1.45 is still inside the npm cooldown window, install locally with the cooldown bypassed. A plain npm install works from 2026-07-18 onward.

• Check out this branch and run npm install --min-release-age=0
• Confirm the lockfile resolves a single 3.1.45 copy of every @wp-playground/* / @php-wasm/* package, with no nested duplicates
• npm run typecheck passes
• npm run cli:build && node apps/cli/dist/cli/main.mjs --version builds and runs
• Smoke test: create and start a local site, confirm it loads and runs normally — i.e. no regression from the runtime bump
• On Windows, confirm the import fix: npm run cli:build then npm test -- apps/cli/commands/tests/import.e2e.test.ts --tagsFilter='e2e' --no-file-parallelism -t 'imports a backup into a running site'

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?
• Confirm the merge date is on or after 2026-07-18 (around 04:13 UTC) so CI can install 3.1.45

[Copilot]

Pull request overview

Updates Studio’s embedded WordPress Playground/PHP-WASM runtime to v3.1.45 to pick up the upstream fix where runCLI() throws instead of calling process.exit(1), allowing Studio’s existing error-handling paths to receive and surface startup failures.

Changes:

• Bump @wp-playground/* and @php-wasm/* dependencies to 3.1.45 across the monorepo packages that depend on Playground.
• Regenerate package-lock.json to reflect the new resolved dependency graph (including new transitive deps like zstddec).
• Remove now-obsolete inline commentary about the previous runCLI() process.exit() behavior in the Playground child process codepath.

Reviewed changes

Copilot reviewed 6 out of 7 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
tools/benchmark-site-editor/package.json	Bumps @wp-playground/cli to 3.1.45 for the benchmark tool.
packages/common/package.json	Bumps @wp-playground/blueprints to 3.1.45 in shared package deps.
apps/ui/package.json	Bumps @wp-playground/blueprints to 3.1.45 for the UI app.
apps/studio/package.json	Bumps @wp-playground/blueprints to 3.1.45 for the desktop app.
apps/cli/package.json	Bumps CLI’s pinned Playground and PHP-WASM runtime deps to 3.1.45.
apps/cli/playground-server-child.ts	Removes stale comment now that the upstream behavior has changed in 3.1.45.
package-lock.json	Updates lockfile to resolve the 3.1.45 dependency set (and associated dedupes/new transitive deps).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[wpmobilebot]

📊 Performance Test Results

Comparing 8949b1b vs trunk

app-size

Metric	trunk	8949b1b	Diff	Change
App Size (Mac)	1367.52 MB	1372.97 MB	+5.46 MB	🔴 0.4%

site-editor

Metric	trunk	8949b1b	Diff	Change
load	1066 ms	1048 ms	18 ms	⚪ 0.0%

site-startup

Metric	trunk	8949b1b	Diff	Change
siteCreation	6528 ms	6539 ms	+11 ms	⚪ 0.0%
siteStartup	2360 ms	2386 ms	+26 ms	⚪ 0.0%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)

[sejas]

@gcsecsey , thanks fixing the issue in Playground repo WordPress/wordpress-playground#3478 and bringing the change to WordPress Studio ✨.

It seems we execute resetSqliteJournalModeToRollback for imports but not for Pulls, is that intentional? Maybe we could move the logic to the base importer.

I also noticed in your description you are tagging the PR 3478 of this repo, instead of the Playground repo.

[gcsecsey]

Thanks @sejas for reviewing this!

It seems we execute resetSqliteJournalModeToRollback for imports but not for Pulls, is that intentional? Maybe we could move the logic to the base importer.

No, this wasn't intentional, I addressed this in the recent commits.

I also noticed in your description you are tagging the PR 3478 of this repo, instead of the Playground repo.

Good catch, thanks, I updated the description.

Could you take another look? Thanks!

[sejas]

Thanks for the changes! Code LGTM and I tested pulling a site 👌.