Why is `await` outside any function a SyntaxError in a CommonJS file or a classic `<script>`, but legal in an ES module?

## Two parse goals, two answers The same characters in a `.js` file mean different things depending on how the file is parsed. JavaScript has two top-level parse goals: Script and Module. A `<script>` tag without `type="module"` is parsed as a Script. A file loaded as an ES module is parsed as a Module. This single decision changes several things at once: module source is strict-mode by default, `import` and `export` are only grammatical in the Module goal, and, since ES2022, `await` is permitted at the top level of the Module goal only. In the Script goal, `await` is not a reserved word at the top level. It is contextually a keyword inside an `async` function and otherwise just an identifier. That is why old code could legally write `var await = 1;` in a script. Because the token is not an operator there, `await somePromise;` at the top of a classic script is a SyntaxError, and adding a newer engine does not change it — the grammar itself differs by goal. ```javascript // classic script: SyntaxError await Promise.resolve(1); // ES module: fine, and the module's evaluation suspends here await Promise.resolve(1); ``` ## Why CommonJS cannot simply add it CommonJS files are parsed with the Script grammar (wrapped in a function that supplies `require`, `module`, and `exports`), so the grammatical answer already applies. But the deeper reason is the loading model. `require('./config')` is an ordinary synchronous function call. It locates the file, runs its body to completion, and returns `module.exports` as the call's return value. The caller is sitting in the middle of an expression, on the stack, waiting for a value. For a CommonJS module to await something, that `require` call would have to suspend the caller and resume it later — which would mean turning every `require` in the program into an asynchronous operation, and turning every function that contains one into something that can suspend. That is a different language, not an added feature. Nothing in the synchronous call-and-return shape of `require` leaves room for it. ES modules are different because the host, not user code, drives loading. Fetching, parsing, linking, and evaluating a module graph are separate phases the host performs, and evaluation was already specified so that the host learns when it is done. Making that completion asynchronous fit the existing shape: nothing in user code has to sit on the stack waiting for it. Instead, the module system holds back the importers' evaluation. ## What people write instead In a CommonJS file, the common substitutes are: ```javascript // async IIFE — the file finishes loading immediately (async () => { const data = await loadData(); // ... })(); ``` and `import('./esm-module.js')`, which returns a promise for the module namespace and works from CommonJS. Both let you await *something*, but neither reproduces the real behaviour: with an IIFE the module's own load completes right away, so anything that required it proceeds immediately and may read exports that have not been assigned. The distinguishing feature of true top-level await is that the module system delays the importers, and no user-land pattern in a synchronous loader can do that. ## Practical consequences A few follow from this cleanly. A module that uses top-level await cannot be consumed by a synchronous loader at all — there is no correct value to return from a synchronous call for a module that has not finished evaluating, so runtimes that let synchronous code pull in an ES module refuse when the graph contains top-level await. Build outputs matter for the same reason: a bundle emitted in a non-ESM format has no way to express a module that suspends partway through, so the feature constrains which output formats a library can ship. And a file that uses it is unambiguously an ES module — if a tool or runtime is treating your file as a script, the very first symptom is often a SyntaxError on the `await` line, which is a useful diagnostic rather than a nuisance.