JavaScript Hoisting — Async Loop Bug Leaked User Data

A single var in a for loop with async callbacks caused user data to leak across sessions in production Node.js services. The root cause is JavaScript hoisting — a compile-time behavior that moves variable declarations to the top of their scope. Understanding how var, let, and const hoist differently is the difference between a secure pagination endpoint and a PII leak. This bug has shipped at Airbnb, Uber, and fintech apps, corrupting financial transactions and exposing sensitive records.

Why Hoisting Breaks Async Loops — And Leaks Data

Scope hoisting in JavaScript is the engine's compile-time behavior of moving variable and function declarations to the top of their enclosing scope before execution. The key mechanic: var declarations are hoisted and initialized with undefined; let and const are hoisted but remain in a temporal dead zone (TDZ) until the actual declaration line. This means a var inside a block is accessible outside it — a property that directly causes the classic async loop bug.

In practice, hoisting interacts with closures and asynchronous callbacks in dangerous ways. When you write for (var i = 0; i < 5; i++) { setTimeout(() => console.log(i), 0); }, the var i is hoisted to the function scope, not block scope. By the time the callbacks execute, i is already 5. The same bug leaks user data when the loop variable is used to index into an array of sensitive records — every callback sees the last value, not the intended one.

Use let for block-scoped variables to avoid this entirely. In production systems, always prefer let or const in loops that schedule async work. If you must use var, capture the current value with an IIFE or .bind(). This isn't academic — it's a top-10 source of data leakage in Node.js services handling paginated queries.

var vs let vs const — The Scope Difference

JavaScript offers three ways to declare variables, and each behaves differently regarding scope. var is function-scoped — it leaks out of blocks like if and for. let and const are block-scoped, meaning they respect any pair of curly braces. const also prevents reassignment of the binding, but it does not make objects immutable — you can still modify properties.

// var: function-scoped — ignores block boundaries
function testVar() {
  if (true) {
    var x = 10;  // declared inside if block
  }
  console.log(x); // 10 — accessible outside the block!
}
testVar();

// let: block-scoped — respects {} boundaries
function testLet() {
  if (true) {
    let y = 10;
  }
  // console.log(y); // ReferenceError — y not accessible here
}

// const: block-scoped + cannot be reassigned
const MAX = 100;
// MAX = 200; // TypeError: Assignment to constant variable

// const with objects — the binding is const, not the object
const user = { name: 'Alice' };
user.name = 'Bob';  // fine — mutating the object, not the binding
console.log(user.name); // Bob

Hoisting — What Actually Happens

Before executing any code, JavaScript's engine scans for declarations and processes them. Function declarations are fully hoisted. var declarations are hoisted but set to undefined. let and const are hoisted but not accessible until the declaration line.

// Function declaration — fully hoisted, works before definition
console.log(greet('Forge'));  // 'Hello, Forge!' — works!

function greet(name) {
  return `Hello, ${name}!`;
}

// var — hoisted but undefined
console.log(city);  // undefined — hoisted, not initialised
var city = 'London';
console.log(city);  // 'London'

// let/const — temporal dead zone (TDZ)
// console.log(country);  // ReferenceError: Cannot access before initialization
let country = 'UK';
console.log(country);  // 'UK'

// Function expression — NOT hoisted (it is a variable assignment)
// console.log(sayHi());  // TypeError: sayHi is not a function
const sayHi = function() { return 'Hi!'; };
console.log(sayHi());  // 'Hi!'

The Temporal Dead Zone — Why let and const Are Not 'Safe' Hoisting

The temporal dead zone (TDZ) is the period between the start of a block scope and the point where a let or const variable is declared. During this period, the variable exists in memory (it has been hoisted) but is not initialized. Any attempt to read or write to it throws a ReferenceError.

The TDZ exists to catch a specific class of bugs: accessing a variable before it's initialized. With var, such access silently returns undefined, which can hide logical errors. The TDZ makes the error visible immediately.

This behaviour applies to class, import, and const as well. It's a deliberate design choice to make the language safer.

// TDZ example with let
{
  // TDZ starts here for `a`
  // console.log(a); // ReferenceError: Cannot access 'a' before initialization
  let a = 10; // TDZ ends here
  console.log(a); // 10
}

// TDZ is also scope-specific
function test() {
  if (true) {
    // TDZ for `x` starts
    // console.log(x); // ReferenceError
    let x = 5;
    console.log(x); // 5
  }
  // TDZ for `x` ended when the block closed, but `x` is no longer accessible
}

// typeof in TDZ also throws
{
  // console.log(typeof y); // ReferenceError in TDZ for let
  let y = 1;
}

// const has the same TDZ behaviour
{
  // const z = z + 1; // ReferenceError — z is in TDZ
  const z = 1;
}

