Simplify vm.Module #43899

Activity

1. GeoffreyBooth

   added

   help wantedIssues that need assistance from volunteers or PRs that need help to proceed.Issues that need assistance from volunteers or PRs that need help to proceed.

   vmIssues and PRs related to the vm subsystem.Issues and PRs related to the vm subsystem.

   experimentalIssues and PRs related to experimental features.Issues and PRs related to experimental features.

   esmIssues and PRs related to the ECMAScript Modules implementation.Issues and PRs related to the ECMAScript Modules implementation.

   loadersIssues and PRs related to ES module loaders.Issues and PRs related to ES module loaders.

   never-staleIssues and PRs exempt from automated stale handling.Issues and PRs exempt from automated stale handling.

   on Jul 19, 2022
2. legendecas commented on Jul 19, 2022

   

   legendecas

   on Jul 19, 2022

   Last edited by legendecas

   Member

   More actions

   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.
3. devsnek commented on Jul 19, 2022

   

   devsnek

   on Jul 19, 2022

   Member

   More actions

   closing as a duplicate of #37648
4. devsnek

   closed this as completedon Jul 19, 2022
5. GeoffreyBooth commented on Jul 19, 2022

   

   GeoffreyBooth

   on Jul 19, 2022

   MemberAuthor

   More actions

   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?
6. devsnek commented on Jul 19, 2022

   

   devsnek

   on Jul 19, 2022

   Member

   More actions

   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.
7. GeoffreyBooth commented on Jul 19, 2022

   

   GeoffreyBooth

   on Jul 19, 2022

   MemberAuthor

   More actions

   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?
8. GeoffreyBooth

   changed the title [-]Stabilize vm.Module[/-] [+]Simplify vm.Module[/+] on Jul 20, 2022
9. GeoffreyBooth commented on Jul 20, 2022

   

   GeoffreyBooth

   on Jul 20, 2022

   MemberAuthor

   More actions

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

    reopened this on Jul 20, 2022
11. axkibe commented on Mar 31, 2023

    

    axkibe

    on Mar 31, 2023

    Last edited by axkibe

    Contributor

    More actions

    One API minor change that would simplify code a lot in I guess many use cases is to allow linker function in case the context is current execution to return a "Module Namespace Object" just like importModuleDynamically does already. But the linker doesn't like that.

    That means, in case one does not want to handle the linking with a custom function but forward it to node, one could simply "return import( specifier );" (also I guess a common case, user wants to extend something new, but for all other case have node.js handle it)

    Right now as far I understood, one must encapsulate a syntheticModule around it as like so:

        const mod = await import( specifier);
        const exportNames = Object.keys( mod );
        const imported =
            new vm.SyntheticModule(
                exportNames,
                ( ) =>{ exportNames.forEach( key => imported.setExport( key, mod[ key ] ) ); },
                {  identifier: specifier }
            );
        return imported;
    

    would become

        return import( specifier );
    

    I believe even no await needed, may return the promise directly. Actually the first case misses caching the results in a Map, something that also would be needed.

    PS: I currently finished changing a more complex system from CJS vm.Script.runInThisContext() with simulating handing down module/require to ESM with the new experimental SourceTextModule API, and while I agree there is room for improvement I must say, in practice everything is already so much cleaner now, because things are way more structured. Overall a huge improvement, albeit more boilerplate needed.
12. LeonxLJX commented on Sep 1, 2026

    

    LeonxLJX

    on Sep 1, 2026 · Hidden as low-quality

    show commentMore actions