Simplify vm.Module

[GeoffreyBooth]

One thing that comes up in user feedback about the vm.Module API is that it requires excessive boilerplate, as you can see in the example in the docs: https://nodejs.org/api/vm.html#class-vmmodule. I think that most users want a straightforward ESM equivalent to vm.Script, without needing to define a context or a custom function for linking; the default should be to link modules as Node itself normally does. See also #43288 (comment).

[legendecas]

There are several open issues on vm.SourceTextModule, like:

• SourceTextModule: Using dynamic imports while passing cachedData throws TypeError: Invalid host defined options #43663
• await Promise.resolve("import('./mod.mjs')").then(eval) rejects/segfaults in REPL #43681

I'm still looking into these problems as part of the effort on bringing module support to ShadowRealm in Node.js, but they depend on the work on the v8 side to enable arbitrary values to be saved in the host_defined_options and the v8 team is also working on refactoring how host_defined_option takes effects on code caching (https://docs.google.com/document/d/1vyfTs9pJVeDeguSVhYts3uolkhPk03eg5IvJeSR4IKI/edit#).

Also, there is a roadmap issue for stabling VM modules: #37648.

[devsnek]

closing as a duplicate of #37648

[GeoffreyBooth]

Thanks. I guess what's missing in that issue that I have here are the UX concerns, about using good defaults so that users can reduce boilerplate. I couldn't find an issue for that part, which maybe we could tackle now while we wait for V8?

[devsnek]

there are a lot of footguns you can hit if you are not careful with the vm api. for example when you point vm modules at node's main context, you create a memory leak which can't be fixed without changes to v8. i'm all for improving the vm api of course, but be wary that you'll likely hit lots of annoying roadblocks on the v8 side.

[GeoffreyBooth]

I didn't say it would be easy 😀 but I think reducing the complexity is a worthy goal. If that request isn't captured elsewhere, perhaps this issue should stay open to track that?

[GeoffreyBooth]

Reopening to focus on the UX changes. If that’s duplicated elsewhere we can close.