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.
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
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?
Blueprints should support at least the following runtimes:
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.
~/.wp/. Ideally, this would take HTTP headers into consideration.fetch(). In addition, we could cache at the service worker level.Network calls
libcurlorfopen("https://")fetch(). We can't open raw TCP sockets sofopen("https://")andlibcurlcannot be easily used.fopen("https://"), butlibcurlisn't since Playground doesn't support it yet.Spawning child processes
Blueprint steps,
wp-cli,phpunit, and other tools will often spawn child processes.proc_openReporting progress
<div>that needs to change itswidthsandinnerTextFilesystem interactions
I'd love to avoid abstract the filesystem and just use the regular PHP functions like
copy()andfread()Local mounts
It may useful to support mounting directories
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:
Other ideas
What are other viable solutions to this problem?