Skip to content

Latest commit

 

History

History
105 lines (94 loc) · 7.27 KB

guest-js-03-05-2025.md

File metadata and controls

105 lines (94 loc) · 7.27 KB

March 5, 2025 | JavaScript subgroup (BA Guest Languages SIG)

Agenda

  1. Opening, welcome and roll call
    1. Note: meeting notes linked in the invite.
    2. Please help add your name to the meeting notes.
    3. Please help take notes.
    4. Thanks!
  2. Announcements
    1. Submit a PR to add your announcement here
  3. Other agenda items
    1. Submit a PR to add your item here

Attendees

Attendee
Calvin Preweitt
Guy Bedford
Till Schneidereit
Tomasz Andrzejak
Victor Adossi

Notes

StarlingMonkey

  • Tomasz: EventTarget and EventInterface implementation has started
  • Tomasz: Started drafting AbortSignal & AbortController
  • Till: Doing work towards debugging support
    • bytecodealliance/StarlingMonkey#222
    • Add support for running a script before the main one
    • One thing to support would be enabling installing builtins to privileged code, w/ a reference to the content global, which will allow us to do polyfills (good as an option)
    • This enables builtin modules, so in Componentizewe can move away from pre-processing source code.
    • We should be able to split componentization into two parts:
      • Splice & reuse the component
      • Build an empty shell and load the JS from disk
    • This should enable fast development cycles and faster debugging
    • Guy: Yes, you could almost pre-build the SDK – creating the shape of the component and swapping out the contents.
      • Till: Starling does this with componentize.sh script without a source file, then you get a contentless component, and it will try to load an index.js file, which can be overridden with ENV vars
      • It doesn’t do pre-initialization
      • Does the same thing as wizer – host API checks when a request comes in if a handler has been set, and if not calls the main function which does init & runs top level code and sets the event handler
      • Guy: So the debug entrypoint is somewhat separate
        • Till: yes, there’s nothing in particular that makes it non production worthy, it’s just a bit slower
        • Important for the zed usecase as well, they can get an empty shell that has the SDK wired up, and the plugins can be just JS.
      • Guy: So they could make a pre-built shell
        • Till: Yes they could build one with their world and use a preopen to pull the scripts and run them.
        • Guy: So their users are not publishing components but rather javascript
        • Till: Yes, and they save even more by not having to ship the wizer preinit
        • Till: Ideally there could be a shared runtime per-WIT world which has the pre-init script and then bundle that
        • Guy: Understanding was similar to what Javy is doing where they import the platform runtime and looking into what that would entail with layered wizering
          • Till: we can do that as well, and it should be easier since dynamic linking is not required. It should only require building StarlingMonkey as it is right now and making sure that evaluating a JS file and handling incoming requests are exported w/ a tiny shell module that invokes the functions (no mem mgmt)
          • Component needs to wire that up as instantiations – import the same memory and the shell just imports the same memory after SpiderMonkey and Wizer takes a snapshot of that.
          • Should work without throwing out Wizer snapshotting mechanism
        • Guy: Another way of doing the defined builtin api could be how node does it the createDynamicModule API , w/ the input being the list of dynamic bindings, and a callback w/ a controller that can call setExport.
          • Till: Is there a place where that would be more expressive?
          • Guy: If you need mutable bindings in your host interface (probably not needed in most cases)
        • Guy: PR looks good to me

ComponentizeJS

  • Release out
  • Debug build is confirmed working

Jco

  • Guy: Jco release cycle done, new contributor improved typescript generation
    • Bug report from a user since there was a breaking change, but this might also have been a bugfix
    • There’s a distinction between compile time errors and their runtime errors, so not necessarily a breaking change.
    • Frustrated user means we have users, which is nice
    • New code looks more correct
    • Victor: we might need coverage for namespace collisions
      • Guy: Each interface is its own file, and those files have deduping between them, and the WIT level deduping should also handle
      • Victor: was referring to a specific top level file that combines interfaces (wit.d.ts) which imports everything, so
      • Guy: The goal model for the typing – for host bindgen the types should be for the component, that typing should not represent a folder, only a single component
      • Victor: Guest types are where this might show up
      • Guy: Guest types are still experimental, and this is where we might need to be more careful
    • Guy: we should get to a point where you can just transpile and get the right types in VSCode
  • Guy: Another fix for trampoline setup (early vs late) – late trampolines need more information (particularly resources). This stuff isn’t set in stone though
  • Guy: Great to see the WebIDL progress as well, want to share what you’re doing?
  • Guy: P3 Async PR?
    • bytecodealliance/jco#585
    • (WALKTHROUGH OF CODE)
    • Victor: early implementation of async support for Jco
    • We use an error-context component from the wasip3-prototyping repo
    • We may be able to move to an officially released wasmtime-environ, but otherwise the branches will have to be long lived
    • Most implementation is in the trampolines and transpile_bindgen.rs
    • Guy: It would be great if we could output a warning about async being experimental at transpile time

Node WASI subgroup

  • Notes related to Node WASI subgroup go here