Runtime adapters

Blueprints should support at least the following runtimes:

• wp-cli
• Docker
• wp-now
• Playground
• Native PHP CLI
• VS Code extension

Runtime-specific features

Caching the downloads

Blueprints shouldn't download the same 10MB WordPress.zip twice. Let's make sure we cache the downloads and invalidate the entries as new versions of Core and Plugins are released.

• In native PHP CLI, we can cache in the filesystem, e.g. ~/.wp/. Ideally, this would take HTTP headers into consideration.
• In Playground, we can rely on HTTP cache built into fetch(). In addition, we could cache at the service worker level.
• In VS Code, there's a caching API AFAIR.
• In Docker, we could use the docker build layers for caching.

Network calls

• In native PHP CLI, we can use libcurl or fopen("https://")
• In Playground, we can only rely on fetch(). We can't open raw TCP sockets so fopen("https://") and libcurl cannot be easily used.
• In VS Code, we can open raw TCP sockets so fopen("https://"), but libcurl isn't since Playground doesn't support it yet.

Spawning child processes

Blueprint steps, wp-cli, phpunit, and other tools will often spawn child processes.

• In wp-now PHP and native PHP, we can rely on proc_open
• In Playground, we need a custom spawn handler implemented in JavaScript

Reporting progress

• In any CLI, we should display an ASCII progress bar.
• With Docker as a backend, we should report the build progress somehow.
• In Playground, progress bar is a <div> that needs to change its widths and innerText

Filesystem interactions

I'd love to avoid abstract the filesystem and just use the regular PHP functions like copy() and fread()

Local mounts

• https://github.com/WordPress/blueprints/issues/46

It may useful to support mounting directories

• In the browser, we would either bale out (with a warning?) or mount an OPFS directory, whether that's page-specific or a local directory handle
• In wp-now and Docker, we can mount directories in the runtime without changing anything on the disk
• In Native PHP we could use symlinks

Technical implementation

Dependency injection

Let's explore the dependency injection pattern. Pimple is a tiny service container we can use to plug-in runtime-specific implementations:

$container = new Container();
switch ( $runtime ) {
	case self::RUNTIME_NATIVE:
		$container['downloads_cache']   = function ( $c ) {
			return new FileCache();
		};
		$container['http_client']       = function ( $c ) {
			return HttpClient::create();
		};
		$container['progress_reporter'] = function ( $c ) {
			return function ( ProgressEvent $event ) {
				echo $event->url . ' ' . $event->downloadedBytes . '/' . $event->totalBytes . "                         \r";
			};
		};
		break;
	case self::RUNTIME_PLAYGROUND:
		$container['downloads_cache']   = function ( $c ) {
			// @TODO
		};
		$container['http_client']       = function ( $c ) {
			// @TODO
		};
		$container['progress_reporter'] = function ( $c ) {
			// @TODO
			// post_message_to_js();
		};
		break;

Other ideas

What are other viable solutions to this problem?

Start by separating the listed runtimes and concerns: caching, network calls, child processes, progress, filesystems, and mounts. Read the linked issues 46 and WordPress Playground issue 1026; the payload names no implementation files or tests, so the first milestone is agreeing on scope and runtime boundaries before defining what done means.