Scope, the scope chain and execution contexts

Scope is the part of a program in which a name can be used. JavaScript decides it lexically: from where the code is written, not from where or how a function is called. Blocks, function bodies, modules and the global level each hold their own names, and they nest like boxes inside boxes. To find a name, the engine looks in the innermost scope first and then in each enclosing one, out to the global level; that path is the scope chain, and a name found nowhere is a ReferenceError. While the program runs, the engine also keeps track of what is running with execution contexts: each function call gets one, holding that call’s variables, and the contexts of the calls that have not finished yet form the call stack. The two chains are easy to confuse. This lesson shows both in programs that run, and the accidental globals and shadowing bugs they explain.

Four kinds of scope

• Block scope. A pair of braces, { … }, as in an if, a loop or a bare block, holds the let, const and class declarations written in it. In strict code, which includes every module, a function declared in a block belongs to that block too.
• Function scope. Each call of a function has its parameters, its var declarations and everything declared at the top of its body.
• Module scope. The top level of an ES module holds its imports and top-level declarations. Other modules see only what it exports.
• Global scope. Outside every function and module sit the built-ins (console, Math, globalThis) and, in classic scripts, the scripts’ top-level declarations.

var is the exception to block scope: it ignores blocks and belongs to the whole function, or to the global object at the top of a classic script. Modern code uses let and const; the next lesson of this module looks at var and the rules for using a name before its declaration.

The scope chain: looking a name up

Here one name, level, is declared four times at four levels. Each line prints the declaration that a use of the name found:

// One name, four scopes. Each line says which declaration the name level resolved to.
const level = 'module';

function outer() {
  const level = 'function outer';

  if (level !== '') {
    const level = 'block inside outer';
    console.log(`in the block: ${level}`);
  }

  function inner() {
    console.log(`in inner: ${level}`); // inner has no level of its own: the next scope out is outer's
  }
  inner();

  console.log(`in outer: ${level}`);
}

outer();
console.log(`at the top of the module: ${level}`);

// A name that no scope declares is a ReferenceError, not undefined.
try {
  // eslint-disable-next-line no-undef -- the misspelt name is the point
  console.log(levl);
} catch (error) {
  console.log(`${error.name}: ${error.message}`);
}

in the block: block inside outer
in inner: function outer
in outer: function outer
at the top of the module: module
ReferenceError: levl is not defined

in the block: block inside outer
in inner: function outer
in outer: function outer
at the top of the module: module
ReferenceError: 'levl' is not defined

• Inside the if block, the nearest declaration is the block’s own, so that one wins. The condition level !== '' sits outside the braces, so it still reads outer’s level.
• inner declares no level, so the lookup moves out one scope, to outer’s function scope, and stops at the first match. It never reaches the module’s level.
• After the block has ended, its level is gone, and outer sees its own again.
• At the top of the module, only the module’s declaration is in reach. Inner scopes can see out; outer scopes cannot see in.

The last lines show what happens when the chain runs out: the misspelt levl is declared nowhere, and reading it throws a ReferenceError. That is a feature. A typo that silently gave undefined would surface much later, far from the line with the mistake.

Scope is lexical, not decided by the caller

Where a function is called makes no difference to the names it sees. What counts is where its code sits:

// Scope comes from where a function is written, not from where it is called.
const rate = 18;

function withTax(pricePaise) {
  return Math.round(pricePaise * (1 + rate / 100)); // this rate is the module's, always
}

function quoteForExport(pricePaise) {
  const rate = 0; // a different rate, local to this function
  return `export quote: ${withTax(pricePaise)} (local rate ${rate})`;
}

console.log(withTax(10000));
console.log(quoteForExport(10000));

// A function created inside another sees that function's variables, even when it is called elsewhere.
function makeGreeter(greeting) {
  return function greet(name) {
    return `${greeting}, ${name}`;
  };
}
const greetHindi = makeGreeter('Namaste');
const greeting = 'Hello'; // does not affect greetHindi
console.log(greetHindi('Asha'), '|', greeting);

11800
export quote: 11800 (local rate 0)
Namaste, Asha | Hello

withTax() is written at the top of the module, so rate inside it means the module’s rate, 18, even when quoteForExport() calls it from inside a function that has a rate of its own. If JavaScript looked names up through the callers instead (dynamic scope, which some other languages use), the export quote would have used 0.

The second half shows the same rule from the other side: greet() is written inside makeGreeter(), so it keeps seeing that call’s greeting, 'Namaste', after makeGreeter() has returned and even though the module later declares its own greeting. A function together with the names it can reach this way is a closure, the subject of a later lesson of this module.

Execution contexts and the call stack

The specification describes running code with execution contexts. One is created for the module or script when it starts and one for every function call; each tracks the code being run and the names it can use. The contexts sit on the execution context stack: a call pushes a new context, which becomes the running execution context, and a return pops it, so the caller’s context is running again. Debuggers and stack traces show the same stack, as frames. This program prints the stack, as V8 reports it, at four moments:

// The call stack while nested calls run: each line lists the running function first, then its callers.
// The names come from V8's stack trace (error.stack is not standard, so its format differs between engines).

