Scope and Closures

var silently allows the same name twice in one scope; let and const make it a SyntaxError. Shadowing the same name in a nested block is always legal for let and const, but a var inside the block collides with an outer let because var is hoisted past the braces.

The assignment walks the scope chain, finds no binding, and in non-strict script code creates a property on the global object instead of throwing. That accidental global outlives the call and is shared by every other script on the page or process.

The assignment fails in both dialects. Sloppy mode discards the failure and continues; strict mode reports it as a TypeError. Strict mode changes the reporting of a failed write, never whether the write succeeds.

An arrow has no this binding to overwrite — it reads this from the enclosing scope. So call, apply, bind and the thisArg of methods like map still pass a value, but the arrow never consults it. Arguments are still forwarded normally.

Arrow functions have no own arguments, no super, no new.target, and no prototype property, and they are not constructors: new on an arrow throws a TypeError. They also cannot be generators. All four missing bindings resolve lexically instead.

Array methods are specified as generic: they read only a length property and integer-keyed properties from whatever this they are given. call supplies the array-like arguments object as that this. Modern code uses a rest parameter, Array.from, or spread instead.

Any arguments after bind's first are stored and prepended to every later call, giving partial application. The trap is that the first parameter is always the this value, never an argument — so presetting only arguments requires passing a placeholder receiver such as null.

Strict mode decides it. In strict code a plain call leaves this as undefined, so the first property access throws immediately; in sloppy code the engine substitutes globalThis, so the method silently reads and writes global properties instead of failing.

Only the immediate base of the property access becomes this, so it is a.b.c — not a. Implicit binding uses the object the method was read from, and everything further left in the chain is irrelevant.

The closure captured the parameter binding, which holds a reference to the caller's object, so property mutations are visible immediately to every logger. To stop it, read the values you need into local bindings at creation time, or copy or freeze the object before capturing it.

All the promise callbacks share the single var binding for i, and they run only after the loop has finished, when i equals ids.length. So every write lands on that one out-of-range index. Declare the counter with let, or build the array from returned values instead of index writes.

Both inner functions share one environment record for the enclosing scope, and that record holds every binding any inner function captures. The stored function therefore keeps the huge array reachable even though it never reads it.

Inside the wrapper, b calls the local binding a, not the property mod.a. The returned object holds a copy of the function value at return time, so replacing the property rewires only outside callers; every internal call keeps going to the original.

In strict-mode code, including ES modules, a function declared inside a block is scoped to that block and is not visible after it. In sloppy-mode scripts, legacy web semantics also create a function-scoped variable that is only filled in when the block actually runs.

That message means the binding exists in scope but is still uninitialized: something declared with let, const, or class was accessed before its declaration ran. Find what executes during the scope's setup and reaches the name early, rather than looking for a missing declaration.

Top-level var in a classic script creates a non-configurable property on the global object, so separate scripts can collide with each other and with built-in globals. let and const instead create bindings in a separate global scope that is not reachable as a property. In an ES module neither touches globalThis.

Expect two classes: parse-time syntax errors that kill the entire script before a line runs, and runtime errors on code paths that previously failed quietly. Roll out per function rather than per file, and lint for undeclared globals first.

The arrow field is an own, enumerable property created fresh on every instance, with this locked to that instance. The method lives once on the prototype, is non-enumerable, and takes this from the receiver at call time.

Return a regular function that invokes the target with fn.apply(this, args). The wrapper picks up the receiver from its own call site and forwards it. An arrow wrapper cannot do this, and calling fn(...args) drops the receiver entirely.

Confirm it by checking the registration sites for a bare method reference and by reproducing the detachment directly, or by asserting the receiver inside the method. Then remove the hazard at the boundary: export closures or pre-bound handlers instead of raw methods, rather than asking every caller to remember.

With no new and no receiver, default binding applies: this is globalThis in sloppy mode, so the assignment creates a global property and the call returns undefined. Nothing throws, so the failure surfaces far from its cause.

It prints "function" and then "number". When the scope is entered, the function declaration wins and puts the function in the shared binding; the var declaration does not overwrite it. Later the assignment foo = 1 runs and replaces the value.

The bound this is ignored. Construction creates a fresh object and uses that as the receiver, so new is the one call form a hard binding cannot override. Bound arguments are still prepended, and instanceof against the target function still works.

The with statement and non-strict direct eval break it. with pushes an object onto the scope chain so lookups depend on that object's properties at runtime, and direct eval can add bindings to the calling scope. Both defeat static analysis, so engines deoptimize and minifiers stop renaming.

Settle four things: whether the cache is bounded in size or age, what each entry transitively retains, whether object arguments should be held weakly so callers can be collected, and how long the memoized function itself lives.

Delete it wherever a module file or a block already provides the scope: wrapping a whole module body buys nothing. Keep it for code that cannot be a module — injected snippets, embeds, build-free pages — and for an async wrapper where await is otherwise illegal.