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

[GereonV]

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

[alexsch01]

a workaround for this...

export {}

console.log(await 0);

[GereonV]

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 };

[qidirbaev]

any updates on this issue?

[aduh95]

a workaround for this...

export {}

console.log(await 0);

A better workaround: use .mjs extension ;)

[GereonV]

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

[aduh95]

/cc @GeoffreyBooth