Blueprints: Transition from a TypeScript library to a PHP library

[adamziel]

Let’s pivot Blueprints from a TypeScript library to a PHP library. I started the explorations in this repo:

https://github.com/WordPress/blueprints/

Motivation

PHP Blueprints would unite all the Blueprint runtime environments, use-cases, and developers. Single library and documentation unlocking multiple ecosystems.

• PHP would run the logic in a write once–run everywhere fashion.
• Playground would be a thin, interchangeable glue layer using WASM to run WordPress and PHP in the browser, Node.js, VS Code, iOS, Android, desktop, etc.

PHP-powered Blueprints would:

• Force us to write universal and interoperable code
• Empower WordPress developers who are familiar with PHP
• Push Playground and PHP.wasm to feature parity with native PHP
• Remove Playground internals and asynchronous code from the equation
• Remove the PHP/TypeScript dualism. We’ll achieve more with less code
• Remove the temptation to duplicate implementations in different JS tools, PHP, and WordPress plugins

Blueprints would become the lingua franca of WordPress. All the runtimes would rely on the same orchestration library:

• Independent CLI binary
• WP-now command
• VS Code extension
• The web browser
• WordPress core
• WP-CLI plugin
• Mobile apps

Here's a few specific use-cases I have in mind

• Template sites
• Site export/import
• The w.org community space
• Prototypes of the Site Transfer protocol
• “Quick development setup”, e.g. I have some local files and I run wp start

Technical steps to get there

Here's the big picture of what we'll need to do:

1. Disregard WASM and prototype a PHP library that only works well in native PHP. Don't overuse third party libraries, but rely on small components like Symfony EventDispatcher when applicable.
2. Run that library in PHP.WASM, identify all the ways it fails.
3. Bundle the library as phar, explore using it in WordPress, WordPress Playground plugin, wp-now, wp-cli etc.
4. Outline a plan to make it work with the least amount of work. Use workarounds, adjust the PHP library, adjust PHP.wasm implementation, and build polyfills as needed.
5. Outline a plan to replace all the workarounds with stable, long-term, easy-to-maintain solutions.
6. Bring the phar library into WordPress Playground core, make the @wp-playground/blueprints library a thin wrapper that delegates all the tasks to the PHP implementation

Related and known PHP.wasm limitations

• Support spawning PHP sub-processes #1026
• Sharing Filesystem between multiple PHP instances #1027
• PHP: Stream downloading/processing of remote resources #1028

Other notes

• WordPress Playground plugin ships a PHP implements of site export and import. This code could be moved to the PHP Blueprint library and replace the TypeScript export/import implementation.
• The PHP library should be extensible.
• We could generate the Blueprint JSON schema from PHP types and interfaces in the same way as we do that today using the TypeScript types.
• A future version of the Blueprint library should know how to extract only a part of a remote ZIP file without downloading all of it.
• wp-cli could handle complex steps like setWpConfigConstant (wp config set), enableMultisite (wp core multisite-convert), runWpInstallationWizard (wp core install). Same for wp-now features like downloading and installing WordPress core or the SQLite integration plugin.

cc @bgrgicak @dmsnell @mtias @youknowriad @eliot-akira @sejas @danielbachhuber

[adamziel]

Surfacing these relevant explorations:

• Contribution workflow: How to include additional files (e.g. plugin zip) in a PR? blueprints#6