In a non-strict JavaScript script, what happens when a function assigns to a name that is not declared anywhere in the scope chain — for example `function init() { cache = {}; }` — and why is it a bug worth catching?

## Reading and writing are not symmetric Identifier resolution walks the scope chain outward from the current environment record until some record has the name. If nothing does, the reference is unresolvable — and what happens next depends on the operation: - **Read** an unresolvable reference: always throws `ReferenceError`. - **Write** to an unresolvable reference: in non-strict script code, the engine creates a property on the global object and assigns to that. No error, no warning. That second rule is a compatibility relic from the earliest days of the language, and it is the whole source of accidental globals. ```js // non-strict script function init() { cache = {}; // no let/const/var anywhere } init(); console.log(typeof cache); // "object" console.log(globalThis.cache); // {} — same thing ``` ## Why it looks like a local until it isn't Inside `init`, `cache` reads exactly like a local variable: it is assigned at the top of the function and used below. Nothing in the function body distinguishes it from a declared one. The difference only appears after the call returns — the binding is still there, on the global object, holding whatever the function put in it. The most common way to create one by accident is a missing declaration keyword in a loop header or a typo in an assignment target: ```js for (i = 0; i < 10; i++) { /* i is now global */ } let result = compute(); resutl = result * 2; // typo: creates a global instead of failing ``` The typo case is the painful one. With a declared variable, misspelling the *read* side throws immediately. Misspelling the *write* side in non-strict code creates a brand-new global and leaves the intended variable untouched, so the bug surfaces later and somewhere else. ## What the damage actually is **Cross-file collisions.** Every classic script on a page shares one global object. Two libraries that both forget to declare `config` are writing to the same slot, and the last one to run wins. Debugging that means noticing that a value changes without any code you can see assigning it. **Leaked lifetime.** A global property is reachable from the global object, so it — and everything it references — is never collected while the realm lives. An implicit global holding a large cache, a DOM node, or a request object turns a per-call allocation into a permanent one. **State bleeding between runs.** In test suites and in server processes, an implicit global is shared across tests or requests. Tests pass individually and fail in sequence; a value from one request appears in the next. **Loss of scope guarantees.** The point of a local is that you can reason about it from one function's source. An implicit global takes that away for the whole realm at once. ## The one observable difference from a real global A property created by an unresolvable assignment is a **configurable** property of the global object, so it can be deleted: ```js function init() { cache = {}; } init(); delete globalThis.cache; // true — implicit globals are deletable ``` A top-level `var` in a script also becomes a global-object property, but a non-configurable one, so `delete` on it returns `false` and the binding stays. That difference is a genuinely reliable way to tell an accidental global from a declared one when you are poking at a live page, and it is a nice detail to have ready if the interviewer pushes. ## Catching them Three defences, in increasing order of strength: 1. **Lint.** A rule that forbids assigning to an undeclared identifier catches this at edit time, before it ever runs. 2. **Strict code.** In strict code the unresolvable assignment throws a `ReferenceError` instead of creating anything, turning a silent leak into a stack trace at the exact line. 3. **Modules.** ES module code is always strict and has its own module scope, so the mistake fails loudly and top-level declarations never land on the global object in the first place. The reason this question still gets asked, despite modules being the default for new code, is that the failure mode is instructive: it is the clearest example in the language of a *write* silently changing the shape of the environment rather than failing, and candidates who can explain the read/write asymmetry usually understand scope resolution properly rather than by analogy. ## Auditing an existing page If you inherit a non-module codebase and suspect leaks, snapshot the global object's own keys early (`Object.keys(globalThis)`) and diff after exercising the app; new keys that no file declares are your candidates. Combine that with the `delete` test above to separate accidental globals from intentional ones.