Monorepo

[adamziel]

Restructures the repository as a monorepo and separates the PHP implementation from the WordPress-specific bits.

Notably, this PR removes node.js-specific WordPress setup to help focus on the browser version. Building PHP to WASM with node.js as a target is still supported, but the express.js server and wp-specific logic is gone. Why? There's no good use-case to justify the effort of maintaining it. If one arises, I'm more than happy to bring it back, probably as a separate package.

The new packages:

• php-wasm – low-level WASM PHP primitives
  • A configurable PHP build pipeline for different targets (web, node.js)
  • A low-level PHP JavaScript class with eval for executing PHP code and FS utils like writeFile for runtime managing the
  • A PHPServer JavaScript class for dispatching HTTP requests – both to run the PHP files AND to download static files
  • A PHPBrowser JavaScript class to consume the above using an iframe
• php-wasm-browser – a high-level layer to efficiently run php-wasm in the browser
  • service-worker utilities to redirect the browser traffic to PHPServer
  • worker-thread utilities to offload the PHPServer to a separate process. Three backends are available: Iframe, Webworker, SharedWorker.
  • A messaging layer and setup helpers to connect the above.
  • Server utilities to serve the correct headers for the wasm files via .htaccess.
• wordpress-wasm – WordPress-specific WASM PHP bindings for web and node.js
  • The required WordPress-specific setup like constants and filters
  • wp.data bundling pipeline for the web configurable to bundle custom code
  • WordPress API to ease common tasks like login, install a plugin, start a block editor with specific settings and content
  • A fetch-based transport for HTTP requests
  • An example app demonstrating WordPress in the browser. Let's eventually extract it into a separate package or at least a directory.

Other, general notes:

• Pre-built binaries are shipped in the global build directory – it would be nice to either move them to their specific packages, or to remove them from the repo entirely. In the latter case the initial build would download them from somewhere to avoid bad developer experience of having to go through a full build before even getting started.
• esbuild is used to build each packages and then the entire app.
• Gulp is used for orchestration. Perhaps https://nx.dev/ would make a good replacement in the future.
• There is no package publishing process yet. Perhaps Lerna would make a good one?

Solves #51 and #16

[adamziel]

There are some rough edges, but it's a good start so I'll go ahead and merge.

[adamziel]

Follow-up issue: #58