-
-
Notifications
You must be signed in to change notification settings - Fork 33.1k
Description
What is the problem this feature will solve?
Currently as far I'm aware there is no way to use vm.SourceTextModule to run ESM code in the current context like it was possible with CJS with vm.runInThisContext().
What is the feature you are proposing to solve the problem?
Access to the current context as "contextObject" that can be supplied as context paramter to vm.SourceTextModule. Or the ability to give "globalThis" as context, right now the result is "TypeError [ERR_INVALID_ARG_TYPE]: The "options.context" property must be an vm.Context. Received an instance of Object"
What alternatives have you considered?
custom ESM loaders are of course now a very suitable alternative. (using a custom loader and then just calling dynamic import).
However in that case a way to add them on runtime would be needed. (effective for dynamic imports of course, and static from dynamically added, all static one from entry point of course need to have been resolved without)
Right now as alternativ I do use vm.SourceTextModule in a separate context and whenever something inside wants to import something that should resolve into the current node.js context, I'm calling import and then create a synthetic module as glue. It works, albeit there are a lot of caveats, since from a coders perspective it should be one context, and breakare of instanceof to ES basic objects can for example be nasty. (see ldapjs/node-ldapjs#864, or I had another case where some Sets are no longer instance of Set, but there isn't a Set.isSet like Array.isArray)