In JavaScript, what happens when you put a `function` declaration inside an `if` block, and how does the result differ between strict-mode code such as an ES module and a sloppy-mode script in a browser?

## The pre-2015 mess, and what fixed it A function declaration nested in a block was not defined by the ES5 grammar at all — it was a syntax extension every engine implemented differently. ES2015 finally specified it: **a function declaration inside a block is a block-scoped declaration**, like `let`. That is the rule to hold in your head. ```js "use strict"; { function helper() { return 1; } helper(); // 1 - fine inside the block } helper(); // ReferenceError: helper is not defined ``` The same applies inside `if`, `for`, `while`, `try` blocks and any other braces that form a block — but *not* to the top level of a function body or a script, where declarations remain function-scoped as always. ## The sloppy-mode legacy layer Making the new rule universal would have broken a great deal of existing web content, so the specification's web-compatibility annex adds an extra behaviour that applies **only to non-strict code** in hosts that implement it (browsers, and Node's non-strict scripts). Under it, the block-scoped declaration is still created, and in addition: - a `var`-style binding with the same name is created in the enclosing function or script scope, initialised to `undefined` when that scope is entered; - when control actually reaches the declaration inside the block, the current value of the block-scoped function is copied out to that outer binding. The observable result is a hybrid: the *name* behaves as if `var helper;` had been hoisted, while the *value* only appears once the block has run. ```js // sloppy-mode script, not a module console.log(typeof helper); // "undefined" if (true) { function helper() { return 1; } } console.log(typeof helper); // "function" ``` Run that as an ES module and the last line throws instead. Nothing about the file changed except its mode, which is what makes this trap so easy to hit during a migration from classic scripts to modules, or when adding `"use strict"` to an old file. ## The conditional-definition trap The pattern that motivates the question is choosing an implementation with if/else: ```js if (supportsFeature) { function render() { /* fast path */ } } else { function render() { /* fallback */ } } render(); ``` Under the legacy sloppy-mode rules, whichever branch executes copies its function out, so this happens to work — but it depends on run-time flow, not on where the code is written, and reviewers routinely misread it. In strict mode or a module it fails outright with a `ReferenceError`, because both `render` bindings died with their blocks. And in a `switch` statement — whose whole body is a single block — two branches declaring the same function name are in the *same* block, which makes the code a syntax error in strict mode rather than a run-time surprise. ## What to write instead Declare the binding at the level you want it and assign function *expressions* inside the branches. This has one meaning in every mode: ```js let render; if (supportsFeature) { render = () => { /* fast path */ }; } else { render = () => { /* fallback */ }; } render(); ``` Or, when both implementations are simple, hoist both to the top level and pick between them as values: ```js function fastRender() {} function fallbackRender() {} const render = supportsFeature ? fastRender : fallbackRender; ``` The second form is usually the better one: both functions are ordinary top-level declarations, so tooling, tests, and stack traces see real named functions, and the conditional part is reduced to choosing a value. ## Diagnosing it in the wild Three symptoms point here. A `ReferenceError: x is not defined` after a build change that turned scripts into modules. A `TypeError: x is not a function` at load time in a sloppy script, because something ran before the block that defines `x`. And behaviour that differs between a bundled build and a plain `<script>` load — bundlers emit module code, which is strict, so the legacy layer is not there to rescue you. In all three cases the fix is the same: stop relying on a declaration escaping its block. As a working rule, treat function declarations as legal only at the top level of a script, module, or function body. Anywhere inside braces, use an expression assigned to a binding you declared yourself.