TypeError — Common Causes and Fixes
debt(d5/e3/b3/t7)
Closest to 'specialist tool catches it' (d5). The detection_hints list TypeScript and ESLint as the tools that catch these issues. Without TypeScript strict mode enabled, plain JavaScript lets null/undefined property access sail past silently until runtime. ESLint can flag some patterns but not all. The common case isn't caught by default linting alone — you need TypeScript's strict null checks or deliberate ESLint rules targeting optional chaining, placing this firmly at d5.
Closest to 'simple parameterised fix' (e3). The quick_fix states enabling TypeScript strict mode or using optional chaining (?.) on external data property accesses. This is more than a single-line patch because it requires identifying and updating all call sites that access potentially-null values from API responses or async data, but it's still a localised pattern-replacement rather than a cross-cutting architectural change. e3 fits.
Closest to 'localised tax' (b3). The applies_to covers both web and cli contexts broadly, but the burden is more a recurring development discipline (always use optional chaining on external data) rather than a deep structural weight. It doesn't shape the entire architecture — it's a per-component tax on every place external/async data is consumed. Slightly above b1 because it affects multiple files and requires ongoing vigilance, but doesn't reach b5's persistent productivity tax level.
Closest to 'serious trap' (t7). The misconception field directly states that TypeErrors frequently occur with correct code receiving unexpected API responses or async race conditions — not just bad code. This directly contradicts the intuition of many competent developers who assume TypeErrors indicate a coding mistake, not a data/timing issue. The async data availability mistake also contradicts synchronous mental models. This is a documented cross-ecosystem gotcha that trips up developers familiar with other languages, earning t7.
Also Known As
TL;DR
Explanation
TypeError occurs when an operation is performed on an incompatible type. The most common: accessing a property on undefined or null. This happens when API responses have unexpected shapes, optional chaining is missing, or async data has not loaded yet. Other common TypeErrors: calling something that is not a function, accessing .length on null, passing wrong argument types. TypeScript catches most TypeErrors at compile time. In PHP, similar errors manifest as 'Call to a member function on null'.
Common Misconception
Why It Matters
Common Mistakes
- Not using optional chaining for potentially-null API response properties
- Forgetting async data is not available synchronously
- Not checking Array.isArray() before calling array methods on unknown values
Code Examples
const user = null;
console.log(user.name); // TypeError: Cannot read properties of null
const num = 42;
num.toUpperCase(); // TypeError: num.toUpperCase is not a function// Optional chaining:
console.log(user?.name); // undefined, no throw
// Type check before calling:
if (typeof value === 'string') {
value.toUpperCase();
}
// TypeScript catches these at compile time