Ошибки ИИ в JS и TS и чек-лист

как отличить решение от заглушки

Что это

Завершение главы. У JavaScript и TypeScript есть своя особенность: здесь у ИИ есть лёгкий способ заставить проверку замолчать. Три символа — и ошибка исчезла, не будучи исправленной.

Отличать исправление от заглушки — главный навык этой статьи.

Три заглушки, которые надо узнавать

1. any

function handle(data: any) { ... }

Отключает проверку целиком. Всё, что приходит из any, компилятор перестаёт смотреть, и зараза расползается дальше по коду.

Честная замена: unknown, которая заставляет проверить, или нормальный тип.

2. as

const city = data as City;

Обещание компилятору, разобранное в статье 9.5. Опаснее any, потому что выглядит как типизированный код.

Когда оправдано: редко и осознанно — например, после собственной проверки, которую компилятор не понимает. Тогда рядом должен быть комментарий, почему.

3. @ts-ignore и @ts-expect-error

// @ts-ignore
widget.render(options);

Выключает проверку следующей строки. Всегда требует объяснения: если причина не записана, через месяц никто не вспомнит, что здесь скрыто.

Остальные частые ошибки

4. strict выключен. Без него нет проверок на null — главной пользы (статья 9.3).

5. Promise.all вместо allSettled, когда нужен частичный результат (статья 9.2).

6. forEach(async ...). Не ждёт. Всегда ошибка, если результат нужен.

7. == вместо === и || вместо ?? (статья 9.1).

8. Типы продублированы руками. Отдельно схема проверки, отдельно интерфейс — разъедутся.

9. Код для старых версий. var, .then() вместо await, классовые компоненты. Обучающих данных той эпохи больше (статья 3.1, причина 3).

10. Несуществующий метод библиотеки. Галлюцинация (статья 4.8). В TypeScript ловится компилятором — если у библиотеки есть типы.

Чек-лист JS и TS

К общему чек-листу приёмки (статья 4.7) добавляются пять шагов.

1. Проверка типов

npx tsc --noEmit

Самый выгодный шаг. Ловит пять классов ошибок из статьи 9.5.

2. Поиск заглушек в диффе

git diff | grep -nE "\bany\b|\bas [A-Z]|ts-ignore|ts-expect-error"

Одна команда показывает все места, где проверка отключена. Каждое должно быть объяснимо.

3. Линтер

npx eslint .

Ловит то, что типы не видят: ==, неиспользуемые переменные, забытые await, forEach с async (при подходящих правилах).

4. Запуск

npx tsx app.ts

Тип не гарантирует, что данные снаружи придут нужной формы (статья 9.5). Запускать обязательно.

5. Граница

Посмотреть, откуда в код попадают внешние данные: fetch, JSON.parse, localStorage, формы. Везде ли есть проверка во время выполнения, а не только as.

Как сказать ИИ

Проверь свой код по списку:
- есть ли any, as или ts-ignore и почему
- включён ли strict и проходит ли tsc --noEmit
- есть ли == вместо === и || там, где нужен ??
- есть ли forEach с async внутри
- Promise.all там, где нужен частичный результат
- где данные приходят извне и проверяются ли они

Что из этого есть? Если ничего — так и скажи.

Отдельно — просьба, которая экономит целый круг переписок:

Исправь ошибки типов по существу. Не используй any, as
и ts-ignore. Если ошибку нельзя исправить без них —
объясни, почему, и не исправляй.

Последнее предложение важно: оно разрешает ИИ сказать «не получается» вместо того, чтобы молча заглушить (статьи 3.8, 4.8).

Шпаргалка