Приходилось ли писать конфиги ESLint и Prettier
Что проверяют
Настраивали ли вы инструменты команды или пользовались готовым конфигом. Вопрос не про синтаксис файла, а про понимание разделения ролей: линтер ищет ошибки, форматтер расставляет пробелы, и смешивать их обязанности не стоит.
Как отвечать
Скажите прямо: Prettier отвечает за оформление, ESLint за правила, которые ловят настоящие ошибки. Стилевые правила линтера при этом отключают готовым конфигом, иначе два инструмента спорят друг с другом и правки ходят по кругу. В новых версиях ESLint форматирующие правила объявлены устаревшими и вынесены в отдельный плагин, так что разделение стало ещё жёстче.
Что полезно назвать из своей настройки:
- современный формат конфигурации, где правила собираются массивом объектов и разные наборы применяются к разным каталогам;
- плагины под стек: правила хуков React, доступность разметки, порядок импортов;
- правила для TypeScript, включая те, что требуют информации о типах, с пониманием, что такой прогон заметно медленнее;
- запуск в CI с запретом на предупреждения и быстрый прогон по изменённым файлам перед коммитом.
Сильный ответ содержит и социальную часть. Новое правило включается не приказом, а в два шага: сначала предупреждением и разбором накопленного, потом уже ошибкой. Массовое переформатирование делается отдельным коммитом, который затем исключают из истории авторства строк, иначе git blame станет бесполезным.
Где спотыкаются
Запускают Prettier как правило ESLint. Каждая лишняя пустая строка превращается в ошибку линтера, вывод забивается шумом, а прогон становится ощутимо дольше. Форматтер вызывают отдельной командой.
Копируют чужой большой конфиг целиком. Через месяц никто в команде не может объяснить, почему правило выключено, а отключения расползаются по файлам построчными комментариями.
Настраивают только редактор и забывают про CI. У кого-то плагин не установлен, у кого-то версия другая, и в ветку приезжает файл, переформатированный целиком. Источник истины это конфиг в репозитории и проверка в пайплайне.