In an ES module you write `var config = {}` and `function init() {}` at the top level. Are `globalThis.config` and `globalThis.init` defined afterwards, and how does that differ from the same two lines in a classic (non-module) script?

## The answer up front Nothing is created on the global object. `globalThis.config` and `globalThis.init` are both `undefined`. Run the same two lines in a classic script and both become global-object properties, so any other script could read the bare names. ## Two different "top levels" ECMAScript parses source text with one of two goals: **Script** or **Module**. That choice is made by whatever loads the file, and it changes what "top level" means. In **script** code, the top-level environment *is* the global environment. `var` and function declarations there create properties on the global object; `let`, `const` and `class` go into a separate global declarative record — they are not properties of `globalThis`, but they still live in the one global scope every script on the page shares. In **module** code, evaluation creates a fresh *module environment record* for the module body. Its outer environment is the global environment, so lookups still fall through to globals, but every declaration you write — `var`, `let`, `const`, `function`, `class`, and imported names — is created in the module's own record. ```js // classic script var config = {}; // globalThis.config === config function init() {} // globalThis.init === init ``` ```js // ES module var config = {}; // globalThis.config === undefined function init() {} // globalThis.init === undefined export { config, init }; ``` Note that `var` gets no special treatment in a module. The "var attaches to the global object" rule was never about `var` itself; it was about top-level script code being global code. ## Reading versus publishing Isolation is one-directional. A module resolves any name it does not declare by walking outward to the global environment, so `globalThis`, `console`, `JSON`, `setTimeout` and anything a previous script parked on the global object are all readable. What changed is *publishing*: a module contributes nothing to the global namespace unless you assign to `globalThis` (or to a property of it) on purpose. ```js // deliberate, visible handoff — the only way out of module scope globalThis.__APP_VERSION__ = '2.4.1'; ``` That explicitness is the point of the design. In the script era, whether a file exported something was invisible: you had to read the whole file and hope nobody later reassigned the same global. In modules, the surface is declared in the source. ## Why interviewers ask it Because it is the single behaviour that breaks pasted-in legacy code. Three symptoms come up constantly: - **"It works in the DevTools console but not in my file."** The console evaluates what you type as script code, so `var x = 1` there really does create `globalThis.x`. Your module does not. - **"Another file can't see my function."** In the script era, file B just used a name file A declared. In modules there is no shared namespace: file A must `export` it and file B must `import` it. - **Name shadowing surprises.** In a browser, `window.name` already exists as a string. A top-level `const name = 'checkout'` in a module creates a module binding that shadows it locally and leaves the global untouched — clean. The script-era equivalent stomped on a real platform property. ## Scope, instance, and lifetime Each module gets exactly one environment per module record: the body runs once, and the bindings it creates live as long as the module is reachable. So a top-level `let cache = new Map()` in a module behaves like a per-module singleton shared by every importer of that module — not a global, but not per-call either. That is worth saying out loud, because it is the useful half of the isolation: private state that survives across calls without touching the global object. ## How to demonstrate it The crisp check is `typeof globalThis.config`. If the file is running as a module it prints `"undefined"`; if it is running as a script it prints `"object"`. That one line is also the fastest way to settle an argument about whether a given file is actually being evaluated as a module. `globalThis` itself is the ES2020 spelling of "the global object"; older code says `window` in a browser. The module-scope rule described here is unchanged since modules were introduced in ES2015.