re-add VM modules to our fork

[MylesBorins]

Based on today's call does it make sense for us to rebase out the removal of VM modules?

[guybedford]

Sounds good to me.

[jdalton]

I still lean -1 on inclusion.

[devsnek]

i'm in favour of including it. it's totally safe to make breaking changes to it, as it's under --experimental-vm-modules

[MylesBorins]

@jdalton can you please expand on your objection based on the consensus we had in the meeting earlier?

[jdalton]

AFAIK we had no formal consensus to add back the VM module. I do not feel the VM additions are a hard requirement to ship in April and think they can live in other places/repos within the Node org if needed.

[MylesBorins]

@jdalton to be explicit my ask is to remove the commit that "removes" VM modules and move that work to core. Essentially freeing us from the responsibility.

[jdalton]

I prefer it stay removed.

[devsnek]

@jdalton vm.Module was added separately from the goals of this group, for uses outside of the goals of this group. I'm ok with the API being in flux and being modified to suit the internal design of our system, but it has to remain when this process is over, outside of any decisions this specific group makes.

Because of this, I think it is a lot easier for us to work with it rather than pretend it doesn't exist. If we pretend it doesn't exist, the burden falls on me or one of the other vm maintainers to muck through months of changes to internals to add it back.

[jdalton]

@devsnek

vm.SourceTextModule was added separately from the goals of this group, for uses outside of the goals of this group.

IMO the vm.SourceTextModule should not exist without our module implementation and is directly impacted by our design choices. It feels like a disconnect to consider it as something completely separate and outside the goals of this group. IMO It's within the scope of the WG, additive, but not required for April.

[devsnek]

@jdalton i agree that it's connected, my point is that it exists whether or not node runs esm, as the reasons it was added in fact had nothing to do with node running esm files. if you want to remove it from core, you'll need to work with people in core to do so, not this group specifically.

[jdalton]

Our existing --experimental-modules and --experimental-vm-modules are subject to radical change depending on what lands in April. My preference is for its continued removal from our fork.

[devsnek]

@jdalton sure, i'm not against radical change, i'm just strongly advising against not having vm modules, because its out of the scope of this group to remove it, the same way its out of the scope of this group to remove fs.promises.

In april if we want to remove vm.SourceTextModule from core entirely we need to have consensus to do so from the vm team.

[jdalton]

@devsnek Thank you for your point of view. I see it differently is all.
Failing consensus, if it falls to a vote in the group that's okay.

[zenparsing]

@devsnek

the reasons it was added in fact had nothing to do with node running esm files

Can you tell me more about this?

[devsnek]

@zenparsing Simply put, vm.SourceTextModule was added to fulfill the design goals of VM, which are exposing APIs to evaluate JS. From the docs of VM:

VM (Executing JavaScript)
The vm module provides APIs for compiling and running code within V8 Virtual Machine contexts.

The specific design of the vm.SourceTextModule API was shaped by the spec text, and by some input from JSDOM.