Extend towards full dev environment

[schlessera]

I love these explorations that show what is currently possible on the web platform!

Thinking about the even bigger picture here, it would be awesome to have a full development platform in the browser, including a terminal you can run tooling like WP-CLI. This could make use of Browsix to power a POSIX-compatible terminal.

This would be a great learning tool that could be directly integrated into workshops on learn.wordpress.org and similar. So you'd head to learn.wordpress.org, read through a tutorial to learn something new, and then click on the Try it yourself button to launch a full environment in your browser that has a running WordPress site and all the dev tooling you need.

I had been discussing this idea with @danielbachhuber to maybe introduce it for this year's Cloudfest Hackathon. @adamziel Is that something you might potentially be interested in?

[adamziel]

Yes, yes, yes! I love it @schlessera !

What exists today is a CodeMirror integration with an in-browser rollup, babel, and React Fast Refresh:

Code.editor.HMR.demo.mp4

In a perfect world, there would be a configurable in-browser Visual Studio Code instance with full support for WP-CLI, composer, npm, WordPress plugins/themes/patterns directory, and the ability to feed custom instructions. Much like Stackblitz. It could even be configurable as a Gutenberg block.

During the hackaton we could try to bridge as much of the gap between these two as possible.

Specifically, we could explore the following results:

• Integrate WP-CLI in a POSIX-compatible terminal
• Build an embeddable code editor that runs code in WordPress
• Make composer install work (requires networking support)

The less backend is required, the easier it will be to host it on WP.org.

I'll find out if I can still attend on behalf of Automattic and let you know – I assume it'd fine if I propose a project? Or would you like to?

[schlessera]

Awesome! Yes, please go ahead and propose a project. Also make sure to get in touch with @danielbachhuber internally, and Angela Jin who is in touch with the organizers already.

I'm one of the two project mentors of this year's hackathon, so I'm happy to give feedback or hop on a call to discuss as you see fit - just ping me in Slack if you want to discuss in any form.

[danielbachhuber]

I'll find out if I can still attend on behalf of Automattic and let you know – I assume it'd fine if I propose a project? Or would you like to?

@adamziel Oh! I thought you were going on sabbatical and unable to attend. If this is not the case, I'd love to work with you on the project. I already submitted this particular project idea but happy to transfer it to you or work on it as co-leads.

In a perfect world, there would be a configurable in-browser Visual Studio Code instance with full support for WP-CLI, composer, npm, WordPress plugins/themes/patterns directory, and the ability to feed custom instructions.

What is the technical feasibility of these elements, as well as git pull, git commit, and git push operations?

[eliot-akira]

There's an article titled, Postgres WASM by Snaplet and Supabase (Oct 2022).

postgres-wasm is a PostgreSQL server that runs inside a browser. It provides a full suite of features, including persisting state to browser, restoring from pg_dump, and logical replication from a remote database.

It describes an experimental project where they used Buildroot to create a minimal Linux build with Postgres, then ran it on a virtual machine in the browser using v86.

v86 emulates an x86-compatible CPU and hardware. Machine code is translated to WebAssembly modules at runtime in order to achieve decent performance.

For network access, they adapted a fork of Websockproxy which "allows the emulator to talk to the internet by converting data sent over a websocket port into TCP packets". (See also v86 networking.)

They've open-sourced the work in packages:

• Buildroot configuration to build a v86 compatible minimal Linux system containing PostgreSQL
• Postgres Browser - Web shell to interact with PostgreSQL in the browser
• WebSockets Proxy - A websocket ethernet switch built using Tornado in Python

Although they're likely not usable as-is, it seems they share some similar building blocks required (if not the code then the concepts) to host WordPress, PHP, and SQLite running on Linux in a virtual x86 machine, all in the browser.

Since it implements the whole stack down to the machine, this approach could theoretically support any software that runs in a standard Linux environment, including: Git, WP-CLI, Composer, Node.js and NPM, regular UNIX commands, interactive shell and terminal. That seems ideal for educational and practical purposes.

A disadvantage is the weight of the WASM bundle, which in their case was about 30Mb (then optimized to 12 by mounting a compressed file system using 9P). And the complexity of hosting, since it's no longer just a static site but with a corresponding server to enable network access and maybe persistence - features where browser support is currently lacking.

[adamziel]

Oh! I thought you were going on sabbatical and unable to attend. If this is not the case, I'd love to work with you on the project. I already submitted this particular project idea but happy to transfer it to you or work on it as co-leads.

@danielbachhuber I will be on sabbatical (unless I move it), but I'm excited about this project and will gladly show up anyway :-) We'll figure out the logistics

In a perfect world, there would be a configurable in-browser Visual Studio Code instance with full support for WP-CLI, composer, npm, WordPress plugins/themes/patterns directory, and the ability to feed custom instructions.

What is the technical feasibility of these elements, as well as git pull, git commit, and git push operations?

@eliot-akira covered the WASM part well so I will focus on the transport.

Composer, npm, WP.org directories, and git can all run over HTTPS which the browser already speaks.

A regular fetch() could work with WP.org directories, packagist.org, and npmjs.com as they seem to ship the right Allow-* headers. Yay!

github.com, however, does not support cross-origin fetch(). Service workers used to have foreign fetch, but it's been removed. The only other option to make fetch() work is a proxy API endpoint, but I don't like deploying one on wp.org as it would also cause serious maintenance and security issues.

How about supporting git via a browser extension? Extensions can request arbitrary HTTP endpoints without the same restrictions as web apps. Chrome extensions even used to support socket.tcp, but unfortunately that's deprecated now. NaCL native apps are also deprecated.

Relatedly, navigator.openTCPSocket in the web app (not in the extension) seems to be under development in Chrome. It could enable moving away from a web extension at one point.

[adamziel]

I wonder how easy would it be to integrate https://busybox.net/live_bbox/live_bbox.html

[schlessera]

@adamziel I don't think that is relevant. This is not POSIX software compiled to run in WASM, it is a PC emulator written in JS. This emulates hardware in JS, so the software is just the regular compilation of the x86 stuff. You'd basically start from scratch and would need to implement a bridge layer that connects the internals of that emulator (network stack, etc...) to the WASM/WASI layer you have now.

[AbeEstrada]

I also was trying to use the cli as a dev environment and install some packages, this can be very useful if Composer gets support.

$ npx @php-wasm/cli composer.phar --help

WASM ERROR
FS error

node:internal/process/promises:289
            triggerUncaughtException(err, true /* fromPromise */);
            ^

[UnhandledPromiseRejection: This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason "ErrnoError: FS error".]