wordpress.core-phpunit cannot run against a clean wordpress-develop checkout (no Composer deps) and crashes silently when vendor/polyfills are absent

[chubes4]

Summary

wordpress.core-phpunit cannot run core's PHPUnit suite against a freshly-mounted wordpress-develop checkout, and when the required Composer dependencies are missing it crashes with no diagnostics instead of failing with a clear message. Two separable problems — a capability gap and a failure-mode bug.

Repro

Mount a clean wordpress-develop worktree (no composer install run) and invoke the command:

npm run wp-codebox -- run \
  --mount /path/to/wordpress-develop:/workspace/wordpress-develop \
  --command wordpress.core-phpunit \
  --arg core-root=/workspace/wordpress-develop \
  --arg test-file=/workspace/wordpress-develop/tests/phpunit/tests/sitemaps/sitemaps.php \
  --artifacts ./artifacts --json

Result:

"error": {
  "name": "PlaygroundCommandCrashError",
  "message": "wordpress.core-phpunit crashed before producing a structured response\n\nPHP.run() failed with exit code 1.\n=== Stdout === (empty)\n=== Stderr === (empty)"
}

No STAGE_FAIL, no .pg-test-result.txt content surfaced — the diagnostics scaffold in corePhpunitRunCode() never gets to flush.

Root cause (confirmed)

Core's tests/phpunit/includes/bootstrap.php hard-requires the Composer-installed test toolchain (PHPUnit + the Yoast PHPUnit Polyfills, per the bootstrap's polyfills check). A clean develop checkout has no vendor/. I probed the actual bootstrap path inside a sandbox with the same mount:

vendor dir exists: NO
polyfills autoloader exists: NO
bootstrap.php exists: yes
wp-tests-config exists: NO
ATTEMPTING bootstrap require ...
Error: Looks like you're using PHPUnit 0. WordPress requires at least PHPUnit 5.7.21.

With no vendor/, PHPUnit version detection resolves to 0, and core's bootstrap.php calls die(). Because that die() happens inside require_once .../includes/bootstrap.php, the PHP-WASM process terminates before the core_pg_stage_fail() / shutdown-handler diagnostics in corePhpunitRunCode() (packages/runtime-playground/src/commands.ts) can write/flush .pg-test-result.txt. Hence the silent crash.

Two issues to fix

1. Capability gap — provisioning Composer test deps

There is currently no documented/supported way to give wordpress.core-phpunit the PHPUnit + Yoast polyfills that core's bootstrap requires. Options worth considering:

• Accept a mounted, pre-installed vendor/ (document that callers must composer install/composer update -W in the checkout before mounting), and/or
• Provision the polyfills + a PHPUnit autoloader inside the sandbox as part of the command (e.g. mount or fetch them), and/or
• Generate a minimal autoload that satisfies the bootstrap's PHPUNIT_COMPOSER_INSTALL / polyfills expectations.

At minimum, acceptedArgs/README should state the hard precondition: the core checkout must have Composer dev dependencies installed (PHPUnit + yoast/phpunit-polyfills) before mounting, since tests/phpunit/includes/bootstrap.php die()s otherwise.

2. Failure-mode bug — silent crash

When the bootstrap die()s (missing polyfills/PHPUnit, unreadable autoload, etc.), the command should surface a clear, structured error like "PHPUnit Polyfills/vendor autoload not found at ; core PHPUnit requires Composer dev dependencies" rather than crashed before producing a structured response. Because core's bootstrap can die()/fatal mid-require, the diagnostics need to either:

• pre-flight the required paths (vendor/autoload.php, vendor/yoast/phpunit-polyfills/..., wp-tests-config.php) before requiring bootstrap and fail structured, and/or
• capture the die() output (output buffering + shutdown handler that flushes the buffer to the result file).

Environment

• wp-codebox CLI from current main.
• Mounted wordpress-develop (trunk) worktree, no composer install.
• Playground WP 7.0, PHP 8.3.

Context

Hit while validating a core sitemaps fix (paginated XML sitemap 404; repro lives in Extra-Chill/data-machine-events#335 + a forthcoming WordPress Trac ticket). The behavior fix is already proven via an in-process WP::main()/handle_404() lifecycle probe; the remaining need is running core's PHPUnit suite green before opening the wordpress-develop PR, which is exactly what wordpress.core-phpunit is for.