What is the problem this feature will solve?
Dynamic imports in modules created by the vm:SourceTextModule currently return a promise created by the intrinsic Promise of the main realm and not the realm of the module. This can be a problem in practice because realms are commonly used to achieve test case isolation at a cheap performance cost. And these test cases might somehow rely on the identity of the constructor of promises returned by dynamic imports -- eg: https://github.com/tc39/test262/blob/c47b716e8d6bea0c4510d449fd22b7ed5f8b0151/test/language/expressions/dynamic-import/returns-promise.js
What is the feature you are proposing to solve the problem?
The problem comes from importModuleDynamicallyWrap which returns an async function:
|
function importModuleDynamicallyWrap(importModuleDynamically) { |
If we want preserve the promise constructor provided by the user-defined
importModuleDynamically , it should use explicit
then chaining. NB: I'm not sure there is no other async jump downstream that could cause the same issue.
What alternatives have you considered?
No response
What is the problem this feature will solve?
Dynamic imports in modules created by the
vm:SourceTextModulecurrently return a promise created by the intrinsic Promise of the main realm and not the realm of the module. This can be a problem in practice because realms are commonly used to achieve test case isolation at a cheap performance cost. And these test cases might somehow rely on the identity of the constructor of promises returned by dynamic imports -- eg: https://github.com/tc39/test262/blob/c47b716e8d6bea0c4510d449fd22b7ed5f8b0151/test/language/expressions/dynamic-import/returns-promise.jsWhat is the feature you are proposing to solve the problem?
The problem comes from
importModuleDynamicallyWrapwhich returns an async function:node/lib/internal/vm/module.js
Line 434 in a0cb507
If we want preserve the promise constructor provided by the user-defined
importModuleDynamically, it should use explicitthenchaining. NB: I'm not sure there is no other async jump downstream that could cause the same issue.What alternatives have you considered?
No response