Skip to content

Conversation

adamziel
Copy link
Collaborator

Motivation for the change, related issues

Implementation details

Testing Instructions (or ideally a Blueprint)

Base automatically changed from remove-on-before-blueprint to trunk September 12, 2025 22:12
@adamziel
Copy link
Collaborator Author

I'm no longer sure if blueprint.setWpVersion( "6.8" ) is the right way to model this. It may work for Blueprints v1 that we have to process in full in TypeScript anyway. A Blueprint v2 might be just a URL or a Git repo description. We need to be able to read the metadata in TypeScript, at least the PHP version number, but overriding parts of the blueprint.json that's shipped in a bundle gets troublesome. How do we pass a bundle (Filesystem instance) with overrides into PHP? Also, how should TypeScript handle overrides if we're fed 4 Blueprints for merging?

A more useful model seems to be:

  1. Have a small TypeScript kernel that can read the PHP version from the Blueprint
  2. Run that PHP instance and pass the original Blueprint reference to PHP
  3. PHP downloads the data, parses it etc. and calls a filter/action similar to blueprint_overrides
  4. Playground website registers a callback that applies overrides

@adamziel adamziel closed this Sep 13, 2025
@adamziel adamziel reopened this Sep 13, 2025
@adamziel
Copy link
Collaborator Author

adamziel commented Sep 13, 2025

I'm no longer sure if blueprint.setWpVersion( "6.8" ) is the right way to model this. It may work for Blueprints v1 that we have to process in full in TypeScript anyway. A Blueprint v2 might be just a URL or a Git repo description. We need to be able to read the metadata in TypeScript, at least the PHP version number, but overriding parts of the blueprint.json that's shipped in a bundle gets troublesome. How do we pass a bundle (Filesystem instance) with overrides into PHP? Also, how should TypeScript handle overrides if we're fed 4 Blueprints for merging?

A more useful model seems to be:

  1. Have a small TypeScript kernel that can read the PHP version from the Blueprint
  2. Run that PHP instance and pass the original Blueprint reference to PHP
  3. PHP downloads the data, parses it etc. and calls a filter/action similar to blueprint_overrides
  4. Playground website registers a callback that applies overrides

This means we need to:

  • Handle the URL -> Blueprint overrides translation in the worker where PHP runs. So ?php=8.3&core-pr=59384 needs to be resolved not in the main JS thread on the website, but in the worker class.
  • Blueprints v1 and v2 need separate handlers for all the Query API features supported by Playground. This could be a good opportunity for code reuse between CLI and web – both will now have classes encapsulating Playground boot flow, here's our chance to unify the Query API options and CLI API options even more.

@adamziel adamziel closed this Oct 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant