Запропонувати правкуПокращити цю статтюДопрацюйте відповідь до «strict: false». Ваші зміни проходять модерацію перед публікацією.Потрібне підтвердженняКонтентЩо ви змінюєте🇺🇸EN🇺🇦UAПереглядЗаголовок (UA)Коротка відповідь (UA)`strict: true` вмикає одразу весь набір строгих перевірок TypeScript (`noImplicitAny`, `strictNullChecks`, `strictPropertyInitialization` та інші), без яких компілятор лише "підсвічує" типи, а не гарантує безпеку. **Ключове:** без strict TypeScript дозволяє неявні `any` та пропускає `null`/`undefined`, тобто перетворюється на JavaScript із типами "для вигляду".Показується над повною відповіддю для швидкого нагадування.Відповідь (UA)Зображення## Що робить `strict: true` Коли в `tsconfig.json` увімкнено: ```javascript { "compilerOptions": { "strict": true } } ``` TypeScript вмикає **весь набір строгих перевірок**, які роблять його **справді безпечною мовою**, а не просто підсвічуванням типів. `"strict": true` - це флаг-комбо, який вмикає одразу **всі** строгі перевірки (еквівалент набору параметрів): ```javascript { "strict": true } ``` ≡ вмикає: - `noImplicitAny` - `strictNullChecks` - `strictBindCallApply` - `strictFunctionTypes` - `strictPropertyInitialization` - `noImplicitThis` - `alwaysStrict` --- ## Чому TypeScript без `strict` майже безглуздий Тому що **весь сенс TypeScript - гарантувати типову безпеку**. Якщо `strict` вимкнено, TypeScript перестає це робити. Він починає *здогадуватися* про типи, дозволяє неявні `any`, і не перевіряє найчастіші джерела багів (наприклад, `null`, `undefined`, невідповідності аргументів тощо). Іншими словами: > Без strict TypeScript ≈ JavaScript + типи "для вигляду". --- ## 1. Без `noImplicitAny` - зникає сенс типізації ```javascript function sum(a, b) { return a + b; } ``` Без `strict` → TypeScript вважає `a` і `b` типом `any`. Ти можеш викликати: ```javascript sum(2, "abc"); // OK ``` TypeScript не попередить, хоча результатом буде `"2abc"`. При `strict: true`: ```javascript function sum(a: number, b: number): number { return a + b; } ``` Тепер: ```javascript sum(2, "abc"); // Помилка типів ``` --- ## 2. Без `strictNullChecks` зникає захист від `null` / `undefined` ```javascript function greet(name: string) { console.log("Hi " + name.toUpperCase()); } greet(undefined); // Runtime error ``` Без `strict` TypeScript думає: > "ну, раптом `undefined` - це нормально" При `strictNullChecks: true`: > Помилка: Argument of type 'undefined' is not assignable to parameter of type 'string'. Це **головна причина**, чому strict потрібен - 60-70% реальних багів у JS пов'язані з `undefined`. --- ## 3. Без `strictPropertyInitialization` класи стають небезпечними ```javascript class User { name: string; greet() { console.log("Hi " + this.name.toUpperCase()); } } new User().greet(); // this.name = undefined → помилка в runtime ``` При `strict: true`: > Помилка: Property 'name' has no initializer and is not definitely assigned. Тепер ти зобов'язаний ініціалізувати властивість у конструкторі: ```javascript class User { name: string; constructor(name: string) { this.name = name; } } ``` --- ## 4. Без `strictFunctionTypes` можна зламати сумісність функцій ```javascript let fn: (a: string) => void; fn = (a: any) => console.log(a); // мало б бути заборонено ``` Без `strict` TS вважає це нормою - зникає безпека при передачі колбеків. --- ## 5. Без `noImplicitThis` можливі дивні помилки контексту ```javascript function sayHi() { console.log(this.message); } sayHi.call({ message: "Hello" }); // ok sayHi(); // this === undefined ``` Без `strict` TypeScript не перевірить, що `this` не визначено. Зі `strict` ти отримаєш помилку: > 'this' implicitly has type 'any'. --- ## 6. Без `alwaysStrict` TS не використовує строгий режим JS TypeScript перестає компілювати файли з `"use strict"`, що спричиняє більш "розслаблену" поведінку JavaScript (наприклад, нестрога робота з `this`, `delete`, `var` тощо). --- ## 7. Без strict TS перестає бути "страховкою" Без `strict` TS не може гарантувати коректність коду. Приклад: ```javascript function processData(data) { return data.value.toFixed(2); } processData(null); // Runtime error ``` TypeScript навіть не скаже, що `data` може бути `null`. А зі `strict` одразу попередить: > Object is possibly 'null'. --- ## 8. Тип `any` стає вірусом Коли `strict` вимкнено, TypeScript часто **автоматично підставляє** `any`, якщо не знає тип. ```javascript let user; // implicit any user.toUpperCase(); // runtime error ``` "Невизначені" типи починають поширюватися по всьому коду. А зі `strict`: > Error: Variable 'user' implicitly has an 'any' type. --- ## 9. Коли strict увімкнено - компілятор допомагає тобі писати надійний код TypeScript починає: - перевіряти кожен nullable кейс (`null`, `undefined`); - контролювати ініціалізацію властивостей у класах; - забороняти неявні `any`; - робити функції **контраваріантними** (тобто несумісними за небезпечними аргументами); - допомагати IDE пропонувати безпечні автодоповнення. --- ## Приклад: проект без strict vs зі strict | Сценарій | Без `strict` | Зі `strict: true` | |---|---|---| | Невказані типи | неявно `any` | помилка | | `null` і `undefined` | проходять без помилок | помилка | | Властивості класу без ініціалізації | допускаються | помилка | | Помилки в контексті `this` | не перевіряються | перевіряються | | Безпека типів | мінімальна | висока | | IntelliSense | неточний | точний | | Runtime-баги | часті | рідкісні | --- ## 10. Проста аналогія > Без `strict` - TypeScript просто додає розфарбування й автодоповнення. > > Зі `strict: true` - він стає **справжнім статичним аналізатором**, > який реально захищає твій код від 90% типових JS-багів.Для рев’юераПримітка для модератора (необов’язково)Бачить лише модератор. Прискорює рев’ю.