Skip to content

modules: implement deferred import for dynamic modules - #66727

Open
MayaLekova wants to merge 1 commit into
nodejs:mainfrom
MayaLekova:import-defer-06-dynamic-imports
Open

MayaLekova wants to merge 1 commit into
nodejs:mainfrom
MayaLekova:import-defer-06-dynamic-imports

Conversation

@MayaLekova

Copy link
Copy Markdown
Contributor

modules: implement deferred import for dynamic modules

This PR adds support for deferring the import of modules in additional
cases, such as importing a dynamic module. It also adds a test for
this case.

Refs: https://github.com/tc39/proposal-defer-import-eval
Signed-off-by: Maya Lekova maya@igalia.com

@nodejs-github-bot

Copy link
Copy Markdown
Collaborator

Review requested:

  • @nodejs/loaders
  • @nodejs/security-wg
  • @nodejs/startup
  • @nodejs/typescript
  • @nodejs/vm

@nodejs-github-bot nodejs-github-bot added c++ Issues and PRs that require attention from people who are familiar with C++. esm Issues and PRs related to the ECMAScript Modules implementation. lib / src Issues and PRs involving general changes in the lib/ or src/ directories. needs-ci PRs that need a full CI run. strip-types Issues and PRs related to TypeScript type stripping. labels Oct 14, 2026
@MayaLekova
MayaLekova force-pushed the import-defer-06-dynamic-imports branch 2 times, most recently from f8ef554 to 503ed1f Compare October 15, 2026 13:08
@MayaLekova

MayaLekova commented Oct 15, 2026 •

Copy link
Copy Markdown
Contributor Author

I tried fixing the cctest failures, but apparently the change to ModuleWrap::Evaluate signature also changed the behaviour of the VM module. Still experiencing this error:

(node:50255) ExperimentalWarning: VM Modules is an experimental feature and might change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
node:internal/vm/module:215
      validateObject(options, 'options');
      ^

TypeError [ERR_INVALID_ARG_TYPE]: The "options" argument must be of type object. Received type number (-1)
    at SourceTextModule.evaluate (node:internal/vm/module:215:7)
    at /home/maya/Work/node/out/Release/cctest:1:328
    at process.processTicksAndRejections (node:internal/process/task_queues:104:5) {
  code: 'ERR_INVALID_ARG_TYPE'
}

@joyeecheung just FYI, I'll keep trying to fix it.

Comment thread test/cctest/test_environment.cc Outdated
"});"
"await m.link(() => 0);"
"await m.evaluate();"
"await m.evaluate(-1, false, 3);"

@joyeecheung joyeecheung Oct 15, 2026 •

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the public API for the vm API, which is not used by the built-in loader at all, and it's not the same as the module wrap's evaluate, which is internal and used by both. There's no need to touch this.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gotcha, I don't know why exactly it hits the changed version of ModuleWrap::Evaluate. Without it, the same test crashes, but with different error:

[ RUN      ] EnvironmentTest.EnvironmentWithESMLoader
(node:156113) ExperimentalWarning: VM Modules is an experimental feature and might change at any time
(Use `node --trace-warnings ...` to show where the warning was created)

  #  Node.js[156113]: static void node::loader::ModuleWrap::Evaluate(const v8::FunctionCallbackInfo<v8::Value>&) at ../../src/module_wrap.cc:789
  #  Assertion failed: (args.Length()) == (3)

----- Native stack trace -----

 1: 0x5eb63c38fce4  [out/Release/cctest]
 2: 0x5eb63c3909f9 node::Assert(node::AssertionInfo const&) [out/Release/cctest]
 3: 0x5eb63c30ddd4 node::loader::ModuleWrap::Evaluate(v8::FunctionCallbackInfo<v8::Value> const&) [out/Release/cctest]
 4: 0x785c5e58ffe9 

----- JavaScript stack trace -----

1: evaluate (node:internal/vm/module:233:26)
2: /home/maya/Work/node/out/Release/cctest:1:328
3: processTicksAndRejections (node:internal/process/task_queues:104:5)

Aborted (core dumped)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is the public API wrapper, I think you need to pass in kEvaluationPhase in

return this[kWrap].evaluate(timeout, breakOnSigint);
- it will be a different matter to actually allow users to customize it in the API.

@joyeecheung

Copy link
Copy Markdown
Member

Can you drop the amaro update commit? I don't think that's supposed to be in this PR?

This PR adds support for deferring the import of modules in additional
cases, such as importing a dynamic module. It also adds a test for
this case.

Refs: https://github.com/tc39/proposal-defer-import-eval
Signed-off-by: Maya Lekova maya@igalia.com
@MayaLekova
MayaLekova force-pushed the import-defer-06-dynamic-imports branch from 503ed1f to 930f23f Compare October 16, 2026 16:07
@MayaLekova

Copy link
Copy Markdown
Contributor Author

Can you drop the amaro update commit? I don't think that's supposed to be in this PR?

Yep, done.

@MayaLekova MayaLekova closed this Oct 16, 2026
@MayaLekova MayaLekova reopened this Oct 16, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

c++ Issues and PRs that require attention from people who are familiar with C++. esm Issues and PRs related to the ECMAScript Modules implementation. lib / src Issues and PRs involving general changes in the lib/ or src/ directories. needs-ci PRs that need a full CI run. strip-types Issues and PRs related to TypeScript type stripping.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants