JavaScript identifier resolution is normally static — you can tell from the source which binding a name refers to. Which two legacy constructs break that guarantee, how does each one do it, and what do engines and minifiers do in response?

## What "static resolution" buys Because JavaScript scoping is lexical, the binding every free identifier refers to can normally be determined from the source text alone. That property is worth real money: - **Engines** can resolve a variable access to a fixed slot in an environment record — or keep the value in a register entirely — instead of doing a name lookup along a chain at every access. - **Minifiers** can rename a function's locals to single letters, because they can prove which occurrences of a name refer to that binding. - **Humans and linters** can tell whether a name is a typo, an import, or a shadowed outer variable without running anything. Two constructs in the language take that certainty away. ## `with`: an object on the scope chain `with (obj) { ... }` creates an **object environment record** whose "bindings" are the properties of `obj`, and splices it into the scope chain in front of the enclosing environment for the duration of the block: ```js // non-strict script const x = 'from scope'; const obj = { x: 'from object' }; with (obj) { console.log(x); // "from object" } ``` What makes this unanalysable is that an object's property set is a runtime fact. Add or delete a property on `obj` — or on something in `obj`'s prototype chain, because inherited properties count too — and the same source line resolves to a different binding. There is no way to decide statically what `x` means inside that block. The language later added a narrow escape hatch: `Symbol.unscopables`. An object may carry a `[Symbol.unscopables]` object whose truthy-valued keys are hidden from `with` lookups. `Array.prototype[Symbol.unscopables]` uses this so that newer array methods do not shadow same-named variables inside `with (someArray)` in old code. That the committee needed such a mechanism at all is the clearest evidence of how disruptive `with` is. Strict code bans `with` as a **SyntaxError**, so it cannot appear in an ES module or a class body at all. ## Direct `eval`: new bindings in your scope A *direct* eval — a call written literally as `eval(...)` where `eval` resolves to the built-in — runs its argument in the caller's execution context. In non-strict code that means the evaluated source can both read the caller's locals and *declare into* the caller's variable environment: ```js // non-strict script function f() { var local = 'inner'; console.log(eval('local')); // "inner" — sees f's scope eval('var added = 1;'); console.log(added); // 1 — eval declared into f } f(); ``` So a static analyser reading `f` cannot even enumerate `f`'s variables, let alone rename them. Any function containing a direct eval is treated as opaque. Strict code softens this: a direct eval in strict code still *reads* and *writes* existing outer bindings, but its own declarations go into a fresh environment that disappears when the eval returns, so it cannot inject new names into the caller. ## Indirect eval is a different function Calling eval through any expression that is not the literal `eval` reference — `(0, eval)(src)`, `const e = eval; e(src)`, `globalThis.eval(src)` — is an **indirect** eval, and it is specified to evaluate the source as *global* code: ```js var top = 'global'; function f() { var local = 'inner'; console.log(eval('local')); // "inner" — direct const g = eval; try { g('local'); } catch (e) { console.log(e.constructor.name); // "ReferenceError" — indirect, no access to local } console.log(g('top')); // "global" } f(); ``` Because indirect eval never touches local scope, it does not deoptimize the surrounding function the way direct eval does. If you truly must evaluate source at runtime, the indirect form (or a `Function` constructor, which likewise only closes over global scope) is the version that leaves your scopes intact. ## The cost, concretely For a function containing `with` or a direct eval, an engine cannot pre-bind variable accesses; it keeps a real, inspectable environment and performs dynamic name lookup, and it typically declines the optimisations that assume a known variable set. Minifiers detect the same constructs and bail out of renaming for that scope — some tools warn about exactly this, because one stray `eval` can noticeably inflate a bundle by preventing name mangling in a large function. There is a second, separate cost worth naming in an interview: evaluating source built from input is a code-injection vector. But the scope argument stands on its own even for source you fully control. ## What to say The strong answer names both constructs, explains the *mechanism* for each (object environment record spliced into the chain; declarations injected into the caller's variable environment), states what strict code does to each, distinguishes direct from indirect eval, and closes with the consequence: the language's static-resolution guarantee is what engines and tools monetise, and these two constructs are the only places it is surrendered.