function stack() {
  return new Error().stack
    .split('\n')
    .slice(2) // drop the "Error" line and the frame of stack() itself
    .map((line) => line.trim().match(/^at (\S+) \(/)?.[1] ?? 'module code')
    .filter((name, i, all) => all.indexOf('module code') === -1 || i <= all.indexOf('module code'))
    .join(' <- ');
}

function applyCoupon(totalPaise) {
  console.log(`3. ${stack()}`);
  return totalPaise - 5000;
}

function priceCart(items) {
  console.log(`2. ${stack()}`);
  const total = items.reduce((sum, item) => sum + item, 0);
  return applyCoupon(total);
}

function checkout(items) {
  console.log(`1. ${stack()}`);
  const due = priceCart(items);
  console.log(`4. back in checkout: ${stack()}`);
  return due;
}

console.log(`due: ${checkout([40000, 25000])}`);

1. checkout <- module code
2. priceCart <- checkout <- module code
3. applyCoupon <- priceCart <- checkout <- module code
4. back in checkout: checkout <- module code
due: 60000

At step 3 the stack holds four contexts: applyCoupon is running, priceCart and checkout are waiting for the calls they made, and the module’s code is waiting at the bottom. By step 4, priceCart and applyCoupon have returned and their contexts are gone, with their local variables. The reduce() callback ran in between and left no trace either: a context exists only while its call runs. The example has no Run button because it reads V8’s error.stack, which is not standard; QuickJS reports the same calls in its own format.

The call stack and the scope chain are different chains, and this is the point that makes scope click. At step 3, the call stack runs through priceCart and checkout, but applyCoupon cannot see either function’s variables, because it was not written inside them:

Environment records, at a high level

In the specification, every scope is an environment record: a table of the names (the bindings) that one block, function call, module or the global level declares. Each record has an outer reference to the record around it, and those references are the scope chain. Looking a name up means checking the running context’s record, then its outer record, and so on, until the global record; a miss there is the ReferenceError.

Two details explain the examples above:

• A function object remembers the environment record it was created in. Each call creates a new function environment record for its parameters and variables, and that record’s outer reference is the remembered one, not the caller’s. That is lexical scope, written as a rule.
• A new record is created each time its code runs: each call of a function, and each pass through a block, gets its own set of bindings. Two calls of the same function never share their local variables.

The specification notes that environment records are a way to describe the language and need not exist inside an engine as such; engines may store variables however they like, as long as programs behave as described.

Scripts and modules at the top level

A browser runs each <script> tag without type="module" as a classic script, and all classic scripts of a page share one global scope. The global environment has two halves: the global object (window in a browser, globalThis everywhere), which holds the built-ins and the top-level var and function declarations of scripts, and a separate table for the scripts’ top-level let, const and class. Node.js’s vm module runs code as classic scripts, which shows the rules without a browser:

// Classic scripts share one global scope. node:vm runs each string below as a classic script, the way a browser runs
// each <script> tag without type="module".
import { runInThisContext } from 'node:vm';

runInThisContext('var cart = 3; let user = "asha"; function total() { return cart * 2; }');
console.log(`globalThis has cart: ${'cart' in globalThis}, user: ${'user' in globalThis}, total: ${'total' in globalThis}`);

// A second script sees the first script's let, even though it is not a property of globalThis.
console.log(`second script reads: ${runInThisContext('`${user} ${total()}`')}`);

// A third script that declares the same name again fails before any of its code runs.
try {
  runInThisContext('console.log("third script starts"); let user = "ravi";');
} catch (error) {
  console.log(`${error.name}: ${error.message}`);
}

// The module's own top-level names are invisible to scripts.
const moduleOnly = 'module';
console.log(`the module sees ${moduleOnly}; a script sees moduleOnly as: ${runInThisContext('typeof moduleOnly')}`);

globalThis has cart: true, user: false, total: true
second script reads: asha 6
SyntaxError: Identifier 'user' has already been declared
the module sees module; a script sees moduleOnly as: undefined

• The first script’s var cart and function total became properties of globalThis; its let user did not.
• A second script still sees user and calls total(): top-level declarations of classic scripts are shared by every script that runs later.
• A third script that declares user again fails before any of its code runs, so its first line never prints: before running a script, the engine checks all of its top-level declarations against the names that already exist. Two third-party snippets on one page that both use let config collide this way.
• The module’s own moduleOnly is invisible to scripts. Each module has its own module scope, so modules never collide like that, and at the top of a module this is undefined.

The example has no Run button because QuickJS has no node:vm.

Accidental globals

In sloppy mode, the old default of classic scripts, assigning to a name that no scope declares does not fail: it creates a property on the global object. Strict mode turns that into a ReferenceError:

// Assigning to a name that no scope declares. Indirect eval runs its code the way a classic script runs: at the
// global level and, without "use strict", in sloppy mode.
// eslint-disable-next-line no-eval -- indirect eval runs each string as a classic script would run
const runAsScript = eval;

runAsScript('function addVisit() { visits = 1; } addVisit();');
console.log(`sloppy script: visits became a global property: ${'visits' in globalThis}, value ${globalThis.visits}`);

try {
  runAsScript('"use strict"; function addSale() { sales = 1; } addSale();');
} catch (error) {
  console.log(`strict script: ${error.name}: ${error.message}`);
}

// Module code is always strict, so the same mistake fails at once.
function addRefund() {
  // eslint-disable-next-line no-undef -- the undeclared name is the mistake this line shows
  refunds = 1;
}
try {
  addRefund();
} catch (error) {
  console.log(`module: ${error.name}: ${error.message}`);
}

sloppy script: visits became a global property: true, value 1
strict script: ReferenceError: sales is not defined
module: ReferenceError: refunds is not defined

sloppy script: visits became a global property: true, value 1
strict script: ReferenceError: 'sales' is not defined
module: ReferenceError: 'refunds' is not defined

Indirect eval, const runAsScript = eval; runAsScript(code), runs code at the global level and in sloppy mode unless the code asks for strict mode, much like a classic script (only its let and const stay inside the eval). In the first, sloppy, script, visits = 1 quietly created globalThis.visits: any other code could read or overwrite it, and a typo in a variable name becomes a new global instead of an error. The second script starts with "use strict", and the same assignment throws. Module code is always strict, so addRefund() fails at the first call. Modules, classes and "use strict" all prevent accidental globals; ESLint’s no-undef rule, part of its recommended set, reports them before the code runs.

Shadowing

A declaration in an inner scope with the same name as one outside shadows it: inside the inner scope, the name means the inner declaration. That is legal, and sometimes useful, but it hides bugs:

/* eslint-disable prefer-const, @typescript-eslint/no-unused-vars -- these rules report the shadowing bugs this file shows */
// Shadowing: an inner declaration with the same name hides the outer one for the rest of its scope.
function longestName(names) {
  let longest = '';
  for (const name of names) {
    if (name.length > longest.length) {
      let longest = name; // a new variable for this block only: the outer longest never changes
    }
  }
  return longest;
}

function longestNameFixed(names) {
  let longest = '';
  for (const name of names) {
    if (name.length > longest.length) {
      longest = name; // no let: this updates the outer variable
    }
  }
  return longest;
}

const names = ['Ravi', 'Meenakshi', 'Asha'];
console.log(JSON.stringify(longestName(names)), JSON.stringify(longestNameFixed(names)));

// An inner declaration shadows the outer name from the start of its block, even on lines above it.
const discountPercent = 10;
function finalPrice(pricePaise) {
  try {
    const half = discountPercent / 2; // reads the inner discountPercent, which is not initialised yet
    const discountPercent = half;
    return pricePaise - (pricePaise * discountPercent) / 100;
  } catch (error) {
    return error.name;
  }
}
console.log(finalPrice(10000));

"" "Meenakshi"
ReferenceError

longestName() returns "" for every list. The let longest = name; inside the if declares a new longest that lives only in that block, so the outer longest is never updated. Dropping the let, as in longestNameFixed(), assigns to the outer variable.

The second function reads discountPercent on a line above the inner declaration, and still gets the inner one: a declaration shadows the outer name from the start of its block, not from its own line. Until its line runs, the inner name is uninitialised, so the read throws a ReferenceError instead of falling back to the outer 10. Renaming the inner variable, here to something like halfDiscount, fixes both kinds of shadowing bug. ESLint’s no-shadow rule reports every shadowing declaration; it is not in the recommended set, so a project turns it on deliberately. Even without it, no-unused-vars notices that the inner longest is never read and prefer-const that the outer one never changes, which is why the example switches both rules off in its first line.

Interview questions

Fresher · What does lexical scope mean in JavaScript?

Lexical scope means that the names a piece of code can use are decided by where the code is written in the source, not by where or how it is called. Blocks, functions, modules and the global level nest, and a name is looked up from the innermost scope outwards along that nesting; this path is the scope chain, and a name declared nowhere throws a ReferenceError. So a function written at the top of a module sees the module’s variables even when another function, with variables of the same names, calls it. A function created inside another function keeps seeing that outer call’s variables after it returns, which is what a closure is. The call stack is a separate chain: it records who called whom, and it plays no part in finding names.

Key takeaways

• Scope is where a name can be used. let, const and class are block-scoped; parameters and var belong to the function; a module has its own top-level scope; the global scope holds the built-ins.
• A name is looked up from the innermost scope outwards, and the first match wins. A name found nowhere is a ReferenceError.
• Scope is lexical: a function sees the names around the place where it was written, never its caller’s.
• Each call creates an execution context; the stack of unfinished contexts is the call stack. It records who called whom, which is a different chain from the scope chain.
• Classic scripts share one global scope: var and functions become globalThis properties, and a second top-level let of the same name is a SyntaxError. Modules keep their names to themselves.
• Strict code, which includes every module, turns an assignment to an undeclared name into a ReferenceError. Shadowed names hide updates and apply from the start of their block; rename them, and let no-undef and no-shadow find the rest.