Lexical Scope and Closures

JavaScript uses lexical scoping, meaning that the scope of a variable is determined by its position in the source code. Inner functions have access to variables of outer functions, but not vice versa.

Closures occur when an inner function retains access to its outer scope even after the outer function has finished executing. This is the foundation for many JavaScript patterns, including data privacy, event handlers, and callbacks.

Understanding closures is essential for debugging scope-related bugs, especially in asynchronous code.

const globalVar = 'global';

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

  function inner() {
    const innerVar = 'inner';
    // Can access all three — lexical scope chain
    console.log(innerVar);   // 'inner'
    console.log(outerVar);   // 'outer'
    console.log(globalVar);  // 'global'
  }

  inner();
  // console.log(innerVar); // ReferenceError — inner scope not accessible here
}

outer();

// Scope chain: inner → outer → global → undefined
// JS looks up the chain until it finds the variable or exhausts the chain

Hoisting of Function Declarations vs Function Expressions

Function declarations and function expressions behave very differently when it comes to hoisting. A function declaration is fully hoisted — both the declaration and the function body are moved to the top of the enclosing scope. A function expression is treated as a variable assignment — only the variable declaraton is hoisted (if var), and the function body is not assigned until the executable code reaches that line.

This distinction catches many developers off guard. If you call a function expression before its definition, you'll get a TypeError because the variable is undefined (if var) or a ReferenceError (if let/const due to TDZ).

Recommended practice: use function declarations for top-level functions that need to be called anywhere in the scope. Use function expressions for callbacks and when you want to limit the function's hoisting to avoid confusion.

// Function declaration — fully hoisted
console.log(sum(2, 3)); // 5 — works!

function sum(a, b) {
  return a + b;
}

// Function expression assigned to var — variable hoisted, function not
console.log(multiply); // undefined (var hoisted)
// console.log(multiply(2, 3)); // TypeError: multiply is not a function
var multiply = function(a, b) {
  return a * b;
};
console.log(multiply(2, 3)); // 6 — now it works

// Function expression assigned to let — not accessible before declaration
// console.log(divide(6, 2)); // ReferenceError: Cannot access 'divide' before initialization
const divide = function(a, b) {
  return a / b;
};
console.log(divide(6, 2)); // 3

// Arrow functions are also function expressions
// console.log(subtract(5, 2)); // ReferenceError
const subtract = (a, b) => a - b;
console.log(subtract(5, 2)); // 3

Block Scope Is a Lie — Until ES6

Here's where most junior engineers burn production systems. You see curly braces, you assume a new scope. In C, Java, even C#, that's true. In JavaScript before ES2015? The if block, for loop, while — they don't create a scope. var laughs at your blocks. It gets hoisted to the nearest function or global scope. So when you write for (var i = 0; i < 5; i++) and schedule an async callback referencing i, every callback sees 5. Not 0,1,2,3,4. That's not a bug. That's var doing exactly what it was designed to do: ignore block boundaries. ES2015 introduced let and const. They actually respect blocks. No hoisting leak. No shared mutable state across iterations. Never use var in a block again. Your async code will thank you.

// io.thecodeforge
// Before ES6: var ignores block scope
function leakyLoop() {
  for (var i = 0; i < 3; i++) {
    setTimeout(() => console.log(i), 0); // 3, 3, 3
  }
}
leakyLoop();

// After ES6: let respects block scope
function safeLoop() {
  for (let i = 0; i < 3; i++) {
    setTimeout(() => console.log(i), 0); // 0, 1, 2
  }
}
safeLoop();

Class Hoisting — The Silent Import Killer

You think hoisting only affects var and function declarations? Wrong. Class declarations are hoisted too — but not in the way you expect. They are hoisted to the top of their scope, but they remain uninitialized until the actual declaration is evaluated. This means you cannot use a class before its definition, even if it's hoisted. Try accessing new MyClass() before the class keyword appears? You get a ReferenceError. This trips up anyone importing classes conditionally or reordering module exports during refactoring. The fix is simple: always declare classes at the top of their module, before any usage. No exceptions. For function-like constructors, use class syntax, not function — it enforces the temporal dead zone and catches errors at compile time instead of runtime.

// io.thecodeforge
// Class hoisting — temporal dead zone applies

// This throws: ReferenceError: Cannot access 'User' before initialization
function createAdmin() {
  return new User('admin');
}

class User {
  constructor(name) {
    this.name = name;
  }
}

console.log(createAdmin());

// Correct: declare before use
class Product {
  constructor(sku) {
    this.sku = sku;
  }
}

function createProduct(sku) {
  return new Product(sku);
}
console.log(createProduct('PROD-001'));