TypeScript и ESLint помогают поймать часть ошибок ИИ-агента до запуска сайта: компилятор проверяет типы и структуру кода, а линтер — правила оформления и распространённые проблемные конструкции. Чтобы проверки работали, настройте строгий режим TypeScript, добавьте ESLint и запускайте обе проверки после каждого заметного изменения. В статье разберём, с чего начать, как читать сообщения об ошибках и почему автоматические проверки не заменяют тесты по требованиям.
Что именно проверяют TypeScript и ESLint?
TypeScript помогает обнаружить несоответствия в коде. Например, функция ожидает число, а агент передал текст, или компонент обращается к свойству, которого нет в описании данных. Проверка сработает до того, как пользователь откроет страницу, если проект настроен и команда запускает компиляцию.
ESLint анализирует код по набору правил. Он находит, например, неиспользуемые переменные и некоторые рискованные шаблоны. Набор правил задаёт владелец проекта: слишком мягкие проверки пропускают ошибки, а слишком строгие могут отвлекать на мелкие замечания.
Эти инструменты не подтверждают, что функция выполняет задачу правильно. Если агент создал форму, которая отправляет не те данные, компилятор может не заметить проблему, когда типы формально совпадают. Для поведения нужны тесты, написанные по требованиям.
Как настроить строгую проверку TypeScript?
Начните с файла конфигурации TypeScript. Включите строгий режим, если проект готов исправлять найденные несоответствия. Настройка strict объединяет несколько проверок типов; после её включения старый код может выдать много ошибок. Поэтому перед изменением сохраните текущую версию в Git и применяйте настройку отдельно от большой правки агента.
Попросите агента не отключать проверки ради успешной сборки. Если он предлагает поставить any, подавить ошибку комментарием или ослабить конфигурацию, попросите объяснить причину и предложить типизированный вариант. Например, для данных формы лучше описать поля и допустимые значения, чем заменить тип на универсальный.
Проверяйте результат отдельной командой компиляции без генерации файлов. Название команды зависит от проекта, поэтому посмотрите раздел scripts в package.json или конфигурацию сборки. После исправления ошибок запустите проверку повторно: агент мог исправить один тип и нарушить другой.
Как подключить ESLint и не утонуть в предупреждениях?
Сначала выясните, установлен ли ESLint и какой файл конфигурации использует проект. Если агент добавляет линтер с нуля, попросите его указать, какие правила включены и какую команду запускать. Не подключайте одновременно несколько наборов правил без причины: повторяющиеся проверки создают шум и мешают разбирать важные сообщения.
Запускайте ESLint по изменённым файлам или по всему проекту — выбор зависит от размера и состояния кодовой базы. Если проект уже содержит старые предупреждения, зафиксируйте их отдельно и договоритесь, что новая работа не увеличивает их число. Так агенту проще исправлять свой участок, не переписывая весь сайт.
Для повторяемого процесса добавьте команды проверки в scripts проекта, например отдельные команды для TypeScript и ESLint. Попросите агента сообщать, какие команды он выполнил и что осталось без проверки. Если локальная среда не позволяет запустить команду, это нужно обозначить, а не выдавать предположение за успешную проверку.
Правила проекта можно описать в файле инструкций для агента. В материале о настройке CLAUDE.md разобрано, как закрепить такие требования, чтобы агент учитывал их при работе.
Как встроить проверки в работу с ИИ-агентом?
Давайте агенту небольшие задачи и просите после каждой изменить код, запустить нужные проверки и перечислить результат. Если проверка нашла ошибку, сначала попросите объяснить её простыми словами, затем предложить минимальное исправление. Не поручайте агенту менять настройки линтера и исправлять бизнес-логику в одном запросе: будет сложнее понять, откуда пришла проблема.
Удобный порядок работы выглядит так:
- Сформулируйте требование к функции и укажите файлы, которые можно менять.
- Попросите агента внести изменение без ослабления TypeScript и ESLint.
- Запустите проверку типов и линтер, затем разберите каждое сообщение.
- Отдельно проверьте поведение функции по требованиям и запустите тесты.
- Посмотрите разницу в Git и сохраните только понятные изменения.
Для сайта с уже работающими функциями проверяйте также соседние сценарии: новая форма может затронуть страницу, где используются те же данные. Подход к повторной проверке после изменений описан в материале о тестировании старых функций сайта после правок ИИ-кода.
Какие ошибки настройки встречаются чаще всего?
- Отключать проверку, чтобы сборка прошла. Попросите агента исправить причину ошибки, а не удалять правило или добавлять подавляющий комментарий.
- Считать чистый вывод линтера доказательством правильной работы. Линтер проверяет код по правилам, но не знает, что именно должен увидеть клиент на странице.
- Менять сразу много настроек. Вносите изменения по одному и проверяйте результат после каждого шага.
- Не запускать команды после исправления. Агент мог добавить новую ошибку, пока устранял предыдущую.
- Не смотреть изменения в Git. Просмотрите список файлов и правки, прежде чем принимать результат агента.
TypeScript и ESLint дают ранний сигнал о проблемах, но качество функции проверяют по её требованиям. На этой неделе выберите одну небольшую задачу, включите для неё проверку типов и линтер, а поведение проверьте отдельными тестами. Если агент меняет код, попросите его назвать выполненные проверки и оставшиеся ограничения.
