Линтеры и форматирование: урок по Инструменты

В команде код должен выглядеть одинаково и не содержать очевидных ошибок. Спорить об отступах на ревью дорого, поэтому это поручают инструментам: форматтер отвечает за вид кода, линтер за подозрительные конструкции.

Форматтер и линтер: разные задачи

Prettier (форматтер) перепечатывает код в едином стиле: отступы, кавычки, переносы, точки с запятой. Настроек мало намеренно: стиль не обсуждают.
ESLint (линтер) анализирует код и находит проблемы: неиспользуемые переменные, == вместо ===, забытые зависимости в useEffect, недостижимый код, await в цикле.

Линтер находит ошибки и плохие практики, форматтер про вид. ESLint с 8.53 сам объявил свои правила форматирования устаревшими и советует отдать форматирование отдельному инструменту. Чтобы ESLint и Prettier не спорили, подключают eslint-config-prettier: он выключает правила ESLint, которые конфликтуют с Prettier.

ESLint: flat config

С ESLint 9 по умолчанию используется flat config: файл eslint.config.js (или .mjs, .ts) с массивом объектов конфигурации. Старый .eslintrc объявлен устаревшим.

// eslint.config.js
import js from '@eslint/js';
import tseslint from 'typescript-eslint';
import prettier from 'eslint-config-prettier';

export default tseslint.config(
  { ignores: ['dist/**'] },
  js.configs.recommended,
  ...tseslint.configs.recommended,
  {
    files: ['src/**/*.{ts,tsx}'],
    rules: {
      eqeqeq: 'error',
      'no-console': 'warn',
    },
  },
  prettier,
);

Объекты применяются по порядку, более поздние переопределяют ранние. Плагины подключаются обычным import, а не строкой-именем, как раньше.

Уровни правила: "off" (0), "warn" (1), "error" (2). Ошибки дают ненулевой код выхода и роняют CI. Предупреждения по умолчанию нет, поэтому в CI часто запускают eslint . --max-warnings 0, иначе warning копятся годами.

Отключить правило точечно: // eslint-disable-next-line no-console. Без объяснения причины такие комментарии на ревью не любят.

Где запускать

В редакторе: подсветка и форматирование при сохранении.
Pre-commit хук: husky вешает git-хук, lint-staged прогоняет линтер и Prettier только по изменённым файлам, поэтому коммит не тормозит.
В CI: eslint . и prettier --check . по всему проекту. Хуки можно обойти (git commit --no-verify), а CI нельзя, поэтому последнее слово за ним.

В CI используют prettier --check (только проверить), а не --write (переписать файлы): CI не должен молча менять код.

Не только ESLint

typescript-eslint даёт парсер TypeScript и правила для него. Правила с информацией о типах (например, no-floating-promises про промис без await) точнее, но медленнее.
Stylelint проверяет CSS.
Biome написан на Rust и совмещает форматтер и линтер, работает в разы быстрее связки ESLint с Prettier, но экосистема плагинов меньше.
.editorconfig задаёт базовые настройки редактора: отступы, кодировку, перевод строки.

Частые ошибки

Включить в ESLint правила форматирования и Prettier одновременно: инструменты правят код друг за другом по кругу.
Полагаться только на pre-commit хук без CI.
Отключать правило на весь файл, чтобы «прошло».
Вводить строгий линтер в большой проект разом: тысячи ошибок, которые никто не чинит. Лучше включать правила постепенно или только для нового кода.

Что спросят на собесе

Чем линтер отличается от форматтера.
Как подружить ESLint и Prettier.
Что такое flat config.
Как устроены pre-commit хуки и почему их недостаточно.
Как внедрить линтер в старый проект.

Линтеры и форматирование