Playground Editor V2: Multi-file, ES modules, NPM Support #17175
Conversation
…styling, inline definitions and navigation to symbols
…nnable compiled by monaco ts worker
|
Devhost visualization test reporter: |
|
Visualization tests for WebGPU |
|
WebGL2 visualization test reporter: |
…odule resolution qol
|
Reviewer - this PR has made changes to one or more package.json files. |
|
Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s). |
|
Reviewer - this PR has made changes to one or more package.json files. |
|
Snapshot stored with reference name: Test environment: To test a playground add it to the URL, for example: https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/refs/pull/17175/merge/index.html#WGZLGJ#4600 Links to test babylon tools with this snapshot: https://playground.babylonjs.com/?snapshot=refs/pull/17175/merge To test the snapshot in the playground with a playground ID add it after the snapshot query string: https://playground.babylonjs.com/?snapshot=refs/pull/17175/merge#BCU1XR#0 |
|
You have made possible changes to the playground. https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/PLAYGROUND/refs/pull/17175/merge/ The snapshot playground with the CDN snapshot (only when available): Note that neither Babylon scenes nor textures are uploaded to the snapshot directory, so some playgrounds won't work correctly. |
|
You have changed file(s) that made possible changes to the sandbox. https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/SANDBOX/refs/pull/17175/merge/ |
|
Devhost visualization test reporter: |
|
WebGL2 visualization test reporter: |
|
Visualization tests for WebGPU |
This PR updates the Playground search page to handle the new manifest that the Playground V2 uses (from this PR: BabylonJS/Babylon.js#17175). The schema of the manifest of the PG V2 is defined as: ``` export type V2Manifest = { v: 2; language: "JS" | "TS"; entry: string; imports: Record<string, string>; files: Record<string, string>; cdnBase?: string; }; ``` For search, we care about the _files_ property, which contains pairs with the name of the file and the code of the file. Most of the parsing changes are related to dealing with the fact that now there are multiple files to search in a PG and to surface the name of the file where the code is found (if we are searching by Code). All search behavior is identical for V1 and V2, except for the following changes: - If the playground is a V2 playground, when searching for code with an exact match the name of the file will be printed with the results: <img width="1869" height="1069" alt="image" src="https://github.com/user-attachments/assets/72d96489-08e8-41ae-a065-08c3dee4abbf" /> - Ellipsis in the code are removed for long lines, this is done to simplify the code that handles finding the correct line and the current page handles long lines correctly by wrapping the lines.
|
I noticed that when you copy an import like 
If you remove the "./" and add it back, the error disappears. |
Nice catch, the issue was some initial ambient module declaration that shadowed the real module. Tested some cases locally and pushed the change here |
|
Reviewer - this PR has made changes to one or more package.json files. |
|
You have changed file(s) that made possible changes to the sandbox. https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/SANDBOX/refs/pull/17175/merge/ |
|
You have made possible changes to the playground. https://snapshots-cvgtc2eugrd3cgfd.z01.azurefd.net/PLAYGROUND/refs/pull/17175/merge/ The snapshot playground with the CDN snapshot (only when available): Note that neither Babylon scenes nor textures are uploaded to the snapshot directory, so some playgrounds won't work correctly. |
|
Devhost visualization test reporter: |
|
Visualization tests for WebGPU |
|
WebGL2 visualization test reporter: |
|
@VicenteCartas is it ok to merge now? |
First I'd like to apologize for the size of this PR. It started as a proof of concept and slowly turned into a large undertaking that necessitated a full pass at compatibility and potential regressions. There are also features baked into this whole system that aren't necessary to the core elements. I appreciate the risk of a merge this big so welcome any opportunity to make it accessible. I also have been using this version since its inception and am coming away with a very new and fresh perspective on using the PG to iterate and build out code + showcase work. I'll try to keep the rest brief:
Goals:
Adding new functionality to the Playground Code Editor to support larger / more complex examples as well as have it serve as a unique sandbox for BJS developers to prove out their code in a more fully-fledged environment.
Non-goals:
"Refactoring" for the sake of refactoring, or injecting unnecessary changes based on my style, preference, modern standards, yada yada... I tried to conform to the existing architecture where possible and otherwise keep SOLID principles in play. The linting standards really helped keep things cohesive!
Full feature set:
import MyClass from './module.ts'import myDevClass from 'dev-package@local'provides a code lens item to link the output directory though the FileSystem)#localrevision suffix or a dialog of managed sessionsCurrent deployment:
I have been deploying this through a lightweight vercel app which builds the core build dependencies and builds the SPA and serves directly. This is available at https://playgroundv2.vercel.app . It would likely be very helpful to get a request for feedback for use while this is deployed as it will reflect the current state of this branch.
Core arch changes:
Code is not stored as a single block of text now but rather a manifest JSON blob defined as
The used fields here are
language,entryandfileswhile the others are placeholders for additional enhancements/validation checks down the line, i.e. versioning for backwards compatibility.Compatibility:
All previous Playgrounds will be able to be loaded as-is and be compatible with this editor. Any saved PG moving forward will then save the JSON manifest blob and therefore not be backwards compatible. The idea being "this is what the spec is" moving forward and not having code paths to continue legacy save support.
User-facing changes:
From the user's perspective, new and existing Playgrounds will load as usual and the only noticeable difference will be the tab bar on the top of the editor. There's a lot going on beneath the hood but it shouldn't be a jarring UI change.
Tests performed:
I have tested the following:
Next steps
Documentation! And examples of the best ways to leverage this system.
Appreciate the time spent reading through this and taking the features into consideration. FWIW I have been a full stack dev for about a decade primarily working with React and have worked with Monaco in multiple projects, happy to commit to maintaining and improving these changes here when necessary.