Type Coercion Gotchas (== vs ===)
debt(d3/e1/b3/t7)
Closest to 'default linter catches the common case' (d3). The detection_hints list ESLint and TypeScript as tools, and the code_pattern '== [^=]' is exactly what the ESLint `eqeqeq` rule flags by default. This is a well-known, commonly enabled lint rule that catches the primary misuse pattern automatically without any specialist configuration.
Closest to 'one-line patch or single-call swap' (e1). The quick_fix is a direct mechanical replacement: swap == for === everywhere and enable the ESLint eqeqeq rule. Where coercion was intentional, an explicit Number()/String()/Boolean() conversion is a single-call swap. No cross-file refactor is required per instance.
Closest to 'localised tax' (b3). The choice to use == vs === is pervasive in JavaScript but the burden is moderate — it applies broadly across web and CLI contexts, but once the ESLint rule is enforced and the codebase is corrected, ongoing burden is low. It doesn't reshape architecture, but codebases with many loose comparisons impose a persistent review tax until corrected.
Closest to 'serious trap — contradicts how a similar concept works elsewhere' (t7). The misconception field states developers believe '=== is overly strict and coercion is a feature.' The behavior of == directly contradicts intuitions from most other languages (where equality checks types), and the coercion table (0 == '0' == false, null == undefined but null !== false) is notoriously non-intuitive. The security implications (auth bypasses) make the wrong assumption costly, pushing this above t5.
TL;DR
Explanation
JavaScript's Abstract Equality Comparison (==) coerces types before comparing. Famous gotchas: '' == false (true), '0' == false (true), [] == false (true), [] == ![] (true), null == undefined (true), null == false (false — null only == undefined). The + operator also coerces: 1 + '2' = '12', [] + {} = '[object Object]', {} + [] = 0. Practical rule: always use ===, use explicit Number()/String() conversions, enable ESLint eqeqeq rule. TypeScript strict mode eliminates most coercion bugs.
Common Misconception
Why It Matters
Common Mistakes
- Using == for comparisons — enables accidental type coercion.
- String/number comparison in conditions: if (userId == '123').
- Forgetting that + coerces to string when one operand is a string.
Code Examples
0 == '0' // true
0 == false // true
'' == false // true
null == false // false (surprise)
1 + '2' // '12' (string!)// Always use === :
0 === '0' // false
0 === false // false
// Explicit conversions:
const total = Number(priceStr) + Number(taxStr);
// ESLint rule:
// "eqeqeq": "error"