21 вересня 2026 року ми виконали на власному сайті npx tsc --noEmit. Ця перевірка нічого не збирає, лише перевіряє типи в TypeScript-проєкті. Результат: 154 помилки.
Дивне тут не число. Дивно, що жодна з цих помилок ні разу не зупинила збірку. У tsconfig.json стояло strict: true, найсуворіший режим перевірки. А в next.config.mjs поруч жили два рядки:
typescript: { ignoreBuildErrors: true },
eslint: { ignoreDuringBuilds: true },
Перевірка виконувалась під час кожної збірки, і її результат щоразу викидався. Збірка лишалась зеленою за будь-якої кількості помилок. Лінтер того ж дня мав 857 зауважень; найбільші групи — 547 про тип any і 300 про невикористані змінні.
Нижче про те, що сиділо всередині тих 154 помилок, чому такі дефекти нікому не заважають і як перевірити, чи захищає вас ваша збірка.
Спершу вирішити, що рахувати
154 — це все разом. 65 помилок були в разових скриптах і тестах, які на прод не потрапляють. Решта 89 — у коді, що обслуговує відвідувачів і адмінку.
Тому першим кроком ми винесли скрипти в окремий tsconfig. Помилку в скрипті, який запускали один раз для перенесення даних, варто виправити, але про стан сайту вона нічого не каже. На момент цього розділення помилок лишалось 132, і 59 із них сиділи саме в скриптах. Рахувати треба те, що працює в проді, інакше пріоритети розмиваються з першого дня.
Два дефекти, які показували нулі
Найдорожчими виявились не ті помилки, що могли б покласти сторінку. Сторінки працювали. Проблеми сиділи там, де сайт показує цифри.
Статистика коротких посилань в адмінці. Для кожного посилання там є картки й графіки: з яких пристроїв переходили, з яких країн. Усі вони показували нуль. Сервер віддавав розбивку словником, приблизно так:
{ desktop: 206, mobile: 33 }
Інтерфейс натомість чекав масив і перевіряв вхід через Array.isArray. Словник цю перевірку не проходить, тому компонент вирішував, що даних немає, і малював нуль. TypeScript казав про це прямо: об'єкт не можна присвоїти типу масиву. Збірка це повідомлення викидала.
Після виправлення на нашому посиланні з 252 кліками з'явилось те, що там було весь час: 206 переходів із десктопа, 33 з мобільних, топ-країна Україна зі 199 кліками.
Експорт аналітики. Кнопки вивантаження в CSV, Excel і PDF працювали, файли завантажувались, а в кожній клітинці стояв нуль. Дані зберігались як словник «період → число», код експорту шукав у ньому об'єкти з полем .count. У числа такого поля немає, тож кожне значення перетворювалось на нуль. Рядок підсумку виглядав ще красномовніше: 0[object Object]. Суму рахували, додаючи до нуля об'єкти замість чисел, і JavaScript склеїв їх у рядок.
Для власника сайту наслідок в обох випадках однаковий: звіт є, виглядає нормально і бреше. Рішення, прийняте на такому звіті, прийняте на нулях.
Решта живих дефектів
У вкладці SEO-сторінок адмінки сортування за колонкою мовчки ігнорувалось. Інтерфейс надсилав параметри sortBy і sortOrder, сервер чекав orderBy і orderDir. Стрілка в заголовку перемикалась, список лишався в тому самому порядку. Людина, яка на це дивиться, радше вирішить, що так задумано, ніж піде шукати розбіжність у назвах параметрів.
Аналітика кнопки «поділитись» писалась зі зсувом: у мітку платформи потрапляла адреса статті, а в адресу статті — слово «button». Аргументи функції стояли не в тому порядку.
Ще одна дрібниця стосувалась листа-підтвердження з контактної форми. Шаблон чекав поле «компанія», якого немає ні у формі, ні в базі, тож рядок «від компанії …» у листі не з'являвся ніколи.
Облік запитів, який запрацював 20 вересня, мав витік міток. Для маршрутів під /api мітка бралась із сирої адреси, і боти, що перебирають адреси на кшталт /api/.env чи /api/credentials.yml, за першу добу дали 15 із 30 міток API. Кожна нова адреса сканера — нова серія в системі метрик назавжди. Тепер усі 404 під /api зливаються в одну мітку.
Найдивнішою знахідкою був модуль CDN. CDN у сайту немає, а ендпоінт без жодної авторизації віддавав будь-кому вигадану статистику: «частка влучань у кеш 81,6%» із датами січня. Функція «очищення кешу» нічого не очищала, лише писала в лог Cache purged successfully. Ми видалили модуль разом з іншим кодом, який ніхто не викликав, — загалом близько 1 300 рядків.
Пастки, які ще не спрацювали
Деякі знахідки нічого не ламали лише тому, що відповідний код зараз не виконується.
У проєкті жили дві однойменні функції обліку запитів з різним порядком аргументів. Один модуль імпортував не ту, і код статусу 200 опинявся в мітці HTTP-методу. Поки цей шлях не викликається, шкоди немає. Щойно його підключили б, метрики були б перемішані з першого запиту.
Тести теж виявились декорацією: vitest не запускався взагалі, бо бракувало пакета середовища jsdom. Тестовий файл маршруту перевірки стану описував його версію, якої давно не існувало. Після виправлення в проєкті 67 тестів, усі проходять.
Решта помилок належала до типу «тип бреше про рантайм». Поле є в базі, але його немає в ручному описі типу; той самий тип оголошено двічі; параметр функції без типу взагалі. Роботу сайту це не ламало. Проте живі дефекти вище сиділи саме в цьому шумі, і дістатись до них можна було, лише пройшовши його весь.
Чому це мовчить
Зелена збірка — найсильніший сигнал «усе гаразд», який є в розробці. Коли помилки ігноруються, їх ніхто не бачить, і кожна нова тоне серед старих.
Прапорець ignoreBuildErrors часто з'являється з цілком зрозумілої причини: правку треба викласти терміново, а збірка падає на чомусь стороньому. Його вмикають один раз, щоб швидко задеплоїти, і забувають.
Найважливіше інше: ці дефекти не валили сторінки. Адмінка показувала нулі, а не помилку. Нуль — правдоподібне значення, бо переходів справді могло не бути. Тихі нулі ніхто не репортить. Схожий візерунок ми вже розбирали в історії про моніторинг, що жив лише в документації: метрики оголошені, панелі стоять, а даних під ними немає.
Як ми розбирали
Кожну помилку читали як питання «що тут відбувається під час виконання?», а не «як це заглушити». as any чи // @ts-ignore прибирають червоне підкреслення за секунду й ховають дефект надовго.
Найбільше уваги отримали такі повідомлення:
- «властивості не існує» (TS2339): код читає поле, якого в даних немає, отже завжди отримує
undefined; - «аргумент не того типу» (TS2345): часто за цим стоїть переплутаний порядок аргументів, як у кнопці «поділитись»;
- «не можна присвоїти» (TS2322): дані мають іншу форму, ніж чекає інтерфейс. Саме так виглядали нулі в статистиці посилань.
Кожен знайдений дефект перевіряли окремо, даними з бази або запуском. Зникнення помилки в редакторі доказом не вважали: його можна отримати й неправильним виправленням.
Що змінилось 22 вересня
Коли помилок типів у коді стало нуль, ми вимкнули ігнорування: ignoreBuildErrors: false. Тепер нова помилка типів зупиняє збірку й до прода не доходить.
Лінтер у збірці поки вимкнений. Там ще сотні зауважень про any, і зупинка на ньому зараз означала б зупинку кожного деплою. Невикористані змінні прибрали механічно: було 291, стало 106.
Порядок кроків тут має значення. Якби ми спершу вимкнули ігнорування, а потім почали виправляти, перший же деплой зупинився б.
Як перевірити у себе
Перше — чи збірка взагалі зважає на типи:
grep -n "ignoreBuildErrors\|ignoreDuringBuilds" next.config.*
Якщо там true, зелена збірка нічого не говорить про стан коду. Далі порахуйте реальну кількість помилок:
npx tsc --noEmit | grep -c "error TS"
Відфільтруйте скрипти й тести та дивіться на код застосунку: він і є сайт. Починати варто з трьох кодів, які найчастіше означають справжню розбіжність між даними й кодом:
npx tsc --noEmit | grep -E "TS2339|TS2345|TS2322"
Окремо перевірте, чи тести стартують: npx vitest run або npm test. Тести, що не запускаються, нічого не перевіряють, скільки б їх не було у репозиторії.
Зупинку збірки вмикайте лише після того, як помилок стане нуль. Інакше наступний деплой зупиниться, і прапорець повернуть назад.
Якщо розробника під рукою немає, попросіть когось виконати дві перші перевірки й показати результат. Коли в конфігурації true, а помилок десятки, цифрам в адмінці варто влаштувати вибіркову перевірку: відкрийте статистику, де правильну відповідь ви знаєте з іншого джерела, і звірте.
Межі цього розбору
Це один проєкт — наш сайт. З 154 помилок у нас знайшлось сім живих дефектів і кілька пасток, які ще не встигли спрацювати. В іншому проєкті під тими самими помилками може виявитись більше, менше або нічого. Кількість помилок типів не каже, скільки під ними поломок. Вона каже лише, що збірка про них мовчить.
Якщо проєкт дістався вам від іншого виконавця і невідомо, що в ньому працює, а що лише так виглядає, такий розбір входить у підхоплення покинутого проєкту. Коли конкретні поломки вже помічені, це виправлення після підрядника.
Для себе ми винесли одне правило: перевірка, результат якої викидається, не краща за відсутність перевірки. Вона лише створює враження, що захист є.
