ts-ignore

TypeScriptJunior~3 хв читання

Що робить `// @ts-ignore`

@ts-ignore - це директива компілятора TypeScript, яка змушує компілятор проігнорувати наступний рядок коду, навіть якщо там є помилки типів.

Приклад:

javascript

// @ts-ignore
const x: number = "hello"; // Помилка, але TS мовчить

Компілятор взагалі не перевіряє цей рядок. Типізація вимикається на 100% тільки тут, але наслідки можуть поширитися далі.

Чому `@ts-ignore` небезпечний

1. Він вбиває сенс TypeScript

TypeScript створений, щоб ловити помилки до запуску коду. @ts-ignore буквально каже компілятору:

"Не перевіряй, я сам знаю, що роблю."

Приклад:

javascript

// @ts-ignore
user.profile.name.toUpperCase();

Якщо user виявиться null, код впаде в рантаймі, а компілятор навіть не попередить.

2. Легко перетворюється на "милицю за звичкою"

Часто розробники ставлять @ts-ignore, коли не хочуть розбиратися з типами прямо зараз:

javascript

// @ts-ignore - «потім розберуся»
someFunction(possiblyUndefinedValue);

Через кілька місяців ніхто вже не згадає, чому ігнор стояв. Типи навколо можуть змінитися, і TS більше не захищає від нових помилок.

3. Він приховує справжні проблеми проєктування

Іноді @ts-ignore маскує архітектурну помилку.

Приклад:

javascript

function getUser() {
  // повертає null або undefined
}

// @ts-ignore
getUser().name; // TS думає, все добре

Замість того щоб виправити тип функції (User | null), розробник просто "заткнув" TS. Це технічний борг, який потім вибухає на продакшені.

4. Він заважає рефакторингу

TypeScript допомагає безпечно перейменовувати поля і переміщати функції. Але якщо @ts-ignore стоїть поруч, TS втрачає контекст і не може підказати, що потрібно оновити код.

Приклад:

javascript

// @ts-ignore
userData.adress = "NY"; // одруківка! але TS мовчить

У типах adress уже перейменовано на address, але @ts-ignore все приховав.

5. Він може "заразити" типову систему

Типи в TS часто "протікають" далі по коду. Якщо ти вимикаєш типізацію на одній ділянці, помилки можуть "просочитися" в інші частини застосунку.

Приклад:

javascript

// @ts-ignore
const response = fetchSomething(); // тепер any
response.data.id; // TS не перевіряє

any поширюється далі, IDE перестає підказувати.

6. `@ts-ignore` не те саме, що `@ts-expect-error`

Багато хто плутає ці дві директиви.

Директива	Що робить	Коли корисна
`@ts-ignore`	Повністю вимикає перевірку	Краще уникати
`@ts-expect-error`	Ігнорує помилку, але видає попередження, якщо помилка зникне	Безпечніший варіант

Приклад:

javascript

// @ts-expect-error: known issue with library typing
someLegacyFunction("abc");

Якщо типи пізніше виправляться, TS повідомить, що expect-error більше не потрібен. А @ts-ignore просто мовчатиме назавжди.

Як "ts-ignore" псує проєкт у реальності

Уяви код із 20-30 @ts-ignore:

IDE більше не знає, що де типізовано.
Перевірки стають вибірковими.
Рефакторинг перетворюється на "ходьбу мінним полем".
Будь-яка зміна може викликати крах, якого TS не помітить.

Фактично проєкт втрачає одну з ключових переваг TypeScript: типову цілісність.

Коли використання `@ts-ignore` все-таки виправдане

Іноді справді немає іншого виходу. Ось випадки, коли @ts-ignore допустимий:

1. Тимчасові проблеми із зовнішніми типами (наприклад, з npm)

Іноді бібліотека має биті або несумісні типи, а фіксу чекати довго.

Приклад:

javascript

// @ts-ignore: typings are wrong in library v2.1.0
import brokenLib from "broken-lib";

Виправдано, якщо ти зафіксував причину і версію у коментарі.

2. Під час переходу з JS на TS (у legacy-коді)

Якщо у тебе величезний старий код і ти поступово мігруєш, іноді потрібно тимчасово "пропустити" пару помилок.

Приклад:

javascript

// @ts-ignore: legacy code, will fix later
initializeLegacyModule(config);

Головне - позначити TODO і відстежувати борг (наприклад, лінтером).

3. Під час роботи з динамічними API (наприклад, window, global)

Коли об'єкт створюється динамічно і TS просто не знає про нього.

Приклад:

javascript

// @ts-ignore: injected by analytics script
window.analytics.trackEvent("click");

Краще додати типізацію (declare global), але якщо це одноразовий виклик, це допустимо.

4. Під час тестування edge-кейсів (внутрішні хаки)

Іноді потрібно навмисно "зламати" типи, щоб перевірити реакцію системи.

Приклад:

javascript

// @ts-ignore: intentional invalid input for test
validateUser(123 as any);

У тестах таке буває виправдано.

5. У генераторах коду або low-level утилітах

Наприклад, під час інтеграції з DOM API, коли TS просто не може вивести коректний тип.

Приклад:

javascript

// @ts-ignore: forced casting for internal optimization
element.style["--custom-color"] = "red";

Як робити правильно замість `@ts-ignore`

Проблема	Правильне рішення
Помилка типів у бібліотеці	Додай тип `@types/...` або `declare module`
Невідомий тип	Використай `unknown` або `any` з коментарем
Невизначена властивість	Додай optional chaining (`?.`)
Неявне приведення	Використай `as const` або уточнення типу
Перехідний код	Загорни у функцію з чітко типізованим інтерфейсом

Приклад:

javascript

// Погано
// @ts-ignore
user.age.toFixed();

// Добре
if (user?.age != null) {
  user.age.toFixed();
}

Як контролювати зловживання `@ts-ignore`

Додай правило в ESLint:

javascript

"@typescript-eslint/ban-ts-comment": ["error", {
  "ts-ignore": true,
  "ts-expect-error": "allow-with-description"
}]

Тепер @ts-ignore буде заборонено, а @ts-expect-error дозволено тільки з поясненням.

Підсумок

Питання	Відповідь
Чому небезпечний?	Повністю вимикає перевірку типів, приховує помилки і ламає типову безпеку
Коли допустимий?	Тимчасові милиці: биті типи бібліотек, legacy-код, тести, глобальні об'єкти
Як краще?	Використовувати `@ts-expect-error` з описом причини
Альтернатива	Виправити типізацію, уточнити тип, використати `unknown` або `declare`
Найкраща практика	0 `@ts-ignore` у продакшені, максимум - у тестах і міграціях

Коротка відповідь

Для співбесіди

Premium

Коротка відповідь допоможе вам впевнено відповідати на цю тему під час співбесіди.