Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

esm: Source Phase Imports for WebAssembly #56919

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

guybedford
Copy link
Contributor

@guybedford guybedford commented Feb 5, 2025

This implements the Stage 3 Source Phase Imports proposal for Node.js (with latest specification at tc39/ecma262#3492), based on the new V8 parser and module loading APIs for this feature.

Phases in the module pipeline represent the ability to load uninstantiated modules (and in future with import defer, unexecuted modules as well).

While we are still waiting for progression on https://github.com/tc39/proposal-esm-phase-imports for JS Source Phase objects, this implements only the WebAssembly source phase per the Wasm ESM Integration Phase 3 proposal (https://github.com/webassembly/esm-integration).

This PR adds support both for dynamic and static source phase syntax:

import source mod1 from './mod.wasm';
const mod2 = await import.source('./mod.wasm');

This allows obtaining a Wasm module through the ESM integration, without it being instantiated through the Node.js resolver, to permit custom instantiations:

import source mod from './mod.wasm';

const instance = await WebAssembly.instantiate(mod, imports);

The dynamic source phase support is a one-line TODO, which is pending #56842. When this lands the skipped tests have been tested against that branch to fully pass.

When a source phase representation for a module is not available, a new ERR_SOURCE_PHASE_NOT_DEFINED SyntaxError is thrown as per the standard.

The VM API is updated to take a string phase argument as its last argument, although the ability to define source phase representations for virtual modules is not currently supported, and left as a future integration point. Perhaps this will simplify with ESM Phase Imports in future as well allowing handles to modules outside of the VM graph.

Resolves #53178.

@nodejs/loaders

@nodejs-github-bot
Copy link
Collaborator

Review requested:

  • @nodejs/loaders
  • @nodejs/startup
  • @nodejs/vm

@nodejs-github-bot nodejs-github-bot added lib / src Issues and PRs related to general changes in the lib or src directory. needs-ci PRs that need a full CI run. labels Feb 5, 2025
@guybedford guybedford force-pushed the source-phase-imports branch 2 times, most recently from c485531 to 8b3ce05 Compare February 5, 2025 02:31
@guybedford guybedford changed the title esm: Support Source Phase Imports for WebAssembly esm: Source Phase Imports for WebAssembly Feb 5, 2025
Copy link

codecov bot commented Feb 5, 2025

Codecov Report

Attention: Patch coverage is 82.15488% with 53 lines in your changes missing coverage. Please review.

Project coverage is 89.09%. Comparing base (79f96b6) to head (81890a1).
Report is 2 commits behind head on main.

Files with missing lines Patch % Lines
src/module_wrap.cc 62.50% 23 Missing and 13 partials ⚠️
lib/internal/modules/esm/module_job.js 89.77% 9 Missing ⚠️
lib/internal/modules/esm/loader.js 87.50% 3 Missing and 1 partial ⚠️
lib/internal/vm/module.js 85.71% 3 Missing ⚠️
lib/repl.js 75.00% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main   #56919      +/-   ##
==========================================
- Coverage   89.10%   89.09%   -0.02%     
==========================================
  Files         665      665              
  Lines      193203   193400     +197     
  Branches    37220    37246      +26     
==========================================
+ Hits       172158   172312     +154     
- Misses      13771    13806      +35     
- Partials     7274     7282       +8     
Files with missing lines Coverage Δ
lib/internal/modules/cjs/loader.js 98.26% <100.00%> (ø)
lib/internal/modules/esm/translators.js 91.51% <100.00%> (+0.06%) ⬆️
lib/internal/modules/esm/utils.js 98.90% <100.00%> (+0.01%) ⬆️
lib/internal/modules/run_main.js 97.60% <100.00%> (ø)
lib/internal/process/execution.js 94.79% <100.00%> (-0.16%) ⬇️
lib/internal/vm.js 100.00% <100.00%> (ø)
src/module_wrap.h 0.00% <ø> (ø)
src/node.cc 73.69% <100.00%> (+0.11%) ⬆️
src/node_errors.h 88.46% <100.00%> (+3.46%) ⬆️
lib/repl.js 94.90% <75.00%> (-0.05%) ⬇️
... and 4 more

... and 23 files with indirect coverage changes

Copy link
Member

@mcollina mcollina left a comment

Choose a reason for hiding this comment

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

lgtm

@mcollina mcollina added the request-ci Add this label to start a Jenkins CI on a PR. label Feb 5, 2025
@github-actions github-actions bot removed the request-ci Add this label to start a Jenkins CI on a PR. label Feb 5, 2025
@nodejs-github-bot
Copy link
Collaborator

@marco-ippolito marco-ippolito added esm Issues and PRs related to the ECMAScript Modules implementation. wasm Issues and PRs related to WebAssembly. labels Feb 5, 2025
@targos targos added dont-land-on-v18.x PRs that should not land on the v18.x-staging branch and should not be released in v18.x. dont-land-on-v20.x PRs that should not land on the v20.x-staging branch and should not be released in v20.x. dont-land-on-v22.x PRs that should not land on the v22.x-staging branch and should not be released in v22.x. dont-land-on-v23.x PRs that should not land on the v23.x-staging branch and should not be released in v23.x. semver-minor PRs that contain new features and should be released in the next minor version. labels Feb 5, 2025
@legendecas legendecas linked an issue Feb 5, 2025 that may be closed by this pull request
* @param {ModuleWrap|ContextifyScript|Function|vm.Module} callbackReferrer
* @param {Record<string, string>} attributes
* @param {string} phase
* @returns { Promise<void> }
Copy link
Member

Choose a reason for hiding this comment

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

Is this return value type correct? I think it should be Promise<ModuleNamespace|vm.Module>

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No it's not - but this is a move of an existing definition, so this is as it's currently written on main.

Copy link
Contributor

Choose a reason for hiding this comment

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

Unless we never want to fix it, we should probably fix it on main first, then move it in this PR

Copy link
Member

Choose a reason for hiding this comment

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

guybedford and others added 4 commits February 13, 2025 10:07
Co-authored-by: Antoine du Hamel <duhamelantoine1995@gmail.com>
Co-authored-by: Michaël Zasso <targos@protonmail.com>
@nodejs-github-bot
Copy link
Collaborator

@@ -607,8 +623,7 @@ void ModuleWrap::Evaluate(const FunctionCallbackInfo<Value>& args) {
}

if (try_catch.HasCaught()) {
if (!try_catch.HasTerminated())
try_catch.ReThrow();
if (!try_catch.HasTerminated()) try_catch.ReThrow();
Copy link
Contributor

Choose a reason for hiding this comment

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

This looks like an unrelated change that's going to make backporting stuff needlessly harder, could we get rid of it?

Comment on lines +644 to +645
USE(module->InstantiateModule(
context, ResolveModuleCallback, ResolveSourceCallback));
Copy link
Contributor

Choose a reason for hiding this comment

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

Same here

Comment on lines +541 to +542
USE(module->InstantiateModule(
context, ResolveModuleCallback, ResolveSourceCallback));
Copy link
Contributor

Choose a reason for hiding this comment

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

Same here

@@ -551,7 +567,7 @@ void ModuleWrap::Evaluate(const FunctionCallbackInfo<Value>& args) {
ContextifyContext* contextify_context = obj->contextify_context_;
MicrotaskQueue* microtask_queue = nullptr;
if (contextify_context != nullptr)
microtask_queue = contextify_context->microtask_queue();
microtask_queue = contextify_context->microtask_queue();
Copy link
Contributor

Choose a reason for hiding this comment

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

Same here

Comment on lines +985 to +988
if (import_callback
->Call(
context, Undefined(isolate), arraysize(import_args), import_args)
.ToLocal(&result)) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Same here

Environment* env = Environment::GetCurrent(context);
if (env == nullptr)
return;
if (env == nullptr) return;
Copy link
Contributor

Choose a reason for hiding this comment

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

Same here

Comment on lines +1089 to +1092
obj->object()->SetInternalField(kSyntheticEvaluationStepsSlot,
Undefined(isolate));
MaybeLocal<Value> ret =
synthetic_evaluation_steps->Call(context, obj->object(), 0, nullptr);
Copy link
Contributor

Choose a reason for hiding this comment

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

Same here

'--eval',
[
'import { strictEqual } from "node:assert";',
`import * as wasmExports from ${JSON.stringify(fixtures.fileURL('es-modules/wasm-source-phase.js'))};`,
Copy link
Contributor

Choose a reason for hiding this comment

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

Drive-by; shouldn't this say import source * as wasmExports?

Comment on lines +145 to +147
'import { strictEqual } from "node:assert";',
`import source mod from ${JSON.stringify(fixtures.fileURL('es-modules/unimportable.wasm'))};`,
'assert.strictEqual(mod instanceof WebAssembly.Module, true);',
Copy link
Contributor

Choose a reason for hiding this comment

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

Also a question here - how does this test ensures that the import is not executed?

@sbc100
Copy link

sbc100 commented Feb 19, 2025

I'm working on corresponding patch to emscripten to enable source phase imports: emscripten-core/emscripten#23175

As such, I would love to see this patch landed so we can start testing it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dont-land-on-v18.x PRs that should not land on the v18.x-staging branch and should not be released in v18.x. dont-land-on-v20.x PRs that should not land on the v20.x-staging branch and should not be released in v20.x. dont-land-on-v22.x PRs that should not land on the v22.x-staging branch and should not be released in v22.x. dont-land-on-v23.x PRs that should not land on the v23.x-staging branch and should not be released in v23.x. esm Issues and PRs related to the ECMAScript Modules implementation. lib / src Issues and PRs related to general changes in the lib or src directory. needs-ci PRs that need a full CI run. semver-minor PRs that contain new features and should be released in the next minor version. wasm Issues and PRs related to WebAssembly.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

WebAssembly source phase imports Tracking issue: latest ESM Integration support
10 participants