Обидві опції закривають «дірки», які лишає навіть strict, тому їх часто вмикають додатково.
noUncheckedIndexedAccess - доступ за індексом чи довільним ключем може повернути undefined:
const items: string[] = [];
const first = items[0]; // без опції: string, з опцією: string | undefined
first.toUpperCase(); // з опцією: помилка 'first' is possibly 'undefined'
const prices: Record<string, number> = {};
prices['coffee'].toFixed(2); // з опцією: помилка
Без опції TypeScript вважає, що елемент масиву чи значення словника завжди є, - і items[0] на порожньому масиві падає під час виконання.
Поведінка, яку варто знати:
for...of,map,forEachне потребують перевірок - елемент там точно існує;- кортежі з відомою довжиною (
[string, number]) не уражені; Map.get()і так повертаєT | undefinedнезалежно від опції.
exactOptionalPropertyTypes - розрізняє «властивості немає» і «властивість є і дорівнює undefined»:
type Options = { theme?: 'dark' | 'light' };
const a: Options = {}; // гаразд
const b: Options = { theme: undefined }; // з опцією: помилка
Це важливо, бо в JavaScript ці стани поводяться по-різному: 'theme' in options, Object.keys, розгортання { ...defaults, ...options } - явний undefined перезапише значення за замовчуванням. Якщо undefined справді допустиме, його вказують явно: theme?: 'dark' | 'light' | undefined.
Чому вони не в strict:
- ціна для наявного коду: увімкнення в старому проєкті дає сотні помилок, частина з яких - перевірки там, де розробник «знає», що значення є;
- шум:
arr[i]у звичайному цикліforз індексом теж вимагає перевірки чи!; - сумісність з бібліотеками:
exactOptionalPropertyTypesвиявляє розбіжності в типах сторонніх пакетів.
Рекомендація: у нових проєктах вмикати обидві (пресет @tsconfig/strictest так і робить). У наявних - noUncheckedIndexedAccess у першу чергу: він ловить реальні помилки «undefined is not an object».