ESM syntax detection ignores certain top-level awaits

Version

v23.11.0

Platform

Darwin Gereons-MacBook-Air.local 24.4.0 Darwin Kernel Version 24.4.0: Fri Apr 11 18:33:46 PDT 2025; root:xnu-11417.101.15~117/RELEASE_ARM64_T8112 arm64

Subsystem

No response

What steps will reproduce the bug?

Run the following snippet like this: node test.js

// test.js (".js" extension is important)
console.log(await 0);

How often does it reproduce? Is there a required condition?

node needs to treat the code as “ambiguous” input. Quote from #50096:

For the following “ambiguous” inputs:

Files with a .js extension or no extension; and either no controlling package.json or one that lacks a type field; and --experimental-default-type is not specified

String input (--eval or STDIN) when neither --input-type nor --experimental-default-type are specified

(REPL works as expected though so idk if this is 100% accurate)

What is the expected behavior? Why is that the expected behavior?

any top-level usage of the await keyword should cause the code to be treated as a module, e.g. this works:

await console.log(0);

after the code has been identified as an ESM the first provided snippet also works:

await /* <- this allows the line to work */ console.log(await 0);

What do you see instead?

/Users/me/code/test.js:1
console.log(await 0);
            ^^^^^

SyntaxError: missing ) after argument list
    at wrapSafe (node:internal/modules/cjs/loader:1666:18)
    at Module._compile (node:internal/modules/cjs/loader:1708:20)
    at Object..js (node:internal/modules/cjs/loader:1899:10)
    at Module.load (node:internal/modules/cjs/loader:1469:32)
    at Function._load (node:internal/modules/cjs/loader:1286:12)
    at TracingChannel.traceSync (node:diagnostics_channel:322:14)
    at wrapModuleLoad (node:internal/modules/cjs/loader:235:24)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:151:5)
    at node:internal/main/run_main_module:33:47

Node.js v23.11.0

Additional information

No response

a workaround for this...

export {}

console.log(await 0);

another workaround which proves the parser is, in principle, capable of switching to MJS mid-statement:

const zero = await 0;
console.log(zero);

other ways to trigger related errors because await is being treated as an identifier (which appears to be the cause of the problem):

const zero = (await 0);
const [zero] = [await 0];
const { zero } = { zero: await 0 };

any updates on this issue?

a workaround for this...

export {}

console.log(await 0);

A better workaround: use .mjs extension ;)

if anyone who knows the code-base would point me to the relevant file or functions I'd love to contribute…

@GeoffreyBooth

/cc @GeoffreyBooth

module: correctly detect top-level await in ambiguous contexts

Navigation Menu

Repository navigation

ESM syntax detection ignores certain top-level `await`s #58331

Version

Platform

Subsystem

What steps will reproduce the bug?

How often does it reproduce? Is there a required condition?

What is the expected behavior? Why is that the expected behavior?

What do you see instead?

Additional information

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

ESM syntax detection ignores certain top-level awaits #58331

Description

Version

Platform

Subsystem

What steps will reproduce the bug?

How often does it reproduce? Is there a required condition?

What is the expected behavior? Why is that the expected behavior?

What do you see instead?

Additional information

Activity

alexsch01 commented on May 14, 2025

GereonV commented on May 15, 2025

qidirbaev commented on May 16, 2025

aduh95 commented on May 16, 2025

GereonV commented on May 17, 2025

aduh95 commented on May 17, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

ESM syntax detection ignores certain top-level `await`s #58331