A JavaScript app throws `ReferenceError: Cannot access 'config' before initialization` at startup. What does that specific message tell you, and how do you track down the cause?

## Read the message first JavaScript gives you two very different `ReferenceError`s and they point at different bugs. - **`config is not defined`** — the name resolves to nothing in the whole scope chain. Suspect a typo, a declaration that was deleted, or code running in a scope that never saw it. - **`Cannot access 'config' before initialization`** — the name resolved. There *is* a binding for it in the current or an enclosing scope, declared with `let`, `const`, or `class`, and it is still uninitialized. This is purely an ordering bug. (Engines word the second one differently — SpiderMonkey says "can't access lexical declaration 'config' before initialization", JavaScriptCore says "Cannot access uninitialized variable" — but all mean the same state.) Confusing the two wastes the most time in this bug, because the instinct on any `ReferenceError` is to go hunting for a missing declaration, and here the declaration is right there in the file. ## Why the throw is usually far from the declaration The dead zone is temporal. Code written above a `const` fails; code written below it also fails if it *runs* first. The second case is the one that reaches production: ```js function createClient() { return { url: config.url }; // written below, runs above } const client = createClient(); // throws const config = { url: '/api' }; ``` `createClient` looks correct in isolation and works everywhere else in the program. It throws only on this one call, made while `config` is still uninitialized. Common shapes of the same mistake: - A top-of-scope initialization call — `setup()`, `register()`, `Object.freeze(buildDefaults())` — that transitively reads a `const` declared lower down. - A callback registered and *synchronously invoked* during setup (an event emitter that replays, a plugin that calls its hook immediately) whose body closes over a later `const`. - `new Foo()` above `class Foo {}`. Class declarations sit in the dead zone exactly like `const`, and this one surprises people who remember that function declarations are fully available before their line. - A block-level shadow: an inner `const config` further down a block makes every earlier reference in that block resolve to the inner, uninitialized binding, even though an outer `config` exists and is fine. ## The diagnostic procedure 1. **Take the name from the message** and find its lexical declaration. Confirm it is `let`, `const`, or `class` — it always is. 2. **Read the stack bottom-up** to find the first frame that belongs to the scope containing that declaration. That frame's line number tells you *when* the scope was interrupted, and it is almost always above the declaration. 3. **Ask what ran before the declaration line** in that scope. Any call expression, any side-effecting initializer, any immediately invoked function is a candidate. 4. **Check for shadowing** if the outer name looks initialized: search the enclosing block for a second declaration of the same name below the failing line. 5. **Reproduce by moving the declaration** to the very top of its scope. If the error disappears, the diagnosis is confirmed and you have already found one valid fix. ## Fixing it The fix is always to change *when* things happen, never to add a defensive check — you cannot guard an uninitialized binding, because `typeof config` and `config !== undefined` both throw as hard as the original access. - **Reorder.** Move the declaration above the code that needs it. Cheapest fix, correct when there is no cycle in the dependencies. - **Defer the access.** Wrap the work in a function and call it after setup completes, so the read happens once the binding is initialized. Turning an eager `const client = createClient()` into a lazily called `getClient()` is the standard move. - **Use a function declaration for the entry point.** Function declarations are initialized during scope setup, so the *function* can be referenced anywhere; only the values it reads have to be ready by call time. - **Split the scope.** If a block's shadowing declaration is the cause, rename the inner binding rather than relying on the outer one leaking in — it never will. ## The judgment to show A strong answer treats the error as a *feature*. Under `var` the same ordering mistake would have produced `undefined`, and the failure would have surfaced later as `Cannot read properties of undefined` in a different module, or worse, as a request sent to the URL `"undefined"`. The dead zone converts a silent, delayed corruption into an immediate crash naming the exact binding. That is worth saying out loud, because the reflex fix — "switch it back to `var`" — is the one answer that is genuinely wrong.