Implicit Globals & strict mode
debt(d3/e3/b5/t5)
Closest to 'default linter catches the common case' (d3). The term's detection_hints lists ESLint and TypeScript as tools, and automated detection is marked yes. ESLint's no-undef rule is a standard/default-adjacent rule that catches accidental globals and missing declarations, placing this firmly at the linter-catches level rather than needing a specialist tool.
Closest to 'simple parameterised fix' (e3). The quick_fix says: add 'use strict' to all non-module scripts, enable ESLint no-undef, use TypeScript, or switch to ES modules. This is a small but non-trivial fix — it may touch multiple script files but follows a clear pattern (add directive, fix declarations) without requiring deep architectural change.
Closest to 'persistent productivity tax' (b5). Implicit globals apply to web and CLI contexts broadly. In long-running apps and test suites, state leakage and test interference are ongoing costs that slow multiple work streams (debugging mysterious state, flaky tests, memory leaks). The burden is not purely localised but not quite architectural in weight.
Closest to 'notable trap' (t5). The misconception field states that developers assume 'use strict' is optional because ES modules are strict by default — but classic scripts still need it explicitly. This is a well-documented gotcha that many developers learn the hard way, especially when mixing module and classic script loading contexts. It contradicts a reasonable inference from modern JS defaults.
TL;DR
Explanation
In non-strict mode, assignment to an undeclared variable creates a global: function foo() { x = 5; } sets window.x (browser) or global.x (Node). This is a silent bug that pollutes the global scope. 'use strict' throws ReferenceError instead. ES modules ('type': 'module') are automatically strict. Implicit globals are a source of cross-frame pollution in browsers, race conditions in async code, and test pollution. They're also a memory leak source — globals are never GC'd. TypeScript catches all implicit globals at compile time.
Common Misconception
Why It Matters
Common Mistakes
- Forgetting var/let/const in a loop: for (i = 0; ...) creates global i.
- Module code that assumes strict mode but is loaded as a classic script.
- Not checking for accidental globals in test setup/teardown.
Code Examples
function processUser(name) {
userName = name; // Creates global 'userName' silently!
}
processUser('Paul');
console.log(window.userName); // 'Paul' — global pollution'use strict';
function processUser(name) {
let userName = name; // Local — no global pollution
// Or: 'use strict' would throw ReferenceError without declaration
}
// ES modules are strict by default:
// <script type="module">