Запропонувати правку

Покращити цю статтю

Допрацюйте відповідь до «strict: false». Ваші зміни проходять модерацію перед публікацією.

Потрібне підтвердження

Контент

Що ви змінюєте

Заголовок (UA)

Коротка відповідь (UA)

Показується над повною відповіддю для швидкого нагадування.

Відповідь (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" });
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-багів.

Markdown · перетягуйте зображення · ⌘B / ⌘I шорткати706 слів

Для рев’юера

Примітка для модератора (необов’язково)

Бачить лише модератор. Прискорює рев’ю.