What does top-level `this` evaluate to in a classic browser script, in an ES module, and in a Node CommonJS module, and why is `this` an unreliable way to reach the global object?

## Why there is more than one answer `this` at the top level of a file is not a single rule; it is decided by the *kind* of code being evaluated. JavaScript has several source types and each one specifies its own top-level `this` value. ## Classic script A file loaded with a plain `<script src="...">` (no `type="module"`) is evaluated as a **script**. Script evaluation runs in the global execution context, whose `this` value is the global object. ```js // classic script console.log(this === globalThis); // true this.appName = 'demo'; console.log(globalThis.appName); // 'demo' ``` This is why the old `var root = this;` idiom worked at all — it was written in an era when nearly all browser code was classic scripts. ## ES module A file loaded with `<script type="module">`, an `.mjs` file, or any file in a package whose `type` is `"module"`, is evaluated as a **module**. The specification sets a module's this-value to `undefined`, so: ```js // ES module console.log(this); // undefined this.appName = 'demo'; // TypeError: Cannot set properties of undefined ``` That is deliberate. Modules are meant to be self-contained: nothing about them should encourage writing to the global object by accident. If you genuinely want a global, you have to say so: `globalThis.appName = 'demo'`. This is also the single most common way the old idiom breaks. A file that worked for years as a script is switched to a module during a build migration, `var root = this;` quietly becomes `undefined`, and the failure surfaces much later as `Cannot read properties of undefined` somewhere unrelated. ## Node CommonJS module A `.cjs` file, or a `.js` file in a package without `"type": "module"`, is loaded by Node's CommonJS loader. That loader wraps the file body in a function and invokes it with `module.exports` as the receiver. So: ```js // index.cjs console.log(this === module.exports); // true console.log(this); // {} (empty until you add exports) this.hello = () => 'hi'; // a real, if unusual, way to export ``` Note the trap in the last line: `this.hello = ...` mutates the exports object, but `module.exports = something` **replaces** it, after which top-level `this` no longer refers to what the module exports. ## What about `this` inside functions? Top-level `this` is a separate question from `this` inside a function, which is decided at call time by how the function is called. The two interact in one place worth knowing: an ordinary function invoked with no receiver gets `undefined` as `this` in strict-mode code and the global object in non-strict code. ES modules are always strict, so inside a module a bare call never gives you the global object either. That is the second reason the `Function('return this')()` trick had to build its function from a string — a function created that way is not strict. An arrow function at the top level inherits the surrounding `this`, so an arrow declared at module top level closes over `undefined`, not over the global object. ## The takeaway Do not use `this` to mean "the global object". It means that in exactly one of the three source types, and the same file can move between source types without any change to its contents. If you want the global object, write `globalThis` — one name, one meaning, every host. If you want the module's exports in CommonJS, write `module.exports` explicitly rather than relying on the wrapper's receiver. ## How to test yourself in a review When you see top-level `this` in a diff, ask which source type the file is: does it have `import`/`export` statements, what is the `type` field of the nearest `package.json`, is it loaded with `type="module"`? If the answer is not obvious from the file alone, that alone is a reason to replace `this` with an explicit name.